In July of 2020, Joran Dirk Greef stumbled into a fundamental limitation in the general-purpose database design for transaction processing. This sent him on a path that ended with TigerBeetle, a redesigned distributed database for financial transactions that yielded three orders of magnitude faster OLTP performance over the usual (general-purpose) suspects.
On this episode, Joran joins Jerod to explain how TigerBeetle got so fast, to defend its resilience and durability claims as a new market entrant, and to stake his claim at the intersection of open source and business. Oh, plus the age old question: Why Zig? :link: https://changelog.fm/635
Ch | Start | Title | Runs |
---|---|---|---|
01 | 00:00 | Welcome to The Changelog | 01:25 |
02 | 01:25 | Sponsor: Augment Code | 03:09 |
03 | 04:33 | Start the show! | 00:44 |
04 | 05:18 | Stumbling into it | 03:10 |
05 | 08:27 | Maybe I did it wrong | 01:13 |
06 | 09:41 | It's the row locks | 01:53 |
07 | 11:33 | Pareto meets the Mag 7 | 02:07 |
08 | 13:40 | Financial, not SQL, transactions | 01:11 |
09 | 14:51 | A specialized database | 03:10 |
10 | 18:01 | Why build yet another database? | 04:55 |
11 | 22:56 | Sponsor: Depot | 02:20 |
12 | 25:16 | Where do you start? | 02:30 |
13 | 27:46 | Who is 'we'? | 01:24 |
14 | 29:09 | 10_000x faster?! | 01:35 |
15 | 30:44 | New world, new constraints | 01:30 |
16 | 32:14 | Row, column, mulit-major | 03:54 |
17 | 36:08 | Multi-row major implications | 05:37 |
18 | 41:45 | Embarrassingly simple | 02:52 |
19 | 44:36 | On durability | 10:28 |
20 | 55:05 | Centuries of testing | 02:12 |
21 | 57:17 | What about real-world use tho | 05:21 |
22 | 1:02:38 | Worst-case scenario logic | 01:17 |
23 | 1:03:55 | Sponsor: Notion | 03:08 |
24 | 1:07:03 | TigerBeetle Simulator | 08:35 |
25 | 1:15:38 | The open source story | 10:18 |
26 | 1:25:56 | Jerod reacts | 00:22 |
27 | 1:26:18 | What about AWS re-hosting | 04:39 |
28 | 1:30:57 | Written in Zig | 05:31 |
29 | 1:36:28 | Redis open source again? | 00:59 |
30 | 1:37:28 | Wrapping up | 00:43 |
31 | 1:38:10 | Closing thoughts | 02:16 |
I don't have any use cases for TigerBeetle in my life, but I respect it
+1, nailed it :grinning_face_with_smiling_eyes:
Interesting thoughts on open source too - a different angle but I _think_ largely compatible with Adam Jacob who is always fun on that topic. Very fun episode :trophy:
(Also, who heard Tiger Style and thought Wu-Tang... and who is lying :sweat_smile: )
Lol I actually thought of Gangnam Style when it was first mentioned but I held myself back from making the reference :sweat_smile:
Hearing Joran's perspective on OSS was my favorite part of this episode. Interface vs Implementation was interesting and not something I'd thought of before, and Kafka/Red Panda/WarpStream is a great example. Now I'm thinking of other examples of this..
The "rising tide" lifts all boats / surfing the wave take was interesting. I'm curious if that POV will change as the proverbial wave crashes, e.g. if AWS does start offering TigerBeetle or make their own version.
Same here! We're turning that part of the convo into a standalone clip because I want more people to hear it and it was at the very end of an hour-plus convo...
Halfway through this and it's really warming the cockles of my performance-loving heart. It's the kind of "optmisation" that sounds super smart to regular old full stack web app developers like me. He says it's as simple as "doing less", but there is so much stuff in a typical app stack that you never realise you can just... not do. And of course, that's enabled by being so use-case-specific.
Another story along the same lines, which I share often despite it being like 3 hours long, is Casey Muratori's "simple code, high performance" video. In it he looks at a system they built for The Witness's editor which was pretty slow. Then he just stips away all the generic framework code that wasn't necessary to the problem that needed to be solved, and speeds it up hugely, turning a "batch processing" interaction into something near-realtime.
The power of knowing exactly what your problem is, and doing only exactly the amount of work needed to solve that problem, is really powerful. I think of it as "vertical integration" for code. Most of the time, we write for "horizontal integration", where each layer is broad and generic. But this means that any specific vertical slice includes a bunch of work that's unnecessary for that vertical.
I always feel like I'm getting slower every day
Boy do I feel this :face_exhaling:
How could you share often but then not link it :grinning:
Touché! https://youtu.be/Ge3aKEmZcqY?si=fzmCJX-u_X-tG-H6
Last updated: Apr 05 2025 at 15:14 UTC