Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TigerBeetle is a most interesting database

amplifypartners.com

Post reply on HN
Print view View original

71–80 of 228 posts

Re: TigerBeetle is a most interesting database

#71

Post by matklad »

mcherm wrote: post #37
flir wrote: 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.

Yeah, there's actually trickiness here. Another curveball is that, with simulation testing, you generally want more assertions to catch more bugs, but slow assertions can _reduce_ testing efficiency by requiring more CPU time per iteration! But then, if you know, at comptime, that the list is going to be short, you might as well do O(N^2) verification!

We captured these consideration in the internal docs here: https://github.com/tigerbeetle/tigerbeetle/blob/0.16.60/src/...

Re: TigerBeetle is a most interesting database

#72

Post by looperhacks »

seemaze wrote: post #46
Xelbair wrote: post #38

Earlier quoted context omitted.

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.

What would DNS look like if it were released in 2025?

Certainly a JSON-based REST API that is not really RESTful just so that people can complain about it

Re: TigerBeetle is a most interesting database

#73

Post by TZubiri »

Something1234 wrote: post #49
seemaze wrote: post #46

Earlier quoted context omitted.

What would DNS look like if it were released in 2025?

It would be completely centralized with a micropayment rent seeking solution to update records.

Nono, it would run decentralized in blockchain with a mircropayment rent seeking solution to update records.

Re: TigerBeetle is a most interesting database

#74

Post by itunpredictable »

bell-cot wrote: post #22

Consider re-titling it "A very cool & interesting article about a very boring & reliable database"? Since "interesting" is the very last thing that anyone sane wants in their accounting/financial/critical-stuff database.

looks like the poster agrees

Re: TigerBeetle is a most interesting database

#75

Post by cma256 »

justinclift wrote: post #32
jorangreef wrote: post #18

Earlier quoted context omitted.

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. :)

Node count doesn't matter. You could use an embedded database and encounter the same problem. There is some time T between when you acquire a lock and release it. Depending on the amount of contention in your system, this will have some affect on total throughput (i.e. Amdahl's law).

Re: TigerBeetle is a most interesting database

#76

Post by oblio »

websiteapi wrote: post #19

All of these apply to FoundationDB as well. - Slow code writing. - DST - No dependencies - Distributed by default in prod - Clock fault tolerance with optimistic locking - Jepsen claimed that FDB has more rigorous testing than they could do. - New programming language, Flow, for testing. You probably could solve the same problems with FDB, but TigerBeetle I imagine is more optimized for its use case (I would hope...)…

> AFAIK - the only reason FDB isn't massively popular is because no one has bothered to write good layers on top. I do know of a few folks writing a SQS, DynamoDB and SQLite layers.

I started writing this comment:

> It seems interesting, but considering what it's for, why aren't the hyperscalers using it?

And while writing it I started searching for FoundationDB and found this:

> https://github.com/>/foundationdb

Ah, all right :-p

Re: TigerBeetle is a most interesting database

#77

Post by caust1c »

wiradikusuma wrote: post #20

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…

Wait, what? A database in 2025 doesn't support any kind of auth? A financial database? WTF?

C'mon folks, the least you can do is put a guide for adding an auth proxy or auth layer on your site.

Particularly since you don't use HTTP (cant easily tell from the docs, I'm assuming), then folks are going to be left wondering: "well how the hell do I add an auth proxy without HTTP" and just put it on the open internet...

Re: TigerBeetle is a most interesting database

#78

Post by TZubiri »

flir wrote: 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).

Because the very raison d'etre of asserts is to be a compile time/test time check. If you wanted them to run in production, you wouldn't use an assert, you would just run an if. Otherwise what's an assert to you? A mildly convenient sugar syntax alternative to if statements?

Re: TigerBeetle is a most interesting database

#79

Post by xnzm1001 »

I work at a bank with old old monstrous sql queries. I thought I can make a use of tigerbeetle to simplify the system. But sadly, I just couldn't figure out how to make it work. Transaction requires lot of business logics but I couldn't convert that to make it work with combination of RDBMS + tigerbeetle. I wish there were some realworld example that I can get insight using tigerbeetle.

Re: TigerBeetle is a most interesting database

#80

Post by sgarland »

While I am a fan of TigerBeetle’s general stance on correctness, coding practices, and their desire to hyper-specialize, I have some critiques on the post.

I think the paragraph about multi-node is a bit misleading. Contrary to what cloud native folk will tell you, a single beefy DB, well-tuned and with a connection pooler, can serve a dizzying amount of QPS just fine. At a former employer, during a maintenance period, I once accidentally had all traffic pointed to our single MySQL 8 RDS instance, instead of sharing it between its read replicas. That was somewhere around 80-90K QPS, and it didn’t care at all. It wasn’t even a giant instance - r6i.12xlarge - we just had a decent schema, mostly sane queries, and good tuning on both ProxySQL and MySQL. At peak, that writer and two .8xlarge read replicas handled 120K QPS without blinking.

A DB hosted on a server with node-local NVMe (you know, what used to be normal) will likely hit CPU limits before you saturate its I/O capabilities.

For redundancy, all RDBMS designed for networked activity have some form of failover / hot standby capability.

My other mild criticism is in the discussion on TigerBeetle’s consensus: yes, it seems quite clever and has no other dependencies, but it’s also not trying to deal with large rows. When you can fit 8,190 transactions into a 1 MiB packet that takes a single trip to be delivered, you can probably manage what would be impossible for a traditional RDBMS.

None of this should be taken as belittling their accomplishment; I remain extremely impressed by their product.

Post reply on HN