Architecture decisions in Neon, a serverless Postgres service

The article mentions that a consequence of separating storage from compute is that compute nodes cache hot pages in memory and load cold pages from object storage (like S3?) when needed. Does anyone know what are the consequences of this decision. In case of a query that touches multiple rarely used pages, would that incur high latency and ingress? How does that penalty compare to a vanilla postgres running on AWS and storing pages on EBS?

I would love to spend 1-3 years with other good people to just build good tech :(

A clean, low-friction separation of storage and compute for a top-tier database like Postgres is huge. I think it will take some time for the implications to sink in though, because it changes some assumptions about how to integrate a databases with a system that are so fundamental that we rarely think about it... (not to mention, it probably doesn't make sense to change existing systems, where the fundamental system decisions have already been made.)

We tend to centralize the database in system design because they are complex and expensive to run, and you can amortize those costs the more you put into a single database. But of course, that also makes the central database bigger, more complex and more expensive. And once everything is in a central store, we tend to bind everything together (with joins, references, procs, etc. Each step in that direction tends to make sense on its own, but the end result is the "big ball of mud" architecture where everything is interconnected and there's no separation of concerns, which makes the system fragile and increasingly difficult to change.

With this tech the pressure to centralize the database is relieved.

E.g., if you have a situation where you are adding some new, logically distinct data to your system -- maybe just a few tables and maybe with a variable load, especially at first -- traditionally you probably would lean hard toward adding this to an existing central database since the overhead of spinning up and running a new one would be prohibitive. But now you can just make that a separate database -- spinning up a managed one is easy and you only need to pay for as much storage and compute as you actually need to use (which is really about the same as if you had put the tables in an existing central database anyway).

Of course, systems would still tend to have significant central data, but that could be based on actual app concerns, not operational ones.

Anyway, I'm loving this and can't wait to see the long term impact.

You can have as many databases as logically makes senseseparate data logically without exploding the operational cost of your system. E.g. you can spin out a separate a database that has light (or even no load) most of the time yet can seamlessly scale to heavy load. And it can do this independent of how much data is in it, and you don't need to worry about it's affect on day-to-day data access in your system since you