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

81–90 of 228 posts

Re: TigerBeetle is a most interesting database

#81

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

And a more serious comment, to separate it from the silly one below:

Interesting that they didn't release it with an SQL client, is there no way to make it compatible? Even with extensions to SQL, I imagine it would be great for a lot of use cases.

Edit: ah, it's more of a key-value store.

Re: TigerBeetle is a most interesting database

#82

Post by porridgeraisin »

TigerBeetle looks interesting. A whole networked database using statically allocated memory. I usually use that technique for small keyboard-shortcut triggered applications.

One question in case folks who work there see this:

This is the most technically impressive zig project I've seen so far. Do you have a blog post detailing your perspective on zig? i.e what design decisions of ziglang helped you in massive way, what were the warts, and in general any other thoughts too?

Re: TigerBeetle is a most interesting database

#83

Post by ksec »

>Most teams write code fast. TigerBeetle tries to write code slow. Most teams treat testing as a necessary evil. TigerBeetle is built entirely on Deterministic Simulation Testing (DST). Most teams build their software on top of loads of other software. TigerBeetle has zero dependencies.

I believe that was more like the norm 25+ years ago. Before Google and Facebook brought in the move fast and break things mentality across software industry.

I hope TigerBeetle gets more recognition. Worth reading its Jepsen report as well. https://news.ycombinator.com/item?id=44199592

Re: TigerBeetle is a most interesting database

#84

Post by WhitneyLand »

cma256 wrote: post #54
tux3 wrote: post #44

Earlier quoted context omitted.

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

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.

You’re changing the subject to the company’s mission when the concern was about a specific claim made.

Re: TigerBeetle is a most interesting database

#85

Post by dangoodmanUT »

I really like the work Joran and his team have done around DST, distributed systems awareness, and performance practices. I especially love the craziness around no dependencies (well, could you consider an underlying OS a dependecy?).

But I've always felt the way they treat normal OLTP (they call OLGP) seems unfair. For example, comparisons using clear sub-optimal interactive SQL transactions for financial workloads, like locking rows rather than using condition checks at commit time, because "that's how OLTP was intended to be used when it was designed ~50(?) years ago".

In their cited https://tigerbeetle.com/#performance the lowest the slider can go is 1% contention. Do you think Stripe has 1% contention directly on an OLTP DB? Definitely not.

You can build systems that _expect contention_, and elegantly handle it at REALLY high throughput. These systems protect the DB from contention, so you can continue to scale. From talking to folks working on these systems, I roughly know the kinds of transactional (financial) throughput of DBs like Stripe's and other systems - they have _many_ more zeros behind them than their performance comparison page proposes they could possibly have at even 0.01% contention.

Their marketing largely ignores this fact, and treats everyone like they just slam the DB with junior engineer-designed interactive transactions. Most developers (I hope) are smarter than that if they're working at a payments company. There's even the title "payments engineer" for the kind of person that's thinks about scaling contention and correctness all day.

TigerBeetle is great, but I find the pattern of being quite misleading about other OLTPs off putting.

Re: TigerBeetle is a most interesting database

#86

Post by moffers »

jorangreef wrote: post #18
justinclift wrote: post #15

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.

TB seems really awesome, but is there non-DebitCredit use cases where it can be applied effectively? I like trying to find off-label uses for cool technology

Re: TigerBeetle is a most interesting database

#87

Post by ksec »

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

I thought they got bought by Apple and what happened to it after?

Re: TigerBeetle is a most interesting database

#88

Post by big_hacker »

jorangreef wrote: post #9
BrentOzar wrote: post #3

Because I'm sure other people will ask - no, it does not support SQL.

Joran from TigerBeetle here! 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 Distribute…

What's it like compared to Redis or even KeyDB?

Re: TigerBeetle is a most interesting database

#89

Post by yomismoaqui »

justinclift wrote: post #13

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

Are you telling me that new shiny things are not always better that established, time tested and boring tech?

Sometimes I feel like we software engineers have the worst memory of any engineers.

Re: TigerBeetle is a most interesting database

#90

Post by flir »

TZubiri wrote: post #78
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?

> A mildly convenient sugar syntax alternative to if statements?

Yup.

Post reply on HN