I mean, so are the relational databases. Rocks provides similar storage primitives - trees - as most databases implement internally.

Postgres is “just” a SQL engine running on top of a key-value heap and trees pointing into it.

Neo4j is the same, key-value record store plus trees.

Rocks and it’s peers have made that into a dependable library, making new db dev that much faster :)

> Postgres is “just” a SQL engine running on top of a key-value heap and trees pointing into it.

I wouldn't call heaps a key-value data structure; even if you could argue that the location of your data is an implicit key. And the trees are strictly optional - you could build your database with only hash and brin indexes.

Yeah agree, I had the same thought after I wrote that comment “wait dumbass, you don’t get to pick the key in the heap, it’s not the same”.

But still, you get what I’m getting at: in the end, the relational dbs, internally, build on top of abstractions that are things like trees, key-value structures, heaps, logs etc.

It’s my understanding that row-based relational databases are basically key-value stores that map from row ID to column values. The “magic” of SQL-based relational databases is how the KVS is queried, and the consistency guarantees they provide.

Part of the consistency guarantees is having a reliable storage engine. That’s the value RocksDB provides.

The rest of the “SQL stuff” can be built on top this.

It seems fairly well shown that the "SQL stuff" can be build on top of it on the server side.

Building the "SQL stuff" on the client side seems less well proven to me.