Most databases treat compute and storage as one unit. Serverless databases break them apart, and that is exactly what makes pay-per-use pricing possible. Here is how your serverless databases really work…
In a traditional Postgres setup, the process that runs your SQL queries and the layer that persists your data live on the same machine. Scale one, and you scale both. If you need more CPU for a heavy workload, unfortunately, you also pay for more storage (memory/disk, depending on the cloud), whether you need it or not.
Serverless databases like Neon, and all, split this apart. The compute layer, the Postgres process handling SQL execution, is completely separate from the storage layer that holds your actual data. They communicate over the network, typically through a custom storage interface that replaces the local disk.
By the way, this separation is what makes scale-to-zero possible.
When no queries are running, the compute process shuts down entirely. Storage keeps running, but you are not paying for idle CPU or RAM. The moment a connection arrives, compute spins back up, reads the latest state from storage, and picks up right where it left off.
The storage layer itself usually sits on top of distributed object storage, think S3, with a thin service in front that handles Postgres-specific concerns like WAL streaming and page serving.
By the way, this is not a Neon-specific trick. It is the core architectural pattern behind most serverless databases today. Aurora, AlloyDB, Neon, and others all follow some variation of this model.
Separate the stateless compute from the durable storage, and you get independent scaling, pay-per-use billing, and a much simpler operational model.