7 ms·

I also don't quite like TigerBeetle as an example, because it is very new startup. They are pre-1.0 and just a bit more than a year since production release. It

I also don't quite like TigerBeetle as an example, because it is very new startup. They are pre-1.0 and just a bit more than a year since production release. It's way too early to tell whether their approach actually paid off.

jorangreef 1y ago
Joran from TigerBeetle here! While the company is 3 years old, TigerBeetle as an open source DBMS project actually started in 2020. What we mean by "production" is also typically a bit different to what is typically meant. For example, TigerBeetle is one of the first DBMS's to withstand an explicit storage fault model (i.e. disk corruption across all replicas). So the tolerances are a bit tighter for TigerBeetle, also with things like static memory allocation (cf. NASA's Power of Ten Rules for Safety-Critical Code). Beyond this, when TigerBeetle was designed, it was (along with FoundationDB) one of few DBMS's to invest in a Deterministic Simulator in-house. Most DBMS's before 2020 were typically not designed from the ground up for Deterministic Simulation Testing (DST) and so now can only use Antithesis if they want to get into DST. However, TB invests heavily in both, not only an external DST audit function, but more importantly, also our own internal DST audit function, which we designed and built entirely inhouse, and which can do considerably more damage to TigerBeetle because it's protocol-aware and understands how to push TB's consensus and storage to the breaking limit. In other words, not one DST simulator, but two, with “the VOPR” (the name for TB's own simulator) tailored to our fault models, and able to reach into any part of the code, across any machine in the simulation, and verify expectations. For example, do things like verify cache coherency between user space page cache and simulated storage engine. Finally, if you're interested in the results of whether this rigid TigerStyle approach pays off, Kyle Kingsbury's Jepsen audit of TigerBeetle was one of the longest Jepsen engagements to date, and these were the findings: https://jepsen.io/analyses/tigerbeetle-0.16.11 https://jepsen.io/analyses/tigerbeetle-0.16.11
potato3732842 1y ago
I work at a medium company that is in a comparable sector implementing comparatively performant and externally constrained things pretty much wholly in C and pretty much wholly with our own dependencies with external dependencies being mostly located in ops, testing/qa and other stuff not in the critical path of what the people who pay us want the products to do. For us it's not about "built here" it's about control and uniformity. The company is a decade old and very profitable for its headcount though not subject to wild delusions about future hockey sticks because of what we build and for who. So the approach clearly can work. It won't kill you. But it's also unclear the degree to which this approach contributed to vs detracted from our success since it's not like there's a control company that did it the other way you can compare to. It takes constant effort to do things this way, but so does managing dependencies. While unilateral control, and the responsibility for that, that comes with writing your own dependencies is a key aspect of how we do what we do with the headcount we do it's not like it's part of our marketing. It's just a decision that was made that we're sticking to because it seems to work for us. It's not some silver bullet, it takes effort to do well, like anything else done well. I have worked at huge companies where they were biased toward using existing stuff where it existed and tweaking it just the bare minimum needed and that worked very well for them too and definitely had its pros too.

jorangreef 1y ago

Joran from TigerBeetle here! While the company is 3 years old, TigerBeetle as an open source DBMS project actually started in 2020. What we mean by "production" is also typically a bit different to what is typically meant. For example, TigerBeetle is one of the first DBMS's to withstand an explicit storage fault model (i.e. disk corruption across all replicas). So the tolerances are a bit tighter for TigerBeetle, also with things like static memory allocation (cf. NASA's Power of Ten Rules for Safety-Critical Code). Beyond this, when TigerBeetle was designed, it was (along with FoundationDB) one of few DBMS's to invest in a Deterministic Simulator in-house. Most DBMS's before 2020 were typically not designed from the ground up for Deterministic Simulation Testing (DST) and so now can only use Antithesis if they want to get into DST. However, TB invests heavily in both, not only an external DST audit function, but more importantly, also our own internal DST audit function, which we designed and built entirely inhouse, and which can do considerably more damage to TigerBeetle because it's protocol-aware and understands how to push TB's consensus and storage to the breaking limit. In other words, not one DST simulator, but two, with “the VOPR” (the name for TB's own simulator) tailored to our fault models, and able to reach into any part of the code, across any machine in the simulation, and verify expectations. For example, do things like verify cache coherency between user space page cache and simulated storage engine. Finally, if you're interested in the results of whether this rigid TigerStyle approach pays off, Kyle Kingsbury's Jepsen audit of TigerBeetle was one of the longest Jepsen engagements to date, and these were the findings: https://jepsen.io/analyses/tigerbeetle-0.16.11 https://jepsen.io/analyses/tigerbeetle-0.16.11

potato3732842 1y ago

I work at a medium company that is in a comparable sector implementing comparatively performant and externally constrained things pretty much wholly in C and pretty much wholly with our own dependencies with external dependencies being mostly located in ops, testing/qa and other stuff not in the critical path of what the people who pay us want the products to do. For us it's not about "built here" it's about control and uniformity. The company is a decade old and very profitable for its headcount though not subject to wild delusions about future hockey sticks because of what we build and for who. So the approach clearly can work. It won't kill you. But it's also unclear the degree to which this approach contributed to vs detracted from our success since it's not like there's a control company that did it the other way you can compare to. It takes constant effort to do things this way, but so does managing dependencies. While unilateral control, and the responsibility for that, that comes with writing your own dependencies is a key aspect of how we do what we do with the headcount we do it's not like it's part of our marketing. It's just a decision that was made that we're sticking to because it seems to work for us. It's not some silver bullet, it takes effort to do well, like anything else done well. I have worked at huge companies where they were biased toward using existing stuff where it existed and tweaking it just the bare minimum needed and that worked very well for them too and definitely had its pros too.