Hello, the developer of db9 here. You’re right, that section is indeed a bit too brief. We will add more architecture documentation later. What I wanted to convey is that, unlike a standard PostgreSQL, db9 is more like a pg SQL-compatible layer built on top of a large distributed KV store. I also shared a brief introduction in this tweet, which might help clarify things. https://x.com/dxhuang/status/2032016443114733744

Doltgres actually is a true versioned Postgres under the hood (or MySql).

This sounds really interesting, and I like the ease with which I could spin something up here and get embeddings for sure! But I would think the actual runtime perf of this would be “fine” for some text, but nowhere near Postgres level for all sorts of other stuff, right?

I am a huge fan of Postgres as a database, and of SQL, etc. but I don’t think I understand the benefit of using Postgres’ wire format here since it’s not Postgres behind the scenes. I guess that lets you use psql as the client?

This is really interesting! Thanks

yes, it’s quite a journey

AI is an instant turnoff and should be banned from HN. Unfortunately it is artificially promoted because of @sama despite not only providing no value but also making the world worse.

Fixed by our agent. Thank you!

The "throw everything in Postgres" angle ignores how bad most DBs are at large-object lifecycle ops like bulk deletion, partial reads, and massive tree renames. Put a million big blobs in there and backup, restore, and replication get ugly.

People also skip over fast atomic moves and concurrent edits across deep hierarchies, which is exactly where a file system earns its keep instead of pretending SQL is a universal storage layer. If uptime and ops sanity matter, you usually bolt one on anyway.

PG SQL is my favorite for many reasons after working with the other two for a decade+ at times. I can turn it into whatever database I want it to be, ultimately.