Yes, this is by design. SQL is a great general purpose query language for read-heavy variable-length string workloads, but TigerBeetle optimizes for write-heavy transaction processing workloads (essentially debit/credit with fixed-size integers) and specifically with power law contention, which kills SQL row locks.

I spoke about this specific design decision in depth at Systems Distributed this year:

1000x - https://m.youtube.com/watch?v=yKgfk8lTQuE

a) what Tigerbeetle data looks like in practice? Assuming it doesn't look like a regular table

b) how you use it, if you can't write sql queries?

c) separately, curious what double-entry would look like for stocks, tickets etc. E.g. I'm a venue and I have 1000 tickets in inventory & deferred revenue.. each time I sell a ticket and equity, and every time I sell one I turn that inventory to cash and the deferred into a performance liability? Or no entries at all until a ticket is sold? Something else?

Within a single machine, yeah, relational dbs still work like a charm.

Without much sweat for general purpose workloads.

But transaction processing tends to have power law contention that kills SQL row locks (cf. Amdahl’s Law).

We put a contention calculator on our homepage to show the theoretical best case limits and they’re lower than one might think: https://tigerbeetle.com/#performance

* spawning 1000 workers all opening a connection to a db,

* solved by service/proxy in front of db,

* proxy knows how to reach db anyway, let's do private network and not care about auth