TigerBeetle is a most interesting database
amplifypartners.com
TigerBeetle is a most interesting database
1–10 of 228 posts
Re: TigerBeetle is a most interesting database
#2Re: TigerBeetle is a most interesting database
#3Re: TigerBeetle is a most interesting database
#4hope you all like this post as much as I enjoyed writing it!
Re: TigerBeetle is a most interesting database
#5Which databases? SQLite is the one I can think of, but it's designed for that use-case. Others start as single node but will replicate to other nodes, either as master-slave or master-master.
Re: TigerBeetle is a most interesting database
#6> And yet some of the most popular OLTP databases in the world today are still highly dependent on a single node architecture. Which databases? SQLite is the one I can think of, but it's designed for that use-case. Others start as single node but will replicate to other nodes, either as master-slave or master-master.
Re: TigerBeetle is a most interesting database
#7> And yet some of the most popular OLTP databases in the world today are still highly dependent on a single node architecture. Which databases? SQLite is the one I can think of, but it's designed for that use-case. Others start as single node but will replicate to other nodes, either as master-slave or master-master.
Postgres, MySQL
Re: TigerBeetle is a most interesting database
#8Earlier quoted context omitted.
Postgres, MySQL
They both have replication, which allows them to be multi-node.
But yes. Postgres remains an amazing choice, especially with modern hardware, until you also have the money available to tackle said write throughput issue.
Re: TigerBeetle is a most interesting database
#9Because I'm sure other people will ask - no, it does not support SQL.
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: