A distributed financial accounting database designed for mission critical safety and performance to power the future of financial services. (by coilhq)

Tigerbeetle Alternatives

Similar projects and alternatives to tigerbeetle

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better tigerbeetle alternative or higher similarity.

Suggest an alternative to tigerbeetle

tigerbeetle reviews and mentions

Posts with mentions or reviews of tigerbeetle. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-06-23.
  • How Safe Is Zig?
    8 projects | news.ycombinator.com | 23 Jun 2022
    It's a pleasure. Let me know if you have any more questions about TigerBeetle. Our design doc is also here: https://github.com/coilhq/tigerbeetle/blob/main/docs/DESIGN....
  • TigerStyle – TigerBeetle's coding style guide
    1 project | news.ycombinator.com | 2 Jun 2022
  • Distributed Systems Shibboleths
    3 projects | news.ycombinator.com | 2 May 2022
    > Allowing developers to think about a stream of operations that moves the databases from one legal state to another is super powerful.

    It is super powerful. We used this RSM intuition to test TigerBeetle's strict serializability, by verifying state transitions the instant they happen, instead of trying to piece everything together and verify strict serializability after the test run.

    Here it is in 49 lines of code:


    3 projects | news.ycombinator.com | 2 May 2022
    Surprisingly, some of the most powerful distributed systems algorithms or tools are actually deterministic. They're powerful because they can "load the dice" and so make the distributed system more intuitive for humans to reason about, more resilient to real world network faults, and do all this with more performance.

    For example, Barbara Liskov and James Cowling's deterministic view change [1], which isn't plagued by the latency issues of RAFT's randomized dueling leader problem. Viewstamped Replication Revisited's deterministic view change can react to a failed primary much quicker than RAFT (heartbeat timeouts don't require randomized "padding" as they do in RAFT), commence the leader election, and also ensure that the leader election succeeds without a split vote.

    Determinism makes all that possible.

    Deterministic testing [2][3] is also your best friend when it comes to testing distributed systems.

    [1] I did a talk on VSR, including the benefits of the view change — https://www.youtube.com/watch?v=Wii1LX_ltIs

    [2] FoundationDB are pioneers of deterministic testing — https://www.youtube.com/watch?v=OJb8A6h9jQQ

    [3] TigerBeetle's deterministic simulation tests — https://github.com/coilhq/tigerbeetle#simulation-tests

  • Lies we tell ourselves to keep using Golang
    8 projects | reddit.com/r/fasterthanlime | 29 Apr 2022
    This is the chasm problem, where people don't use a technology because people aren't using that technology, thus the technology has difficulty gaining adoption. I did see that Zig does have it's own killer app and startup that's using Zig: TigerBeattle.
  • Ask HN: Codebases with great, easy to read code?
    35 projects | news.ycombinator.com | 21 Mar 2022
    Are we allowed to share repos that we've written? :)

    If so, then here's distributed consensus written in Zig:


    Something that differentiates this from many other consensus implementations is that there's no networking/multithreading code leaking through, it's all message passing, so that it can be deterministically fuzz tested.

    I learned so much, and had so much fun writing this, that I hope it's an enjoyable read—or please let me know what can be improved!

    35 projects | news.ycombinator.com | 21 Mar 2022
    Control flow statements should always be on their own lines, then it's easy to find all of them by visually scanning top-down, without needing to look all the way down each line.

    [1]: https://github.com/coilhq/tigerbeetle/blob/main/src/vsr/repl...

  • Database functions to wrap logic and SQL queries
    1 project | news.ycombinator.com | 28 Feb 2022
    > In hindsight, data logic should be in the database itself.

    This is the reason we are creating TigerBeetle [1] at Coil, as an open source distributed financial accounting database, with the double entry logic and financial invariants enforced through financial primitives within the database itself.

    This is all the more critical for financial data, because raw data consistency is not enough for financial transactions, you also need financial consistency, not to mention immutability.

    The performance of doing it this way is also easier. For example, around a million financial transactions per second on commodity hardware, with p100 latency around 10-20ms.

    [1] https://github.com/coilhq/tigerbeetle

  • Building Payment systems for the World at Hackathons
    2 projects | dev.to | 7 Feb 2022
    You probably already know this — because we’ve mentioned it a few times — but Coil champions and supports open-source projects and is privacy-first, by default. Over the years, Developer Relations at Coil has championed and sponsored teams that write Open Web Documentations and projects that empower open-source developers to get paid. Coil has also incubated many open-source projects like Tigerbeetle and Rafiki.
  • Durability and Redo Logging
    1 project | news.ycombinator.com | 26 Jan 2022
    [6] Partial logical sector reads/writes even when using O_DIRECT — https://github.com/coilhq/tigerbeetle/blob/main/src/storage....
  • Failing to Learn Zig via Advent of Code
    17 projects | news.ycombinator.com | 17 Jan 2022
    > Checked arithmetic is a much bigger performance hit than most people expect.

    You're right about the branching cost. I believe there's a better way to solve that though then simply disabling checked arithmetic everywhere.

    I am the tech lead for TigerBeetle [1], a new distributed database that can process a million financial transactions per second.

    We differentiate between the control plane (where we want crystal clear control flow and literally thousands of assertions, see NASA's "The Power of 10: Rules for Developing Safety-Critical Code") and the data plane (where the loops are hot).

    There are few places where we wouldn't want checked arithmetic in TigerBeetle enabled by default. But where the branch mispredict cost relative to the data is too high, Zig enables us to mark the block scope as ReleaseFast to disable checked arithmetic.

    [1] https://www.tigerbeetle.com

  • Zig 0.9.0
    12 projects | news.ycombinator.com | 20 Dec 2021
    My guess is that Zig's design choices are hitting "a sweeter sweet spot" for systems programming that resonates with many engineers reading HN.

    At least for TigerBeetle [1], a distributed database, the story was strong enough even last year that we were prepared to paddle out and wait for the swell to break, rather than be saddled with undefined behavior and broken/slow tooling, or else a steep learning curve for the rest of the project's lifetime. We realized that as a new project, our stability roadmaps would coincide, and that Zig makes a huge amount of sense for greenfield projects starting out.

    The simplicity and readability of Zig is truly remarkable, which comes down to the emphasis on orthogonality, and this is especially important when it comes to writing distributed systems.

    Appropriating Conway's Law a little loosely, I personally feel it's more difficult (certainly possible though) to arrive at a super simple design for a distributed consensus protocol like Viewstamped Replication, Paxos or Raft, if the language's design itself is not also encouraging simplicity, readability and explicitness in the first place, not to mention a minimum of necessary and excellent abstractions. Because every abstraction carries with it some probability of leaking and undermining the foundations of the system, I feel that whether we make them zero-cost or not is almost besides the point compared to getting the number of abstractions and composition of the system just right.

    For example, Zig's comptime encouraged a distributed consensus design where we didn't leak networking/locking/threading throughout the consensus [2] as is commonly the case in many implementations I've read even in high-level languages like Go. It made things like deterministic fuzzing [3] really the natural solution. People who've worked on some major distributed systems in C++ have commented how refreshing it is to read consensus written in Zig.

    Zig also has a different/balanced/all-encompassing approach to safety that resonates more with how I feel about writing safe systems overall: all axes of safety as a spectrum rather than as an extreme (this helps to prevent pursuing one axis of safety at the expense of others), safety also including things like NASA's "The Power of 10: Rules for Developing Safety-Critical Code" [4], assertions, checked arithmetic (this should be enabled by default in safe builds, which it is in Zig), static memory allocation, and compiler checked syscall error handling, the latter of which is really the number one thing that makes distributed databases unsafe according to the findings in "An Analysis of Production Failures in Distributed Data-Intensive Systems" [5].

    While we could certainly benefit from the muscle of Rust's borrow checker in places, it makes less sense since TigerBeetle's design actively avoids the cost of multi-threading, with a single-threaded control plane for more efficient use of io_uring (zero-copy when moving memory in the hot path), plus static memory allocation and never freeing anything in the lifetime of the system. The new IO APIs like io_uring also encourage a future of single-threaded control planes (outsourcing to the kernel thread pool where threads are cheaper) since context switches are rapidly becoming relatively more expensive. Multi-threading for the sake of I/O is less of a necessary evil these days than it was say 5 years ago.

    At some point, the benefits didn't outweigh the costs, and we had to weigh this up. In the end, it came down to simplicity, readability and state-of-the-art tooling.

    [1] https://www.tigerbeetle.com

    [2] https://github.com/coilhq/tigerbeetle/blob/main/src/vsr/repl...

    [3] https://github.com/coilhq/tigerbeetle#simulation-tests

    [4] https://web.cecs.pdx.edu/~kimchris/cs201/handouts/The%20Powe...

    [5] https://www.usenix.org/system/files/conference/osdi14/osdi14...

  • Raft Consensus Protocol
    5 projects | news.ycombinator.com | 4 Nov 2021
    If you avoid multithreading in your consensus protocol, this also means that your implementation becomes more deterministic. If you can have it fully deterministic by stubbing out the message passing and storage, then you can do deterministic simulation fuzzing like we do in TigerBeetle, which is a high velocity testing technique for finding/reproducing/fixing interesting (and rare) bugs: https://github.com/coilhq/tigerbeetle#simulation-tests
  • Experimenting timeout and cancellation with Zig async/await and tigerbeetle-io
    3 projects | dev.to | 3 Nov 2021
    After reading Proposal: Event loop redesign · Issue #8224 · ziglang/zig, I'm really interested in the TigerBeetle IO event loop.
  • Serial, Parallel, and Quorum Latencies
    1 project | news.ycombinator.com | 22 Oct 2021
    Thanks for making this. This is such a cool tool.

    Would be awesome to see the tradeoff between network latency and network throughput, assuming that network throughput is not unlimited.

    For example, a primary with a 1Gbps NIC may see less favorable latency profiles due to queueing theory if it's replicating to backups in parallel but also ingesting data at a high rate.

    This is where matching outgoing bandwidth 1-to-1 with incoming bandwidth, and spreading the primary's load more evenly across all replicas for better stability, but still with 3/5 quorum acks for grey failure tail-tolerance, might show slightly higher latencies, but with less of a latency cliff and significantly higher throughput, saturating the line rate.

    We devised this technique for TigerBeetle, and it works extremely well together with Flexible Paxos, since you only pay the serial latency cost for the first synchronous replication hop from primary to next backup (subsequent serial hops between backups can then be async in terms of Flexible Paxos), and this is also ideal in terms of Viewstamped Replication since the next backup will be the next primary:



Basic tigerbeetle repo stats
5 days ago

coilhq/tigerbeetle is an open source project licensed under Apache License 2.0 which is an OSI approved license.

SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
Find remote jobs at our new job board 99remotejobs.com. There are 2 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.