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...
TigerBeetle is a most interesting database
111–120 of 228 posts
Re: TigerBeetle is a most interesting database
#112Re: TigerBeetle is a most interesting database
#113Re: TigerBeetle is a most interesting database
#114Earlier 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…
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…
Re: TigerBeetle is a most interesting database
#116[1] - https://spacetimedb.com/ [2] - https://www.youtube.com/watch?v=kzDnA_EVhTU&
Re: TigerBeetle is a most interesting database
#117> 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
#118Earlier 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.
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…
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
#120Earlier 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.