jorangreef

Ah thank you! (and for posting!)

That’s the dream. To serve the world’s transactions and data (with a whole lotta beetles!). We’re working to make it reality.

Appreciate the congrats! You make today a double whammy! :P

Ah it’s a pleasure. It’s our experience, and happy to share.

Let’s answer that when we’re there!

They really don’t work for us. The quality is just so poor.

We still write, read (and have an independent engineer review) each line of code by hand.

We go faster like that, but, most of all, it’s the guarantee we make to our users, also to continue to invest in our own understanding, because second order that’s valuable for the kind of high performance safety work we do.

Long term, I’m sure LLMs will improve, but right now they’re just not there.

Hey Joos, ah appreciated!

I'd check out tigerstyle.dev, pick up Zig, and then make an HTTP server or file format parser. Those are great ways to learn and experience this kind of programming. At some point, you start to realize that it's just easier to build API services in this way.

But for sure, you can learn so much in JVM-based languages. They make you appreciate low-level techniques all the more!

If you give the TigerBeetle client a single transfer, it sends it off immediately to the cluster. There's no delay. No Nagle!

But if your application then creates another transfer against the client, and another, while the first request is inflight, then the client will autobatch under the hood and send these off as a batch when the first request returns.

You get this sweetspot then between latency and throughput. And your latency is not spiking as your load increases, since your throughput is now able to keep up.

Thanks! Watch IronBeetle too on Twitch if you’d like to go really deep.

No, the LSM in TB is generalizable at comptime to any combination of power of two sized key/value tuples.

Thanks! We use streaming data structures.

For example, if you take a look at our LSM compaction, regardless of the table size, we compact at the 512 KiB block granularity, and everything is streaming.

The same principle applies everywhere.

In our experience writing TigerStyle (and for all our internal code and tooling, not only TB as DBMS), we’ve never had a scenario where static allocation was not applicable or didn’t produce a better design.

You also tend to become more memory efficient, not less. Again, since you’re streaming. (You’re not allocating a massive buffer, just because a file is multi-GiB.)

This was always the plan, and if you look closer at VSR and the state machine interface you’ll see it’s already pluggable. We just haven’t packaged it. (We’re dogfooding our first few internal “CustomBeetles” before we package and document.)

Joran from TigerBeetle here! I created TB. Happy to answer questions!

TB was designed to track stock inventories (as another form of double-entry accounting).