Live data from Hacker News

TigerBeetle is a most interesting database

amplifypartners.com

221–228 of 228 posts

Re: TigerBeetle is a most interesting database

#221

Earlier quoted context omitted.

Give us 27 years—the company only turned 3 last month, and we designed for 30 :) To be clear, TB's pretty young, only 3, but Jepsen-tested and already migrating some of the largest brokerages, wealth managements and exchanges in various countries. I'm excited to see what can be done in 27. ”Slow is smooth, and smooth is fast”

Just to keep the tone I’d like to say I was just joking and that I wish you guys great success! Tiger beetle is amazing!

Haha! Much appreciated, thanks for the kind wishes! (Let's chat again when we're both old!) :)

Re: TigerBeetle is a most interesting database

#222
post #217
post #200

Earlier quoted context omitted.

You're nitpicking the term "journalism" here, but even in casual conversation if a friend went on and on about how great a company was and then I later found out that they: * Got paid a referral fee if I signed up * Owned shares in the company * Even was roommates with the founders/CEO but failed to mention it I would trust that person less going forward. If you want to be perceived as trustworthy, then you shouldn't…

I don’t mean to suggest it’s not sleazy—I think it’s sleazy by default. VC writing is not to be trusted.

Joran from TigerBeetle!

Our investors (Spark, Amplify, Coil) are different to most, in that our partners are all highly technical.

Engineers, coders, CTOs who read the same research papers and attend the same technical conferences (CIDR, VLDB, SIGMOD, HYTRADBOI etc.).

In fact, that's how we met.

Re: TigerBeetle is a most interesting database

#223

The most interesting database is the most boring one.

The problem with "boring", "popular" and "old" is that they are too often synonyms (and logical fallacies, i.e. as an appeal to popularity/authority).

Rather, I would say that the most interesting database is the fastest and safest.

Or as Jim Gray always put it: “correct and fast”.

Re: TigerBeetle is a most interesting database

#224

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

>we just had a decent schema Glad someone mentioned it. In the dev ORM culture now days it is all about how to make the db look like the code. DB is essentially reduced to a object store. Often a proper decent schema can handle most of these load. You can always throw in redis layer later if your traffic is really getting to require that level of optimization.

Re: TigerBeetle is a most interesting database

#225

As nice as TigerBeetle is, do keep in mind that this article is written by an investment company that has invested in TigerBeetle: https://www.amplifypartners.com/blog-posts/our-investment-in...

Keep in mind for what reason? The content doesn't change based on this knowledge. It either stands up for what it is or it doesn't. It wouldn't somehow be better if it were written by a random Joe user instead: It would be the exact same work. Attributing qualities of the author onto the work is a logical fallacy.

Use that precious mind space for understanding basic logic instead.

Re: TigerBeetle is a most interesting database

#226
post #194

Earlier quoted context omitted.

> comparisons using clear sub-optimal interactive SQL transactions for financial workloads, like locking rows rather than using condition checks at commit time Could you give an example of how the same transaction could be written poorly with "locking rows" and then more optimally with "using condition checks at commit time"?

subtract 50 if balance >= 50 is optimistic (the value at commit can be different than at read) vs. "lock this row so it can't change while I subtract 50 from 50,000,000,000,000..." you get the point

I'm more confused now. Those two have different logic? In the second example the balance can go negative.

Also aren't both of those are going to have to lock the row to modify it? Even if you don't explicitly take out a lock on a row the DBMS will do its own concurrency control to provide transaction isolation, which will require a write lock for the row.

Edit: Oh are you saying the "poorly written" case is an interactive transaction where the logic happens in the application code and involves multiple round trips while holding a lock? Instead of a transaction (or maybe even stored proc) where the logic happens in the DB, so less time holding the lock. Less contention. Ah ok. Yeah interactive transactions like that aren't great.

Re: TigerBeetle is a most interesting database

#227

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

Kelsey Hightower gave an interesting talk on this - why understanding fundamentals will always matter more than the recent shiny new trend:

https://youtu.be/Jlqzy02k6B8

Re: TigerBeetle is a most interesting database

#228

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

That a traditional modern RDBMS is very fast is not really useful here because the use case of Tigerbeetle includes work loads with high contention. Under that kind of load, in their own tests you can see in a recent conference talk, you can see the throughput drops dramatically in clusters where many transactions affect a single account. edit: from the horses mouth is better https://news.ycombinator.com/item?id=4543…

It's worth noting that other databases have features designed specifically to address this use case.

Oracle has lock free reservations on numeric columns: https://oracle-base.com/articles/23/lock-free-reservations-2...

Post reply on HN