Re:It's Time to Stop Building KV Databases
by porridgeraisin on Monday March 24, 2025 @11:53PM
(#43467978)
+1.
Indexes, triggers (very good abstraction covering everything from computed fields to dependent fields), transactions.
Use foundationdb then
A K-V store by construction has an index (over K). But you seem to also want referential integrity and transactions, not small features, limiting the implementation quite a lot.
You can attain what you desire by using an RDBMS, and having all tables with one key column, and a TEXT column with your serialized non-key fields; it's going to be a fun approximation of 6NF. Realistically, you can have all joinable columns as normal columns, indexed as you desire, and the rest of the columns as a serialized blob.
When you want high parallelism for guaranteed independent segments of data, use sharding.
Let database enforce serialization format (JSON, BSON, MessagePack, protobuf.. anything really) + create and maintain indices, using this fancy crash-proof logic it has. That'll cover 95% of all my database needs.
(OP also asks for row-based layout, types, and non-trivial language. I think those parts are entirely optional)