Live data from Hacker News

TigerBeetle is a most interesting database

amplifypartners.com

31–40 of 228 posts

Re: TigerBeetle is a most interesting database

#31

Pretty much agree, I honestly think that TB team should invest some more effort on evangelizing the double-entry model for non-financial scenarios, like managing stocks, booking a show ticket etc. The 1000x API improvement has been done, now people must know how to use it

It sounds awesome. I'm an a analytics guy using a lot of SQL - not a coder. Though I understand the OP writeup and the purported performance advantages. Can someone explain:

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 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?

Re: TigerBeetle is a most interesting database

#32

Earlier quoted context omitted.

> which kills SQL row locks. What's it like compared to MVCC?

Depending on contention and RTT, as a specialized OLTP DBMS, TB can do roughly 1000-2000x more performance than a single node OLGP DBMS (cf. the live demo in the talk above)… but also with strict serializability. You don’t need to sacrifice correctness or real-time resolution, and that’s important. For example, if you need to do real-time balance checks.

Hmmm, I guess it sounds weird to me to be talking "RTT" (round trip time) when the example is "a single node".

I'll watch your talk properly at some point and see if it makes sense to me after that. :)

Re: TigerBeetle is a most interesting database

#33

> In less than a decade, the world has become at least three orders of magnitude more transactional. And yet the SQL databases we still use to power this are 20-30 years old. Can they hold up? Errr yes. Without much sweat really. Just because something started ~30 years ago doesn't mean it hasn't updated with the times, and doesn't mean it was built on bad foundations.

Joran from TigerBeetle!

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/#general-purpose-databases-have-an-o...

Re: TigerBeetle is a most interesting database

#34
post #27

> In less than a decade, the world has become at least three orders of magnitude more transactional. And yet the SQL databases we still use to power this are 20-30 years old. Can they hold up? Errr yes. Without much sweat really. Just because something started ~30 years ago doesn't mean it hasn't updated with the times, and doesn't mean it was built on bad foundations.

I disagree. If we are talking about distributed systems in which we have N different databases, then distributed transactions are left as an exercise to the reader (that’s why we have things like Sagas). Within a single machine, yeah, relational dbs still work like a charm.

The other interesting thing to consider is that machines are a lot more powerful in all dimensions than they were 30 years ago - so many tasks that would have required distributed systems no longer do.

Re: TigerBeetle is a most interesting database

#35

We were considering TigerBeetle, but found blockers: * We use Cloudflare Workers. TigerBeetle client app is not supported. It might work using Cloudflare Containers, but then the reason we use Cloudflare is for the Workers. --> https://github.com/tigerbeetle/tigerbeetle/issues/3177 * TigerBeetle doesn't support any auth. It means the containing server (e.g. a VPS) must restrict by IP. Problem is, serverless doesn't h…

But Cloudflare Workers or AWS Lambda setup would not work anyway with any db?

* 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

Re: TigerBeetle is a most interesting database

#36
post #27

Earlier quoted context omitted.

I disagree. If we are talking about distributed systems in which we have N different databases, then distributed transactions are left as an exercise to the reader (that’s why we have things like Sagas). Within a single machine, yeah, relational dbs still work like a charm.

The other interesting thing to consider is that machines are a lot more powerful in all dimensions than they were 30 years ago - so many tasks that would have required distributed systems no longer do.

DBMS design has also changed. The bottleneck for a DBMS has moved from spinning disk to CPU and per core memory bandwidth. That's also key to TigerBeetle's design. For example, with static allocation and zero-copy techniques such as zero-deserialization.

If you were to design an OLGP DBMS like Postgres today, it would look radically different. Same is true for OLTP.

Re: TigerBeetle is a most interesting database

#37
post #23

> They keep assertions enabled in production. Never understood why we turn those off. An assert failing in prod is an assert that I desperately want to know about. (That "never understood" was rhetorical).

I like to write assertions that aren't always easy to check. Like asserting that a list is sorted.

Re: TigerBeetle is a most interesting database

#38

> In less than a decade, the world has become at least three orders of magnitude more transactional. And yet the SQL databases we still use to power this are 20-30 years old. Can they hold up? Errr yes. Without much sweat really. Just because something started ~30 years ago doesn't mean it hasn't updated with the times, and doesn't mean it was built on bad foundations.

DNS still runs strong and it was ~~designed~~ released* in the November 1983.

It still holds up basically whole of internet.

in most cases SQL is good enough for 90% of workloads.

Re: TigerBeetle is a most interesting database

#39
post #37
post #23

> They keep assertions enabled in production. Never understood why we turn those off. An assert failing in prod is an assert that I desperately want to know about. (That "never understood" was rhetorical).

I like to write assertions that aren't always easy to check. Like asserting that a list is sorted.

That sounds easy to check. Can you expand on this, because I don't understand.

Re: TigerBeetle is a most interesting database

#40
post #7

Earlier quoted context omitted.

They both have replication, which allows them to be multi-node.

With the bounds capped by a single writer. Unless you can shard the data and create a distributed database with manual sharding. But yes. Postgres remains an amazing choice, especially with modern hardware, until you also have the money available to tackle said write throughput issue.

TigerBeetle doesn't shard either.
Post reply on HN