Adam Prout

Distinguished Engineer @ Microsoft. Ex-MemSQL/SingleStoreDB cofounder.

Database builder. One trick pony.

[Adam Prout @a_prout]

@sunbains Alot of databases written in Rust end up going down this path it seems. Some of the HorizonDB storage layer uses:

https://t.co/TT5xyRm248

[Adam Prout @a_prout]

@JasonThorsness Yep, we are throwing agents indiscriminately at every bug filed right now. We're starting to indiscriminately try to have them find bugs more directly...

[Adam Prout @a_prout]

Broadly agree that there is some pressure to go faster via agents and hope your tests are good enough to catch problems.

That said, I still have hope that the overall quality of software will go up with agents debugging, testing and fixing bugs. They are good at this.

[Mitchell Hashimoto @mitchellh]

I strongly believe there are entire companies right now under heavy AI psychosis and its impossible to have rational conversations about it with them. I can't name any specific people because they include personal friends I deeply respect, but I worry about how this plays out.

I lived through the great MTBF vs MTTR (mean-time-between-failure vs. mean-time-to-recovery) reckoning of infrastructure during the transition to cloud and cloud automation. All those arguments are rearing their ugly heads again but now its... the whole software development industry (maybe the whole world, really).

It's frightening, because the psychosis folks operate under an almost absolute "MTTR is all you need" mentality: "its fine to ship bugs because the agents will fix them so quickly and at a scale humans can't do!" We learned in infrastructure that MTTR is great but you can't yeet resilient systems entirely.

The main issue is I don't even know how to bring this up to people I know personally, because bringing this topic up leads to immediately dismissals like "no no, it has full test coverage" or "bug reports are going down" or something, which just don't paint the whole picture.

We already learned this lesson once in infrastructure: you can automate yourself into a very resilient catastrophe machine. Systems can appear healthy by local metrics while globally becoming incomprehensible. Bug reports can go down while latent risk explodes. Test coverage can rise while semantic understanding falls. Changes happens so fast that nobody notices the underlying architecture decaying.

I worry.

[Adam Prout @a_prout]

This approach gives you more CPU to run your workload.

I talked about this in more detail recently in Andy's CMU tech talk series. HorizonDB uses Azure blob store as its durable storage (same design as the Socrates paper)

https://t.co/FDajCwdHy9 via @YouTube

[Adam Prout @a_prout]

Agreed, shared storage (Aurora, AlloyDB, HorizonDB, Neon, etc.) is the dominate design for cloud OTLP. It's not the best in every scenario, but it is for most use cases. You can push a lot of work (replication, full page writes, dirty page writes, etc.) into the storage layer

[Nikita | Scaling Postgres @nikitabase]

There is a new era of data tech that is effectively "__ on object storage":

Turbopuffer is "vector search on object storage"
Warpstream is "kafka on object storage"
Neon is "Postgres on Object Storage" or “Postgres on S3”.

It doesn’t mean that every read and write goes directly to S3. That would be incredibly slow. I’m saying that a Postgres database in the "Postgres on object storage" category can be faster than one in the "Postgres on a cluster of servers with NVMe disks" category.

No one is claiming that S3 is faster than NVMe but Postgres on S3 (with low latency storage in between) can be faster than Postgres running on NVMe with HA on. HA is important here, without HA you don’t do durable writes so it would be an unfair comparison.

While neon runs on s3, calls into s3 are almost never on the transaction reads or writes. Writes are sent into a consensus service and streamed into s3 asynchronously. So the claim can be expanded to Postgres running on a disaggregated storage which implements low latency tier on top of s3 is faster then Postgres with HA running on NVMe.

We are not the only ones making this claim. For example AWS Aurora says "Aurora has 5x the throughput of MySQL and 3x of PostgreSQL with full PostgreSQL and MySQL compatibility."

So why does disaggregating compute allow for higher throughput on Postgres and potentially lower latency as well? The reason is that we can offload a number of CPU and IO operations down to storage. We just published a blog post on how we can turn off full page writes which dramatically reduces WAL volume and saves on CPU cycles on the Postgres node.

In many scenarios this may be a wash because for many workloads you might not be write throughout bound and therefore Postgres checkpoints and full page writes don’t impact overall throughput. However this is general purpose enough to impact a large swath of workloads. It’s also important to mention that scaling write throughput is more important since Postgres is a single write system and you can’t scale writes with read replicas.

So is Postgres on S3 faster than Postgres on NVMe? We believe it can and will be. Postgres with disaggregated storage and several kernel performance optimizations has higher throughput than stock Postgres on NVMe with HA implemented via sync replication.

We'll share more including latency impact as we gather insights after rollout. Lots of things to learn here if saving CPU on full page writes can have a material impact on latency under high throughput. The idea is that if CPU is all used up, freeing up some CPU will impact both latency and throughput - but we'll see!

The statement is indeed provocative, but far from “shock value marketing” as some of the responses claim.

[Adam Prout @a_prout]

If I had known database twitter was going to blow up about NVMe vs blob store for OLTP today, we would have hit on that in a little more detail! Still, if you're interested in a career working on databases hopefully this podcast will be of some interest to you.

[Claire Giordano ✨ @clairegiordano]

🎙️ New #TalkingPostgres podcast Ep39 is out!

@a_prout, distinguished engineer at Microsoft, talked about his engineering journey from MemSQL to HorizonDB, shared-storage, & why good systems programmers are paranoid

🎧 https://t.co/0Phno5nHFL
📺 https://t.co/phFB0kEh1O

[Claire Giordano ✨ @clairegiordano]

🎙️ New #TalkingPostgres podcast Ep39 is out!

@a_prout, distinguished engineer at Microsoft, talked about his engineering journey from MemSQL to HorizonDB, shared-storage, & why good systems programmers are paranoid

🎧 https://t.co/0Phno5nHFL
📺 https://t.co/phFB0kEh1O

[Adam Prout @a_prout]

@saisrirampur @kellabyte I'm talking specifically about the setup you benchmarked (No Postgres HA when running on local disks). Using HA on local NVMe disks is just fine. You did not benchmark that.

[Adam Prout @a_prout]

@iavins Strong +1 on including durability guarantees. The folks doing single node Postgres on NVMe benchmarks with no HA and comparing that to systems running on remote disks with 5 9's or more durability need to be much clearer on the trade-offs (100x higher chance of data loss)

[Adam Prout @a_prout]

@saisrirampur @kellabyte A remote disk (EBS, Aurora storage, neon storage) will be 5 9's durable at least, a local disk will be 2 9s.

[Adam Prout @a_prout]

@saisrirampur @kellabyte Yes, you didn't hide it, your just not upfront about the harsh trade-offs with data loss risk in your setup. There is a big difference in durability guarantees between the local disks your using vs the remote disks used by everyone your comparing against (EBS, etc.).

[Adam Prout @a_prout]

@saisrirampur @kellabyte hmm.. this from the folks at Clickhouse who published a Postgres benchmark that runs vs locally attached disks with no high availability. That is far more egregious than this Lakebase article. Database customers typically care about not losing data...

[Adam Prout @a_prout]

If you're interested in:
- how databases (and database services) are built
- how building a database service at a startup compares to doing it at big tech
- how Postgres vs MySQL vs SQL Server are different/same (I've work on/around all three!)

come check this out!

[Claire Giordano ✨ @clairegiordano]

Looking forward to talking to database architect Adam Prout @a_prout today/Wed 6 May at 10am PDT on the #TalkingPostgres podcast!

Ep39 topic: From MemSQL to HorizonDB, an engineer's journey
Where? Live on the Microsoft Open Source Discord. Join us: https://t.co/bDl2ESnANl

[Adam Prout @a_prout]

Agents are great testers and bug fixers if focused on this work. For code bases with a high quality bar (databases) and massive test suites, agents root causing bugs and proposing fixes is a big time saver. I hope they keep improving as testers!

https://t.co/G0XrlbRo0z

[Glauber Costa @glcst]

It is personal now. I have a new archenemy. I was having a great time at @AntithesisHQ's conference (the lineup for this year is fantastic), but then @carlsverre ruined my day. I hate that guy now.

How? he told me about Hegel, and then I ended up spending the whole day fixing stuff. Carl might have saved me some 3 months of work. But he ruined my day.

Can I ever forgive him? Read more 👇

[Adam Prout @a_prout]

@iavins LSMs typically have a WAL log to make the in-memory layer durable don't they? It's a simpler log vs a B-Tree, but still around. I haven't done a broad study of LSMs, but MemSQL/Singlestore did things this way and so does RocksDB

[Adam Prout @a_prout]

@wegrydnn Andy usually puts them online within a few days.

[Adam Prout @a_prout]

Representing team Postgres... I'll talk about some of the changes we've made to Azure (and to Postgres) to improve the performance/reliability/security of running PostgreSQL in the cloud.

[CMU Database Group @CMUDB]

Today's Postgres vs. World Seminar Speaker: Adam Prout (@a_prout) will present the architecture of the newly released Microsoft Azure HorizonDB. Zoom talk open to public at 4:30pm ET. YouTube video available after: https://t.co/fJ2XE2AXZP

[Adam Prout @a_prout]

@eatonphil It's a good for the MySQL community. That said they're a VC backed startup that will (eventually) be under some pressure to deliver VC-level returns ($$ Billions with a B). I'm not sure how that will work out...

[Andy Pavlo (@andypavlo.bsky.social) @andy_pavlo]

Spring 2026 @CMUDB Seminar Series: PostgreSQL vs. The World
https://t.co/OyvsAfGA4a
Starts Mon Feb 2nd @ 4:30pm EST. We will alternate between a speaker from either a @Postgres DBMS or a non-Postgres DBMS.
Open to the public over Zoom. All videos available on YouTube afterwards.