Debating Modern Postgres Architectures: Shared Nothing vs. Shared Everything
The multi-tenant storage layer provides great flexibility for features like instant provisioning and instant forking, but achieving true serverless inevitably means sacrificing some latency (even with aggressive prefetching). The architecture involves several components, such as the safekeeper (for WAL), page server (for heap), cold storage (S3), and more, each adding some overhead. This results in additional latency across the network, compute (page server), and storage (S3) layers. This also offers the ability to price very low.
With Bare Metal, storage is tightly coupled with compute, and disk access happens on the order of microseconds rather than milliseconds. I view the disk (specially with NVMe) almost as a second-level memory, which can significantly improve performance when a Postgres workload is memory bound leading to dis -access i. However, this architecture offers less flexibility in scaling, storage and compute must scale together, and presents challenges for instant provisioning and forking. That said, one could argue that cloud providers have evolved considerably, offering a broad range of bare-metal instance types.
There’s a user base that finds value in both Serverless and Base Metal architectures. I see serverless as being best suited for customers who prioritize flexibility, aren’t super latency sensitive and don’t anticipate scaling significantly in the near to medium term, where memory or disk might become a bottleneck. In contrast, Bare Metal can greatly benefit workloads that are expected to scale rapidly and where memory or disk performance becomes a critical factor.
Coming to my views on the future, I lean toward shared-everything (Metal) over shared-nothing (serverless), especially for OLTP workloads, where tail latencies really matter, and in contrast to OLAP workloads, every millisecond matters. I find Bare Metal to offer significantly better efficiency (price and performance at scale) while still providing enough flexibility. Metal also stays native to open-source Postgres, no forks or brittle extensions, which means it can keep up with the fast improvements happening in Postgres’ storage layer: async I/O, better checkpoints, vacuum, logical replication, and many other features.
From my experience working with thousands of Postgres customers at Citus, Microsoft, and ClickHouse, memory and disk I/O are always the biggest pain points as they scale. Metal helps address this, enabling customers to scale 2x–10x more efficiently as they grow. This need is even more pressing in today’s AI-driven world, where customers are and will hit memory and disk limits much sooner than before. As AI adoption accelerates and more companies make AI accessible across thousands of verticals, it’s becoming clear that planning for scale from day one is no longer optional, it’s essential.
When it comes to future innovation in this area, one obvious area is making the powerful Metal/NVMe architecture accessible to everyone — through enterprise-grade managed services, which is already starting to take shape. Next, I think the focus will be on overcoming the flexibility challenges of Bare Metal architectures: how do we lower the cost barrier to entry, enable instant provisioning and forking, achieve infinite scale through approaches like sharding, and more.