On this page · 11 sections
- The preview limitations that actually decide it
- How HorizonDB is actually built
- How Flexible Server is built, and why that is often enough
- A decision procedure, not a feature list
- Cost shape, not cost numbers
- India-specific considerations
- If you are staying on Flexible Server
- What would change our answer
- FAQ
- How eCorpIT can help
- References
Summary. Microsoft announced the public preview of Azure HorizonDB at Microsoft Build 2026 on 2 June 2026, and as of 20 July 2026 it remains in preview across 5 Azure regions: Central US, West US 2, West US 3, Sweden Central and Australia East. Azure Database for PostgreSQL flexible server is generally available in more than 60 regions, including Central India, South India, Jio India Central and Jio India West. That single line settles the decision for most Indian workloads before anyone opens a benchmark.
The architectures genuinely differ. HorizonDB separates compute from storage and writes only the write-ahead log from compute to storage, a database-as-a-log design. Flexible Server runs the community engine in a container on a Linux virtual machine with three locally redundant synchronous copies of the data files, and it starts at a few dollars a month on the Burstable tier. HorizonDB bills provisioned compute in core hours plus used database storage per GB per month.
But Microsoft's HorizonDB documentation, last updated on 2 June 2026, publishes 8 capabilities the service does not yet have, and that list, not throughput, is what should drive the decision in 2026. Backup retention is fixed at 7 days against a configurable 35 days on Flexible Server. There are no customer-managed encryption keys. There are no cross-region read replicas.
The preview limitations that actually decide it
Microsoft's HorizonDB overview publishes the gaps openly. Read them as a checklist before anything else.
| Capability | Azure HorizonDB (preview) | Flexible Server (generally available) |
|---|---|---|
| Backup retention | Fixed at 7 days; 1 to 35 days in progress | Default 7 days, configurable to 35 days |
| Cross-region read replicas | Not yet available | Supported, with geo-redundant backup in many regions |
| Customer-managed keys | Not available; service-managed keys only | Storage encryption with FIPS 140-2 validated module, AES 256-bit |
| Maintenance windows | System-managed only; not configurable | System-managed or a custom schedule you choose |
| Connection pooling | No built-in PgBouncer; use an external pooler | Built-in PgBouncer on port 6432 |
| Network isolation | Private Link only; no virtual network injection | Full virtual network integration, public access denied |
| Long-term retention | Not available | Retention configurable within the 35-day window |
| Index tuning | Not yet available | Supported |
| Indian regions | None | Central India, South India, Jio India Central, Jio India West |
Four of those rows are not performance trade-offs. They are compliance and operations blockers. A regulated workload that requires customer-managed keys, a documented cross-region disaster recovery path, or backups held longer than a week cannot run on HorizonDB today regardless of how fast it is.
Microsoft notes the list reflects the current state of the service and is subject to change, so re-check it before you plan. That is the correct instruction and also the reason not to write a 2027 architecture around a preview feature set.
How HorizonDB is actually built
The architecture is the interesting part, and it is a real departure from Flexible Server rather than a bigger VM.
Disaggregated compute and storage
Compute in HorizonDB is stateless. vCores and memory scale independently of storage and vice versa, and you scale reads horizontally by adding replicas to the cluster. The storage layer runs two purpose-built fleets, one for the write-ahead log and one for data, both durable on Azure storage and zone resilient by default. Storage grows automatically as data grows, with no provisioned size or IOPS to configure.
Three consequences follow: compute and storage scale on separate axes, read replicas provision quickly because they share the same underlying storage with no data copy, and failover is faster because the durable WAL storage is shared and no log rewinding is needed.
Database-as-a-log
Only the write-ahead log travels from compute to storage. Data pages are never written from the compute replicas. As Microsoft's documentation, authored by Denzil Ribeiro, states it: "WAL is the authoritative source of truth through the system."
The write path works like this. Every write is appended to a durable log service and acknowledged to the client. Filtered WAL then goes only to the storage nodes owning those changes. Storage nodes reconstruct page state by replaying WAL, which removes the traditional checkpoint I/O bottleneck. The claimed payoff is reduced write amplification and consistent write latency regardless of database size.
The offloading is concrete. WAL sending, WAL archiving, dirty page writing, checkpointing, backups, full page writes and WAL recovery all move off the compute replica to the storage layer, freeing disk and network I/O for actual query work.
What a cluster looks like
A HorizonDB cluster has one or more compute replicas, exactly one of which is a writable primary while the rest are readable standbys and failover candidates. There is a single copy of data in zone-resilient shared storage, a read-write endpoint that always points at the primary, and a read-only endpoint that load balances across the readable replicas.
Two operational numbers matter. You need at least two replicas for zonal resilience, so a single-replica cluster is not a resilient deployment. And compute replicas come with 8 GB of memory per provisioned core, plus a local NVMe SSD cache on every replica that holds hot pages and cuts fetches from remote storage.
How Flexible Server is built, and why that is often enough
Flexible Server also separates compute and storage, but conventionally: the database engine runs in a container inside a Linux virtual machine while data files sit on Azure storage holding three locally redundant synchronous copies.
Zone-redundant high availability provisions a warm standby in another availability zone in the same region, with synchronous replication for zero data loss. On failover, planned or unplanned, the standby comes online immediately.
The service supports the major community PostgreSQL versions, which is the thing teams underrate. Running the community engine means an existing application migrates with minimal refactoring, through either Azure Database Migration Service or plain pg_dump and pg_restore.
Three compute tiers cover the range: Burstable for low-cost development and low-concurrency work, General Purpose and Memory Optimized for production workloads needing concurrency and predictable performance. The V6 SKU family is in public preview for General Purpose and Memory Optimized, with its own restrictions worth knowing: you cannot scale between the V6 family and the Burstable tier in either direction, and virtual network integration is not supported on V6.
Cost control is more granular here too. You can stop the server on demand and compute billing stops immediately, though the server stays stopped for seven days unless you restart it sooner.
A decision procedure, not a feature list
Work through these in order. The first "no" ends it.
Do you need an Indian region? HorizonDB has none. Flexible Server has four. Stop here for any workload with an India data-residency requirement.
Do you need customer-managed keys? HorizonDB uses service-managed keys only. If your security review requires CMK, this is a hard stop.
Do you need cross-region disaster recovery? HorizonDB has no cross-region read replicas yet. Flexible Server offers geo-redundant backup in many regions.
Do you need backups older than seven days? HorizonDB's retention is fixed at seven days. Many audit regimes require more.
Do you need virtual network injection? HorizonDB supports Private Link but not VNet injection. If your network standard mandates injection, stop.
Are you migrating an existing Postgres database as-is? Flexible Server runs the community engine, which is the shortest path.
Do you actually need horizontal read scale-out with shared storage? This is the case HorizonDB is built for, alongside vector search and AI Foundry integration in the database layer. If your read load genuinely needs many replicas over one copy of data, HorizonDB's architecture is the one designed for it.
Can you tolerate preview terms? A preview service is a preview service. Plan a fallback.
Most teams stop at question one, two or four. That is not a criticism of HorizonDB. It is what "preview" means, and Microsoft documents it plainly.
Cost shape, not cost numbers
The two services bill on different shapes, which matters more than the rate card when you model a year.
HorizonDB charges provisioned compute in core hours, used database storage per GB per month, and used backup storage for the short-term retention period. Storage is allocated dynamically as the database grows, so there is no provisioned-IOPS line to get wrong and no over-provisioned volume to pay for.
Flexible Server bills hourly at a fixed rate per tier, and Microsoft's own guidance notes you can start on a small database for a few dollars a month and scale from there. The stop-and-start capability makes non-production environments genuinely cheap, since compute billing halts the moment you stop the server.
The trap in both cases is the same one FinOps teams hit everywhere: read replicas are compute. HorizonDB makes adding replicas easy precisely because they share storage, which means the thing that scales your reads also scales your bill on the compute axis. Our guide to FinOps for AI and cloud cost across AWS, Azure and GCP in India covers the budgeting controls that belong around this before, not after, the first invoice.
Check the pricing page for current rates rather than trusting any figure quoted in a third-party comparison, including this one. Preview pricing changes.
India-specific considerations
This is where the comparison stops being close.
HorizonDB is not available in any Indian region as of 20 July 2026. The preview footprint is Central US, West US 2, West US 3, Sweden Central and Australia East. For a workload that must keep personal data in India, that ends the evaluation.
Flexible Server's Indian footprint is more nuanced than "available in India", and the differences matter for architecture. Microsoft's region table shows South India with zone-redundant high availability, same-zone high availability and geo-redundant backup all supported. Central India supports the same set, but is marked as a region where new zone-redundant HA deployments are temporarily blocked, so an existing HA server keeps running while a new one may not provision. Jio India Central and Jio India West support same-zone high availability and geo-redundant backup, but not zone-redundant HA.
Read that carefully before you promise an availability target. A design that assumes zone-redundant HA in Central India may not be deployable right now, and a Jio India region cannot give you zone redundancy at all. Microsoft's own note suggests using another region in the same geography when zone-redundant HA is unavailable in your preferred one, which for an India-resident workload means South India rather than a foreign region.
On privacy, the Digital Personal Data Protection Act 2023 makes the region choice an architectural decision rather than a latency preference. Teams working through those obligations will find the DPDP engineering playbook for Indian startups useful, and the sequencing of a database move is covered in our cloud migration and modernization notes.
If you are staying on Flexible Server
Two things are worth doing now rather than waiting for HorizonDB to reach general availability.
Set backup retention deliberately. The default is seven days and the ceiling is 35. Teams routinely leave it at the default and discover the gap during an audit.
Turn on the built-in PgBouncer rather than running your own. It is available on port 6432, and on port 8432 for elastic clusters, using the same hostname. Connection pooling is one of the capabilities HorizonDB explicitly lacks today, and it is free here.
Beyond that, the engine-level work is the same on either service. Our Postgres 18 async I/O and UUIDv7 migration guide covers the tuning that pays off regardless of which Azure service hosts it, and the staged-rollout discipline in our Kubernetes 1.35 upgrade guide applies equally to a database platform move.
What would change our answer
Three things, in order of impact.
An Indian region for HorizonDB. This reopens the entire evaluation for the Indian market in one step.
Customer-managed keys and cross-region read replicas. These unblock the regulated workloads that would otherwise most want the architecture.
General availability with configurable backup retention. Microsoft says 1 to 35 days is in progress. Until it lands, seven days is the ceiling and that is disqualifying for a lot of enterprise data.
Until then the honest recommendation is narrow. Run a HorizonDB proof of concept if you have a genuine read scale-out or in-database vector search problem and you are already deploying in one of the 5 preview regions. Keep production on Flexible Server. Revisit at general availability.
FAQ
How eCorpIT can help
eCorpIT is a senior-led engineering organisation in Gurugram that helps teams choose and move onto managed database platforms without discovering a compliance gap after the migration. We map your residency, encryption and disaster recovery requirements against what each service actually supports today, design applications aligned with Digital Personal Data Protection Act 2023 requirements, and stage the cutover so a preview service never sits on your critical path. If you are evaluating Postgres options on Azure, talk to us about an architecture review.
References
- What is Azure HorizonDB (Preview)? Microsoft Learn, updated 2 June 2026.
- What is Azure Database for PostgreSQL flexible server? Microsoft Learn.
- Choose the right hosting option in Azure Database for PostgreSQL flexible server Microsoft Learn, updated 8 July 2026.
- PostgreSQL on Azure: two services, one future-proofed ecosystem Microsoft Community Hub.
- Azure HorizonDB: enterprise-ready Postgres, engineered for the AI era Microsoft Community Hub.
- Announcing Azure HorizonDB Microsoft Community Hub.
- Azure HorizonDB release notes Microsoft Learn.
- Backups in Azure HorizonDB (Preview) Microsoft Learn.
- Backups in Azure Database for PostgreSQL Microsoft Learn.
- Built-in PgBouncer in Azure Database for PostgreSQL Microsoft Learn.
- Supported versions of PostgreSQL in Azure Database for PostgreSQL Microsoft Learn.
- Reliability in Azure Database for PostgreSQL flexible server Microsoft Learn.
- Azure Database for PostgreSQL pricing Microsoft Azure.
- Azure HorizonDB product page Microsoft Azure.
- Migration service in Azure Database for PostgreSQL Microsoft Learn.
Last updated: 20 July 2026.
