Comparing Managed Postgres Options on The Azure Marketplace

Azure is expanding their Postgres portfolio, now offering a range of managed Postgres services to suit the needs of developers and teams of all sizes. In this post, we’ll walk through the main Postgres options available on the Azure Marketplace, so you can find the one that works best for your application.

Why Deploy Postgres Through the Azure Marketplace?

If your company runs on Azure infra, using the Azure Marketplace to set up your database makes things simple and efficient. Here’s why: 

• Unified billing. You can manage your database costs right alongside the rest of your Azure services, which most likely simplifies the internal process of approval for your team. 
• Built-in security. You can use your Microsoft credentials to access the database. 
• Integrated workflows. You can use  Azure CLI and SDKs to manage your database, integrating it with other Azure tools without issues. 

Managed Postgres Services in Azure 

Now that you’re set in the Azure Marketplace, let’s take a look at your options. 

Azure Database for PostgreSQL 

Azure Database for PostgreSQL was the first managed Postgres service introduced by Azure. Launched in 2017, it was Azure's initial step into offering managed Postgres services to developers looking to ease the main management tasks associated with running Postgres in production, getting help with automated backups, high availability, and basic scaling capabilities. 

Azure Database for PostgreSQL offers two primary flavors, Single Server and Flexible Server. Single Server was the first implementation of the service; over time, Azure recognized the growing demand for more flexible and advanced features, which led to the introduction of Flexible Server. 

This new flavor aimed to address some of the limitations of Single Server by offering more control, better scaling options, and features like zone-redundant high availability and VNet integration. Flexible Server has since become the recommended option as Azure transitions away from Single Server, which is set to retire in March 2025.

For this reason, let’s take a closer look at the Flexible Server configuration, since it will very soon be the only flavor of Azure Database for PostgreSQL: 

Flexible Server: Feature Overview 

As we were saying, Flexible Server is the most recent iteration of Azure Database for PostgreSQL, built to provide greater control over database management and configuration. Feature highlights include: 

• Multi-AZ deployments
• Customizable maintenance windows
• VNet integration for enhanced security
• The ability to manually stop and start servers to optimize costs
• The possibility to autoscale compute using Azure Automation Tasks

Flexible Server: Storage 

In a flexible server, users provision storage based on their anticipated needs and get billed for it at the end of the month (storage is billed by GiB/month). Generally speaking, this is how things work: 

• When setting up your PostgreSQL Flexible Server, you'll start with at least 32 GiB of storage.
• You can manually increase the storage capacity as your data requirements grow. Once expanded, the storage size cannot be reduced. To decrease storage, you'd need to create a new server with the desired size and migrate your data. 
• Flexible Server offers a “storage autogrow” feature that automatically scales up storage when usage reaches a certain threshold. This helps prevent disruptions due to insufficient storage. Note that autogrow only scales storage up; it doesn't reduce storage if usage decreases. 
• At the end of the month, your receive charges are based on the provisioned storage size, not actual usage. 

Flexible Server: Compute  

Flexible Server offers several compute scalability options to suit different workloads. Compute resources are provisioned in virtual cores (vCores) and organized into pricing tiers, each with specific capabilities and performance characteristics. Here's a breakdown:

• Burstable. For intermittent and light workloads, such as development or testing environments. They’re billed via a credit-based system: CPU credits accumulate during idle times and are consumed during bursts of activity. 
• General purpose. Designed for most business applications requiring balanced compute and memory resources, e.g., web applications. The memory-to-vCore ratio is 5 GiB per vCore. 
• Memory optimized. For high-performance workloads with low latency and high memory requirements, e.g. analytical applications. Memory-to-vCore ratio is 10 GiB per vCore. 

How scaling works: 

• Manual scaling (standard). Compute resources can be manually scaled up or down using the Azure portal, CLI, or API. While scaling up typically does not cause downtime, scaling down may result in brief downtime (up to a few minutes) as active connections are re-established. Both scaling actions can cause a temporary performance impact during the reconfiguration process.
• Autoscaling (custom). Flexible Server does not natively support automatic scaling for compute resources, but users can implement autoscaling through Azure Automation Tasks. 

Neon Serverless Postgres

Neon provides a serverless Postgres solution designed to help teams ship modern applications faster. As an Azure Native Integration, developers can provision and manage Neon organizations directly within the Azure portal. 

Unlike traditional managed Postgres services, Neon natively separates compute and storage layers and implements an innovative storage design that supports database branching. This architecture is tailored for medium-sized teams who want a Postgres experience that adapts dynamically to their application's demands and workflows while minimizing costs.

Neon: Feature Overview

Neon Serverless Postgres' features are aimed at simplifying database management for teams deploying serverless applications: 

• Databases provisioned instantly (under a second) 
• Automatically scales compute and storage resources based on usage
• Developers can create isolated branches of their database for testing or development 
• Supports up to 10,000 concurrent connections

Neon: Storage 

Neon’s storage architecture separates storage from compute and keeps a record of Postgres' WAL, supporting features like database branching and point-in-time restores via copy-on-write. Data is stored using a combination of object storage and SSDs, distributed across multiple availability zones to enhance reliability and availability. 

Storage is billed based on a subscription model that includes a predefined volume within the monthly fee. Any usage beyond this allocation is charged based on actual consumption, calculated hourly. Storage is not billed by allocation but by usage (it "scales down").

Neon: Compute 

Neon automatically adjusts compute resources based on real-time workload demands. It scales up during peak activity to handle increased traffic and scales down to zero when the database is idle for more than 5 minutes. Neon’s autoscaling algorithm monitors CPU usage, working set size, and memory utilization to dynamically adjust resources with precision.

After scaling to zero, databases experience a cold start latency of around 500 ms. Autoscaling occurs without downtime or disruptions to active connections. 

In terms of billing, 

• Neon measures compute consumption in compute hours, which factor in both CPU and memory usage as well as the duration the database is active.
• Monthly subscriptions include a certain number of compute hours within the base fee.
• After the included hours are consumed, additional compute usage is billed based on true usage, with charges calculated hourly.

Azure Cosmos DB for PostgreSQL

Azure Cosmos DB for PostgreSQL is Azure’s answer for developers who need a distributed Postgres database service capable of handling large-scale, high-performance applications. The service is based on a distributed, “shared-nothing” architecture that allows the cluster to scale by adding more nodes, each with its own storage and compute resources: 

• A coordinator node manages metadata and orchestrates query planning across the cluster.
• Worker nodes store the actual data and execute queries in parallel. 

CosmosDB: Feature Overview

Azure Cosmos DB for PostgreSQL is built to handle large, high-performance workloads by distributing data across a cluster of nodes. Key features include:

• Automatic sharding of data across worker nodes while the coordinator node manages query planning and execution, across multiple Azure regions 
• Add or remove nodes to scale compute and storage independently
• Built-in replication and fault tolerance ensure consistent uptime and reliability.

CosmosDB: Storage 

Azure Cosmos DB for PostgreSQL uses a distributed storage system where each node has its own allocated storage capacity:

• Storage must be provisioned for each node (coordinator and workers) based on anticipated needs. The minimum per node is typically 128 GiB, with the ability to increase as requirements grow.
• Storage in Cosmos DB does not “auto-grow” dynamically. You’ll need to manually increase storage when nearing capacity.
• Charges are based on the total provisioned storage across all nodes (not usage-based). 

CosmosDB: Compute 

When setting up a Cosmos DB for a PostgreSQL cluster, users provision compute resources separately for the coordinator node and worker nodes. The coordinator node requires enough compute power to efficiently handle query coordination for distributed data; in the case of the worker nodes, they determine the horizontal scaling capacity of the database, each one of them having its own provisioned compute resources. 

So there are two dimensions of scaling in CosmosDB: 

• Vertical scaling. E.g., increasing memory for the coordinator to handle larger query planning or scaling up worker nodes to support more intensive queries. This is a manual operation and may involve downtime.
• Horizontal scaling. This involves the addition or removal of worker nodes, a process that’s also handled manually. When adding nodes, data is re-sharded and redistributed across the cluster, a process that can temporarily impact performance. 

In terms of compute billing, compute costs are billed for the provisioned resources on both coordinator and worker nodes (not usage-based). It’s worth noticing that horizontal scaling directly affects the number of worker nodes, increasing or decreasing costs accordingly.

EDB Postgres AI Cloud Service

The EDB Postgres AI Cloud Service is an offering from EnterpriseDB (EDB) that combines Postgres features with Oracle compatibility, making it a good choice for enterprises looking to migrate from Oracle to Postgres. 

EDB Postgres: Feature Overview

This service offers features aimed at enterprises looking for a Postgres service, with an emphasis on machine learning and AI workloads. 

• It provides support for Oracle database syntax, functions, and procedures
• Includes built-in replication, clustering, and failover options 
• Features robust encryption, role-based access control, and audit logging
• It offers optimizations for running machine learning and AI workloads 

EDB Postgres: Storage 

In EDB Postgres AI Cloud Service, users allocate storage based on their expected workload requirements. Storage size can be manually increased, but it cannot shrink once provisioned. At the end of the month, charges are based on provisioned storage, with additional costs for backup storage that exceeds the default free tier.

EDB Postgres: Compute   

In the EDB Postgres AI Cloud Service, users can manually adjust compute resources, such as virtual CPUs (vCPUs) and memory, for individual instances through the EDB Cloud Console. This process is designed to minimize downtime, though some operations may require brief interruptions. Currently, the service does not support automatic scaling of compute resources; all scaling operations must be performed manually.

Pick Your Flavor of Postgres in the Azure Marketplace

Here’s a recap to help guide your decision:

• Azure Database for PostgreSQL Flexible Server is a robust managed Postgres option, especially attractive if you have experienced DBAs in your team. 
• Neon Serverless Postgres requires less manual oversight and a lower price to entry, what makes it a great option for smaller teams and startups. 
• Azure Cosmos DB for PostgreSQL is the best choice for applications that demand distribution across multiple regions and horizontal scalability. 
• EDB Postgres AI Cloud Service has great supporting features if you're migrating from Oracle to Postgres.

Each option has its strengths and trade-offs. The best way to decide is to explore them in the Azure Marketplace and choose the one that fits your application’s requirements. Go ahead and create your first Postgres database.