Live data from Hacker News

TigerBeetle is a most interesting database

amplifypartners.com

111–120 of 228 posts

Re: TigerBeetle is a most interesting database

#111
post #77

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

[deleted]

Re: TigerBeetle is a most interesting database

#114
post #44

Earlier quoted context omitted.

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

>Traditional SQL databases hold locks across the network; under Amdahl's Law, even modest contention caps write throughput at ≈100–1,000 TPS In fact large real world systems are not limited to 100-1000 TPS, or even 10 kTPS as the calculator tries to suggest. That's not because Amdahl's law is wrong, the numbers you're plugging in are just wildly off, so the conclusions are equally nonsensical. There might be some spe…

This whole page, and their response in this thread, is about tigerbeetle as a transaction processing database - e.g. financial transaction processing

I think this is very clear, I don't know why you're saying that tigerbeetle is trying to make a generic claim about general workloads

The comment you're replying to explicitly states that this isn't true for general workloads

Re: TigerBeetle is a most interesting database

#115

> Deterministic Simulation Testing (DST) feels like the most transformational technology that the fewest developers know about. It’s a novel testing technique made popular by the FoundationDB team It's not novel. That's how hardware (ASIC) testing has been done forever. The novelty is applying it to software. > TigerBeetle’s VOPR is the single largest DST cluster on the planet. It runs on 1,000 CPU cores Only if you…

Leading edge photo mask synthesis is easily in the top 5 most computationally demanding things out there. You need an actual supercomputer to solve these problems on meaningful (competitive) timescales.

https://en.wikipedia.org/wiki/Optical_proximity_correction

Re: TigerBeetle is a most interesting database

#116
TigerBeetle is plenty interesting, though if half of SpacetimeDB's [1] [2] claims are true, it's even more interesting for me. (The title of this post has "_a_ most interesting database", while the article has "_the_", hence this comment)

[1] - https://spacetimedb.com/ [2] - https://www.youtube.com/watch?v=kzDnA_EVhTU&

Re: TigerBeetle is a most interesting database

#117
post #78
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?

That a semantic we've all just sort of inherited from C - I don't know we're required to be bound by it forever. The word itself doesn't imply that assertions would be contextually disabled.

Re: TigerBeetle is a most interesting database

#118
post #67
post #54

Earlier quoted context omitted.

Its a financial database built for use cases where this invariant holds and built for enabling new use cases where this invariant prevented businesses from expanding into new industries. The creator says as much: > Without much sweat for general purpose workloads.

Having a niche and expanding into new industries are all fine, there is no problem with having a DB filling a particular sub-segment of the market. But writing that traditional SQL databases cannot go above these "100-1000 TPS" numbers due to Amdahl's law is going to raise some eyebrows.

He clearly says this is in the context of "transaction processing" in the comment you're responding to.

Re: TigerBeetle is a most interesting database

#119

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

Yeah, SQL is not the issue. At least not mostly. The relational model has shown itself to be exactly the flexible and powerful model that Codd said it was, even in its relatively-debased from in SQL. In fact the potential of it as a universal and flexible data model that abstracts away storage still remains to be fully unlocked. Now as for existing SQL databases, yes, many of them were built on foundational assumptio…

> Throwing out SQL is not really the recipe for "performance"

We've discovered hacks to work around the limitations of SQL, so you can maintain performance with sufficient hackiness, but you have to give up "purity" to get there. Worse is better applies, I suppose, but if we were starting over today the design would be very different.

Throwing out SQL isn't strictly required, but like Rust isn't strictly required when you already have C, sometimes it is nice to take a step back and look at how you can improve upon things. Unfortunately, NoSQL turning into a story about "document databases" instead of "A better SQL" killed any momentum on that front.

Re: TigerBeetle is a most interesting database

#120
post #73

Earlier quoted context omitted.

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.

You’re right that it would run on a block chain, but that fact would primarily exist to power some marketing. Everybody would end up interacting with it through a single centralized web site and API because it’s the only usable way to get it to work.
Post reply on HN