PostgreSQL is a proven open-source relational database that powers mission-critical workloads across many organisations. Azure Database for PostgreSQL brings that same engine to Microsoft’s cloud as a fully managed service, removing the operational overhead of provisioning, patching, and administering database instances. Developers can connect using native PostgreSQL tools, drivers, and libraries without changing their existing workflows.
Deployment Options
At the time of the original publication (October 2019), Azure Database for PostgreSQL offered two deployment models: Single Server and Hyperscale (Citus). The Hyperscale option was in public preview at that time. Microsoft has since evolved its PostgreSQL offerings, so check the current Azure documentation for the latest deployment options and their general-availability status.
Single Server
The Single Server deployment model is the standard option for teams migrating PostgreSQL workloads from on-premises environments. The experience is familiar: a single PostgreSQL server instance acts as the host for one or more databases, and teams manage it through the Azure portal or the Azure CLI.
Key characteristics of the Single Server model include:
- Fully managed: Microsoft handles OS patching, PostgreSQL engine updates, and hardware maintenance.
- High availability SLA: The service provides a four-nines (99.99%) uptime guarantee with no additional configuration required.
- Built-in backup and encryption: Automated backups and at-rest encryption are included by default.
- Flexible database hosting: You can host a single database per server to maximise dedicated resources, or share a server across multiple databases.
Permissions and the azure_pg_admin Role
One important constraint to understand before migrating: administrators of Azure Database for PostgreSQL do not receive full PostgreSQL superuser privileges. The highest role available to service users is azure_pg_admin. The actual superuser attributes are assigned internally to the azure_superuser account, which belongs to the managed service itself and is not accessible to tenants. Any workloads or scripts that depend on superuser-level access will need to be reviewed before migration.
Hyperscale (Citus)
For very large databases — broadly, those exceeding 100 GB — or workloads that require horizontal scalability beyond what a single server can provide, Azure offers the Hyperscale (Citus) deployment model. This option is built on technology from Citus Data, a company Microsoft acquired in January 2019.
How Sharding Works in Hyperscale (Citus)
Hyperscale (Citus) uses database sharding to distribute data across a cluster of compute nodes. Rather than storing all data on a single server, data is split into smaller shards and spread across multiple worker nodes. The architecture has two logical roles:
- Coordinator node: Receives queries from the application, determines which worker node(s) hold the relevant data shards, routes sub-queries accordingly, and aggregates results before returning them to the client.
- Worker nodes: Store the actual data shards and execute the distributed query fragments routed to them by the coordinator.
A critical advantage of this model is that sharding is handled transparently by the platform. The application does not need to be aware of the sharding logic — it simply issues standard SQL queries to the coordinator endpoint. Hyperscale (Citus) parallelises query execution across available worker nodes, which can significantly reduce query latency for large analytical or multi-tenant workloads.
Note on SLA: As the Hyperscale (Citus) option was in public preview at the time of original writing, no SLA was offered. Verify the current general-availability and SLA status in the official Azure documentation before relying on it for production workloads.
Pricing Tiers (Single Server)
Azure Database for PostgreSQL Single Server is available across three pricing tiers. Your monthly cost is influenced by the tier selected, the number of vCores provisioned, the amount of storage consumed, and the backup retention period configured. The number of databases hosted on a server does not directly affect pricing.
After a server is created, you can adjust the vCore count, storage allocation, backup retention period, and switch between the General Purpose and Memory Optimised tiers without reprovisioning. Note that downgrading from General Purpose or Memory Optimised to the Basic tier is not supported after deployment.
Tier Comparison
| Attribute | Basic | General Purpose | Memory Optimised |
|---|---|---|---|
| Compute generation | Gen 4, Gen 5 | Gen 5 | Gen 5 |
| vCores | 1, 2 | 2, 4, 8, 16, 32, 64 | 2, 4, 8, 16, 32 |
| Memory per vCore | 2 GB | 5 GB | 10 GB |
| Storage capacity | 5 GB – 1 TB | 5 GB – 4 TB | 5 GB – 4 TB |
| Storage type | Azure Standard Storage | Azure Premium Storage | Azure Premium Storage |
| IOPS guarantee | None | 3 IOPS per GB provisioned | 3 IOPS per GB provisioned |
| Backup retention | 7–35 days | 7–35 days | 7–35 days |
Choosing the Right Tier
Basic — Suitable for development, testing, and low-traffic applications that do not require sustained high performance. The Basic tier does not provide an IOPS guarantee and uses Azure Standard Storage, so it is not appropriate for latency-sensitive production workloads.
General Purpose — The right choice for most production PostgreSQL workloads, including web applications and SaaS platforms. It offers a balance of compute, memory, and I/O performance backed by Azure Premium Storage and scales to up to 64 vCores.
Memory Optimised — Designed for workloads where dataset size and query performance depend heavily on in-memory caching, such as financial transaction processing, real-time analytics, and high-throughput OLTP. It provides double the memory per vCore compared to General Purpose.
Key Benefits of Azure Database for PostgreSQL
- Built-in high availability: The service delivers high availability out of the box with no additional VMs, replication setup, or extra cost. Hardware failures trigger automatic failover without manual intervention.
- Security by default: Data at rest — including backups — is encrypted on disk. SSL/TLS is enabled by default for all connections, encrypting data in transit without requiring additional configuration.
- Live scaling: Compute resources (vCores) can be scaled up or down without application downtime, allowing teams to respond to changing load without maintenance windows.
- Automated backups: The service manages backup storage automatically. Point-in-time restore is available within the configured retention window of up to 35 days, eliminating the need to manage backup infrastructure separately.
- Native PostgreSQL compatibility: Because the service runs standard PostgreSQL, existing drivers, ORM libraries, extensions, and tooling work without modification. Teams can use
psql, pgAdmin, and other familiar tools against their Azure-hosted instances. - Integrated management: The Azure portal, Azure CLI, and Azure Resource Manager templates all support full lifecycle management of PostgreSQL instances, making it straightforward to incorporate database provisioning into infrastructure-as-code pipelines.
Summary
Azure Database for PostgreSQL provides a managed PostgreSQL environment that reduces operational burden while retaining compatibility with the standard PostgreSQL ecosystem. The Single Server model suits most migration and greenfield workloads, while Hyperscale (Citus) addresses large-scale distributed use cases through automatic sharding. Pricing is determined by the selected tier, vCore count, storage, and backup retention — giving teams the flexibility to right-size their database infrastructure as workloads evolve.
For current pricing, available PostgreSQL engine versions, and the latest deployment options (including Flexible Server, which was introduced after this article was originally written), refer to the official Azure Database for PostgreSQL documentation.