> db9 is a PostgreSQL-compatible distributed SQL database. Your data is stored in a distributed TiKV cluster, and each database (tenant) gets its own isolated keyspace. [0]
I feel like the lede is a bit buried here, bordering on deceptive.
That or the architecture doc is wrong. Both plausible I guess, in this day and age.
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
"Compatible" isn't mentioned on the homepage, though, despite multiple opportunities to do so -- "Create, manage and query serverless PostgreSQL", "Run history, status, and metadata live in Postgres", "Full Postgres. Fully typed.".
This lack of detail may cause folks to form the incorrect impression that this is PostgreSQL, or a fork of it, or some module or plugin for it. Folks will be upset to learn that they were misinformed. Some will assign deception as the cause, whether that is true or not.
I think your interests would be best served by trying to make that distinction clear and prominently so. So for example "A PostgreSQL-compatible, fully serverless database", or similar.
it has nothing to do with TiDB, db9 is built from scratch.A good way to think about it is that db9 is similar to tidb-server, it provides a PostgreSQL wire protocol and SQL layer, while the actual data lives in the underlying KV layer.
If it is based on TiKV, why is it built from scratch when TiDB exists? To achieve faster boot times? I think the bigger offering here is distributed-, not serverless Postgres!
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?
PG compatible means if you built your application or analytics queries for PG SQL, it's very easy to migrate to XYZ database that takes PG SQL as input and returns the same results in most cases. The wire format means you can point your code at the database and get the same responses as normal SQL.
I agree with the commentary above that it's much clearer to describe something as "PG SQL/wire format compatible".
I think what’s really interesting is that the first version of db9.ai is done by a single person by commanding AI. There must be tons of invaluable lessons learned.
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.
I like the idea of combining the file system and the database. It's really useful when people don’t want to manage files and structured data separately.
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.
> db9 is a PostgreSQL-compatible distributed SQL database. Your data is stored in a distributed TiKV cluster, and each database (tenant) gets its own isolated keyspace. [0]
I feel like the lede is a bit buried here, bordering on deceptive.
That or the architecture doc is wrong. Both plausible I guess, in this day and age.
[0] https://db9.ai/docs/sql
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
"Compatible" isn't mentioned on the homepage, though, despite multiple opportunities to do so -- "Create, manage and query serverless PostgreSQL", "Run history, status, and metadata live in Postgres", "Full Postgres. Fully typed.".
This lack of detail may cause folks to form the incorrect impression that this is PostgreSQL, or a fork of it, or some module or plugin for it. Folks will be upset to learn that they were misinformed. Some will assign deception as the cause, whether that is true or not.
I think your interests would be best served by trying to make that distinction clear and prominently so. So for example "A PostgreSQL-compatible, fully serverless database", or similar.
I hope I have explained better.
If you're using TiKV why not use TiDB too, which is MySQL compatible?
it has nothing to do with TiDB, db9 is built from scratch.A good way to think about it is that db9 is similar to tidb-server, it provides a PostgreSQL wire protocol and SQL layer, while the actual data lives in the underlying KV layer.
If it is based on TiKV, why is it built from scratch when TiDB exists? To achieve faster boot times? I think the bigger offering here is distributed-, not serverless Postgres!
Wonder if that’s what it is, with a few changes to make it postgres wire compatible
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?
PG compatible means if you built your application or analytics queries for PG SQL, it's very easy to migrate to XYZ database that takes PG SQL as input and returns the same results in most cases. The wire format means you can point your code at the database and get the same responses as normal SQL.
I agree with the commentary above that it's much clearer to describe something as "PG SQL/wire format compatible".
You can do the same and a bit more with sqlite through agentfs
https://github.com/tursodatabase/agentfs
This is really interesting! Thanks
I think what’s really interesting is that the first version of db9.ai is done by a single person by commanding AI. There must be tons of invaluable lessons learned.
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.
yes, it’s quite a journey
The carousel overflows on mobile, extending past the screen
Fixed by our agent. Thank you!
It forgot all other locations where the lines are too long to read and you cannot scroll (e.g. the part about embeddings) - from Firefox on Android.
Okay.
I like the idea of combining the file system and the database. It's really useful when people don’t want to manage files and structured data separately.
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.
I've only worked with MySQL, Sqlite up until this year. Started on Postgres since January and I'm seeing how flexible it is.
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.
[dead]