> the real irony is that RDBMS are all built on fast k:v stores :)

Not if the RDBMS is a column store. Or if the storage model is based on log-structured merge trees. There are many ways to map the relational model to storage. Even for the traditional row-oriented case in InnoDB there are structures like B+-tree indexes that do not directly correspond to a K:V store.

The real point is that you don't want to reimplement a poor, ad-hoc RDBMS inside your application.

What do you mean, a filesystem?

Pretty much all RDBMSs can be considered a set of key-value collections, and their storage backends often conceptually are pretty much that. Assuming a row-oriented storage engine, a simple approach is:

* A main key/value collection consisting of primary key (key) mapping to a serialization of the row (value)

* One key/value collection per index consisting of each index function applied to the row (key) mapping to the primary key (or some internal object id; the value)

It's a bit of a simplification as an RDBMS needs to maintain a sort-order and allow e.g. range queries, and need interfaces that allow reading/writing lots of rows with low per-row overhead, and so it's not that they'd be a good match for just any key-value store.

I think it's a reference to RocksDB, and maybe also InnoDB

I’m not sure what you mean? Aren’t most databases built on assumptions of continuous disk space mapped by indexed arrays? How does k:v fit into the picture?

The most common high-level use of a DBMS is the pair "given this key, get me the record that is its value" and "store this record under a new key". It's not exactly equal to the usual k:v usage (because it uses meaningless keys), but it's very similar.

That said, I don't think this is the usage scenario most DBMS are optimized for, because despite being common, it's a very fast case, so there is relatively little to gain. At the same time, this is the only usage of k:v storage, so you bet it's optimized for that.