Database for PostgreSQL
Azure Database for PostgreSQL is managed PostgreSQL on the Flexible Server deployment model. Azure runs patching, backups, and high availability; you get a PostgreSQL server with the open-source extension ecosystem and full control of configuration. It is the path for applications built on PostgreSQL that should not run their own database.
Flexible Server replaced the older Single Server model, and new deployments should always use it — it gives zone-redundant high availability, configurable maintenance windows, and stop/start to save cost on non-production servers. Provisioning the retired Single Server today is a migration you will have to do later.
Flexible Server
Flexible Server gives you more control than the retired Single Server: server parameters, a chosen maintenance window, VNet integration or private access, and the ability to stop a server entirely when it is not needed. It is the only model Microsoft is investing in, and the default for every new PostgreSQL workload on Azure.
Compute Tiers
Three compute tiers match workload shape. Burstable accumulates CPU credits for low-traffic and dev servers. General Purpose balances CPU and memory for most production workloads. Memory Optimized serves memory-bound workloads with a higher memory-to-CPU ratio. As elsewhere, matching the tier to the bottleneck beats oversizing.
High Availability
Zone-redundant high availability provisions a hot standby in another availability zone with synchronous replication, failing over automatically on a zone or server failure. Same-zone HA places the standby in the same zone for lower replication latency without datacenter-failure protection. HA is a deployment choice, billed for the standby, and not on by default.
Extensions and Read Replicas
Flexible Server supports a broad set of PostgreSQL extensions — PostGIS, pg_stat_statements, pgvector for embeddings, and more — enabled per server. Read replicas offload read traffic to asynchronous copies, including across regions, for read-scale and a disaster-recovery copy. Writes still go only to the primary.
- Deploying the retired Single Server model for new work instead of Flexible Server, signing up for a future migration.
- Leaving high availability off in production and discovering it only during a zone outage — HA is opt-in and billed for the standby.
- Running a non-production server around the clock instead of using stop/start to pause compute billing.
- Oversizing on General Purpose when a memory-bound workload needed Memory Optimized, or a dev box needed Burstable.
- Assuming read replicas accept writes — they are read-only asynchronous copies; writes go to the primary.
- Forgetting that a needed extension must be explicitly allowed and enabled, then debugging why it is missing.
- Use Flexible Server for all new PostgreSQL deployments; migrate any remaining Single Servers.
- Enable zone-redundant HA in production where datacenter-failure protection matters.
- Stop non-production servers when idle to avoid paying for compute you are not using.
- Match the compute tier to the bottleneck — Burstable for dev, Memory Optimized for memory-bound work.
- Use cross-region read replicas for read-scale and as a disaster-recovery copy, keeping writes on the primary.
- Enable only the extensions you need (such as pgvector for embeddings) and pin configuration through server parameters.
Knowledge Check
Why should new Azure Database for PostgreSQL deployments use Flexible Server?
- It is the current, invested-in model with zone-redundant HA, maintenance windows, and stop/start; Single Server is retired
- It is the only deployment model that supports standard SQL queries and PostgreSQL extensions; Single Server cannot run them
- It bills per request like a serverless database with no idle charges
- It removes the need for read replicas by scaling reads on the primary
What does zone-redundant high availability provide on Flexible Server?
- A hot standby in another availability zone with synchronous replication and automatic failover
- A read replica in another availability zone that also accepts writes directly from the application alongside reads
- Per-second scale-to-zero billing when no queries run
- Automatic sharding of tables across multiple regions
A non-production PostgreSQL server runs 24/7 but is used only during work hours. What cuts cost most directly?
- Stopping the server when idle to pause compute billing
- Switching the server to Strong consistency for cheaper reads
- Adding a cross-region read replica to offload work-hours reads
- Enabling zone-redundant HA to share load across zones
You got correct