Thanks for the questions! It's a database with purpose-built primitives for recording financial transactions between accounts, particularly two-phase commit tr

Thanks for the questions! It's a database with purpose-built primitives for recording financial transactions between accounts, particularly two-phase commit transactions between different payment systems run by different operators. Over the past decade or so, some of our team saw that these primitives kept getting re-implemented over and over again, often with duct tape ad-hoc solutions that are not always safe, or scalable. At the same time, the payments world is rapidly changing. Things are moving to high volume, low value digital transactions, which means that operational cost becomes important. We extracted the design for TigerBeetle out of a real-world payment switch, so that TigerBeetle can be transplanted into these kinds of systems very easily, and in a way that's very hard to get wrong because the interface maps one-to-one to the domain. We also solve a storage fault model that's relatively new in the research literature, something that most traditional databases were never designed for, and we do this because this makes for a safer system of record, not to mention a better operating experience. If anything, we place the pursuit of safety much higher than the pursuit of performance. We work much harder at the safety, the performance came pretty easily with the design right from the beginning. So the safety of TigerBeetle is what we're most excited about. The performance is a nice-to-have to go with it. These are hopefully "the things that don't change" when it comes to databases. Nobody wanted a less convenient, or more dangerous, or slower database.