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

141–150 of 228 posts

Re: TigerBeetle is a most interesting database

#141

Post by Xelbair »

slightwinder wrote: post #124
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.

Isn't DNS a catastrophic clusterfuck which also had to be patched up multiple times to not allow people burning down the whole world? I mean, yes, it's doing its job, but mainly because of people doing their job.

Quite the opposite: as it designed in a way that it could be patched and extended, while also being performant.

Re: TigerBeetle is a most interesting database

#142

Post by mkleczek »

While TigerBeetle way is very interesting I find lack of multicore processing support (or any kind of horizontal scaling) a blocker in terms real world deployment.

It is just too risky as there is a hard limit to scalability and while it might look it is high enough for foreseeable future, what am I supposed to do once I reach this limit? Financial database has to be planned with at least 15-20 years of growth in mind.

Re: TigerBeetle is a most interesting database

#143

Post by andrewl-hn »

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

> the only reason FDB isn't massively popular

The only reason is Apple. They liked the product that was released in 2013 so much they bought the whole company, and all other FoundationDB users were abandoned and were forced to drop it.

Who would trust a database that can be yanked out of you at any moment? Though a lot of products have license terms like this only a handful were ever discontinued so abruptly. It's under Apache license now but the trust is not coming back.

Re: TigerBeetle is a most interesting database

#144

Post by yomismoaqui »

sgarland wrote: post #97
yomismoaqui wrote: post #89

Earlier quoted context omitted.

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.

I don’t even think it’s memory, it’s lack of experience. A lot of the battle-tested infrastructure is now abstracted away to the point that a lot of devs are hard-pressed to explain the difference between AWS’ ALB and NLB, much less name OSS versions of them. Actually, load balancers are a great example. The number of times I’ve seen a team re-implementing HAProxy, but poorly, is entirely too high. The reasoning is a…

True, the only right answer for a question like "Should we use X here?" is "It depends". Maybe NIH is the right answer in some specific case but not on another that seems quite similar to the first.

Some months ago I was re-enlightened when Anders Hejlsberg (creator of C# and TypeScript) explained why they chose Go for reimplementing the TypeScript compiler, instead of using any of those languages or something like Rust.

The way they defined the problem, the tests they did and how they justify their pick is how these kind of decisions should be made if we want to call ourselves engineers.

Re: TigerBeetle is a most interesting database

#145

Post by andrewl-hn »

ksec wrote: post #87
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?

Apple bought them, took it down from the web, then quietly open-sourced it a few years later. They tried to make it popular, ran a conference for it, but the adoption was too minor for Apple to care afterwards.

It's still maintained by a sizable team at Apple, GH stats show that the activity is much lower now than it was 3 years ago, but there're about 10 people that contribute on a steady regular basis, which is honestly better than 99% of open source projects out there.

Re: TigerBeetle is a most interesting database

#146

Post by pluto_modadic »

jorangreef wrote: post #33
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.

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

So, the pitch for TigerBeetle is... "you can do database schemas wrong and we're performant enough"? (and also we don't have auth)

Re: TigerBeetle is a most interesting database

#147

Post by samlambert »

sgt wrote: post #14
ViewTrick1002 wrote: post #8

Earlier quoted context omitted.

With the bounds capped by a single writer. Unless you can shard the data and create a distributed database with manual sharding. But yes. Postgres remains an amazing choice, especially with modern hardware, until you also have the money available to tackle said write throughput issue.

I think the point is that sharding won't really help that much since transactions will happen across all or most shards, and then you have certain accounts that will be more active than others.

if your sharding schema is designed properly you will avoid cross shard transactions.

Re: TigerBeetle is a most interesting database

#148

Post by justinclift »

cma256 wrote: post #75
justinclift wrote: post #32

Earlier quoted context omitted.

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

How familiar are you with MVCC?

https://www.postgresql.org/docs/current/mvcc-intro.html

Asking because needing a lock for changing a row isn't the only approach that can be taken.

Re: TigerBeetle is a most interesting database

#149

Post by wiradikusuma »

jorangreef wrote: post #107
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…

You should chat to our solutions team, who'd be able to help you solve auth etc. at the logical level with end-to-end encryption, something we typically do for our customers.

I might not be able to afford paid support yet since it's just PoC, but if it's okay to be public, could they respond to the GitHub issue instead so it can benefit others? https://github.com/tigerbeetle/tigerbeetle/issues/3073

Re: TigerBeetle is a most interesting database

#150

Post by theYipster »

Looking at the Zig vs. Rust angle — an interesting takeaway from the article is that Zig makes it considerably easier to build statically allocated applications than Rust.

For all of Rust’s talk about “safety”, assuming the above assertion is true, than perhaps Zig is a better choice to augment or replace C in embedded, safety-critical software engineering, where static memory allocation is a core principle.

Post reply on HN