Why we built Azure HorizonDB for PostgreSQL
summary
Azure HorizonDB claims predictable latency under spikes by separating compute and storage, using shared WAL storage plus a sharded data storage fleet and NVMe SSD caches per node; commit path drops from four serialized local-disk steps to one zone-resilient hop, supporting up to 15 read replicas and faster failovers because nodes are stateless. The team implements storage and extensions in Rust, archives cold WAL to Blob storage, auto‑scales shards, and keeps read latency microseconds when data fits the SSD cache.
AI-written summary · about
chapters (12)
- 0:00Music & introduction
- 0:57Opportunity for Postgres to run better on Azure
- 2:04HorizonDB architecture and core design
- 3:20Separating compute and storage layers
- 5:08Rust and Azure HorizonDB
- 6:10Shared WAL storage and commit latency
- 9:31Write lifecycle and WAL filtering explained
- 11:22Faster failover with stateless nodes
- 13:44Read performance with SSD caching
- 15:05Data storage sharding and resilience
- 16:18Auto-scaling storage and point-in-time restore
- 18:04Key takeaways
related talks
50mUnleashing the Power of Azure for PostgreSQL
25mWhat’s New with Azure Database for PostgreSQL- Flexible Server
26mWhat Enterprises like about Azure Database for PostgreSQL - Flexible Server
28mHA and DR at a glance with Azure Database for PostgreSQL
46mEmpowering Developers: Microsoft’s Commitment to Ope...
51mAzure SQL Hyperscale Deep Dive
20mHosting Open Source Relational Databases at Scale
02h 02mAzure Cosmos DB: Liftoff