The key/value string workload of a general purpose (OLGP) “system of reference” like Postgres is easy to scale… …once you offload the read-modify-write hot integer workload to a transaction processing (OLTP) “system of record” like TigerBeetle. But you also get good architectural principles like “separation of concerns”.

I got into database design thanks to systems like ZFS and Redis. And I remember when Antirez was “staring down the barrel” of building a storage engine for Redis, and then walked away (wisely I believe) from that at the time. But for transacting processing (and for TigerBeetle), I would say “safety is never a tradeoff, but rather a move from local maximum to global maximum”. It’s not XOR (as humans we tend to think too much in terms of XOR instead of OR). If you can apply first principles, to move from local maximum (how things have always been done) to global maximum (the physics optimal way that things should be done) then you get both safety and performance, as was our experience in TigerBeetle. As Jim Gray would say: “correct AND fast”.

The hardest problem in distributed systems (and database design) is hot rows. In other words, serialization w.r.t. data accesses while preserving application correctness (e.g. ACID). But hot rows is also what separates (and accelerates) TigerBeetle from most systems…