top | item 45436748

(no title)

BrentOzar | 5 months ago

Because I'm sure other people will ask - no, it does not support SQL.

discuss

order

jorangreef|5 months ago

Joran from TigerBeetle here!

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

justinclift|5 months ago

> which kills SQL row locks.

What's it like compared to MVCC?

big_hacker|5 months ago

What's it like compared to Redis or even KeyDB?

karmakaze|5 months ago

It helps to know what kind of data TigerBeetle handles. The data committed by its transactions is an immutable Transfer of id:128-bit, debit_account_id:128-bit, credit_account_id:128-bit, amount:128-bit, ledger:128-bit, code:16-bit, flags:bitfield, timestamp:64-bit, user_data_128, user_data_64, user_data_32.

Transactions atomically process one or more Transfers, keeping Account balances correct. Accounts are also records, their core fields (debits_posted, credits_posted, etc).

This gives a good idea of what TigerBeetle might be good for and what it might not be. For anything where latency/throughput and accuracy really, really matters, it could be worth the effort to make your problem fit.