LayerbaseLayerbase

Managed TigerBeetle: where things actually stand in 2026

TigerBeetleFinancialDatabases

TigerBeetle is one of the more interesting databases I've integrated. It's purpose-built for double-entry accounting (debits, credits, balance constraints) and the engineering is unusually rigorous: deterministic simulation testing, io_uring-based I/O, written in Zig, with a culture around correctness that they call TigerStyle and that I genuinely admire.

The hosting story is different from most databases, and I want to be honest about it up front. TigerBeetle's docs say their managed offering is invitation-only and reserved for select enterprise partners. I run Layerbase Cloud, and TigerBeetle is gated there too: it works behind the scenes, but I haven't enabled it in the cloud dashboard yet because a couple of pieces (around auth and the in-browser query experience) need to land first. So if you're here searching for "managed TigerBeetle," the practical answer in 2026 is that the easiest path is running it locally, not in a hosted environment. Here's the full picture.

Contents

What TigerBeetle actually is

A quick framing for anyone who hasn't used it. TigerBeetle is not a general-purpose database. It does one thing: it stores accounts and transfers with debit/credit invariants enforced at the database layer. You don't write SQL. You don't store arbitrary JSON. You create accounts, create transfers between them, and the engine guarantees that double-entry accounting rules are preserved at high throughput.

If you're building anything that touches money (payments, ledgers, wallets, point-of-sale, in-game economies, accounting systems), TigerBeetle is worth a serious look. If you're building literally anything else, you want a different database. The engine is narrow on purpose.

The other thing to know up front: TigerBeetle uses a custom binary protocol. There is no SQL, no HTTP, no JDBC. Clients use the official SDKs (Node.js, Python, Go, Java, .NET, Zig). That means GUI database tools don't connect to it, standard ORMs don't speak to it, and there's no curl you can run to poke at the data. Everything goes through application code using the TigerBeetle client library.

That last point matters for understanding the hosting situation. Most hosted databases give you a way to inspect data from the web UI: open a query console, run SELECT *, see rows. With TigerBeetle, that doesn't exist as a generic feature, because there's no query language. A hosted dashboard would need to know your application's account schema and ship a client-library snippet for each operation. Solvable, but not solved yet.

Option 1: Run it locally with SpinDB

For local development, SpinDB runs the real TigerBeetle binary on your machine. No Docker, no Zig install, no tigerbeetle format ritual to remember. (What is SpinDB?)

bash
npm i -g spindb        # npm
pnpm add -g spindb     # pnpm

Create an instance:

bash
spindb create tb1 -e tigerbeetle --start

Get the connection info:

bash
spindb url tb1
text
tcp://127.0.0.1:3000

The TigerBeetle client connects to that address:

typescript
import { createClient } from 'tigerbeetle-node'

const client = createClient({
  cluster_id: 0n,
  replica_addresses: ['127.0.0.1:3000'],
})

await client.createAccounts([
  {
    id: 1n,
    debits_pending: 0n,
    debits_posted: 0n,
    credits_pending: 0n,
    credits_posted: 0n,
    user_data_128: 0n,
    user_data_64: 0n,
    user_data_32: 0,
    reserved: 0,
    ledger: 1,
    code: 1,
    flags: 0,
    timestamp: 0n,
  },
])

Same engine binary you'd run in production. Same protocol. Just running on your laptop with no auth, which is fine for local development because no one else can reach it.

bash
spindb stop tb1
spindb start tb1
spindb list

This is what I use for testing ledger logic. The deterministic simulation that TigerBeetle is famous for makes it especially good for unit tests because the same sequence of operations produces the same result every time.

One thing worth knowing if you're on Linux: TigerBeetle uses io_uring syscalls, which Docker's default seccomp profile blocks. SpinDB runs TigerBeetle as a native process (not in Docker), so this is a non-issue locally. If you do run it in Docker yourself, you'll need --security-opt seccomp=unconfined.

For 90% of "I want to try TigerBeetle" use cases, this option is the answer.

Option 2: Layerbase Desktop

Layerbase Desktop wraps SpinDB in a Mac app. New instance, pick TigerBeetle, click create. Address shows up in the side panel.

For an engine where you can't really inspect data with a GUI (no SQL, no admin UI), Desktop is honestly less essential than for engines like Postgres or MongoDB. The main value is "I have a TigerBeetle running and I haven't forgotten where it is" while you build the application code that talks to it.

If you do a lot of weekend coding on a ledger project and don't want to remember which terminal tab has SpinDB running, Desktop is the comfortable way to do it.

Option 3: Self-host on a VM

TigerBeetle is a single binary. Download it from the TigerBeetle releases page, format a data file, run it. Production deployments use three or five replicas across machines for consensus. A single-replica deployment is fine for development and acceptable for low-stakes use cases.

bash
# Download the binary, then format a data file
./tigerbeetle format \
  --cluster=0 --replica=0 --replica-count=1 --development \
  0_0.tigerbeetle

# Start the server
./tigerbeetle start \
  --addresses=0.0.0.0:3000 \
  --development \
  0_0.tigerbeetle

The two things that get people:

The --development flag is required for single-replica operation. TigerBeetle's safety story is built around having multiple replicas with consensus, and single-replica mode disables some of those checks. For testing and dev work it's fine. For production, you want the real multi-replica setup.

Backups are file copies, but you should stop the process before copying. The data file format is internal and TigerBeetle does not currently have an online backup mechanism, so if you need point-in-time recovery you're managing it with file-system snapshots or stop-and-copy.

The other thing to plan for: TigerBeetle has no built-in network authentication. The protocol does not support passwords or API keys. Anyone who can reach the port can read and write to the ledger. In a self-hosted setup, you secure it with firewall rules and a private network. If you ever consider exposing a TigerBeetle port to the public internet, the answer is no.

Option 4: TigerBeetle's invite-only managed offering

The TigerBeetle team operates a managed product for select enterprise partners. If you're a serious financial company with a real production workload (payments processor, exchange, bank, anything regulated), email sales@tigerbeetle.com and have a conversation. They also have a Startup Program for earlier-stage companies in fintech that might be a fit.

This is the right path for production financial applications. It's not the right path for "I want to try TigerBeetle on a weekend project," which is exactly the gap the local options are filling for now.

Option 5: Layerbase Cloud (coming, not yet)

I want to be straightforward about where Layerbase Cloud sits on TigerBeetle. The engine works end-to-end in the Cloud API. I can provision a TigerBeetle instance, manage its lifecycle, expose it over TLS with IP allowlisting (since there's no protocol auth), and back it up. The reason it isn't enabled in the cloud dashboard yet comes down to two things.

First, the no-auth situation requires the IP-restriction model rather than a username/password. That works, but it's a different onboarding flow than every other engine and I want it polished before users hit it.

Second, the in-app query console doesn't know how to talk to TigerBeetle. Every other engine in my catalog has a generic /query path: send SQL or a wire command, get rows back. TigerBeetle's binary protocol doesn't fit that shape. The fix is per-operation code snippets in the dashboard ("create account," "create transfer," "lookup balance") that drop into a client-library template. That work hasn't shipped yet, and without it, a hosted TigerBeetle instance lands users on a dashboard that can't actually inspect their data.

Both are solvable and both are on the list. I'm writing this post on a self-imposed deadline, so I'd rather say "not yet" than ship a worse experience to make the post line up. When it does ship, this page gets updated.

If you want to be notified when Layerbase Cloud opens TigerBeetle to public signups, the Layerbase newsletter (subscribe link on the homepage) is the right place to keep an eye on. In the meantime, the local options above cover most of what people are looking for when they search "managed TigerBeetle."

Things to know about TigerBeetle in production

A few learnings from running TigerBeetle behind the scenes that might save you time when you start building:

The protocol is binary and stateful. Connection setup is more involved than HTTP. Reuse client connections rather than creating one per request.

There is no concept of a database or schema. There are accounts, transfers, and ledgers. Everything else is application-level (the code, user_data_*, and flags fields let you encode application metadata). The conceptual shift from "tables and columns" to "accounts and ledgers" takes a minute.

Account IDs and transfer IDs are 128-bit unsigned integers (bigint in TypeScript via the n suffix). The official advice is to use ULIDs or UUIDs cast to 128-bit. Don't try to use auto-incrementing integers.

The flags field on accounts and transfers enables features like debits_must_not_exceed_credits, credits_must_not_exceed_debits, pending (two-phase transfers), and linked (atomic groups). These are how you encode accounting invariants. Worth reading the TigerBeetle docs carefully before designing your schema.

The lack of standard tooling cuts both ways. Less ecosystem, but also fewer footguns. You either commit to using the SDKs properly or you don't use TigerBeetle.

Which one to pick today

Short version for May 2026:

  • Trying out TigerBeetle on a personal project? SpinDB.
  • Prefer a Mac app? Layerbase Desktop.
  • Building a real fintech product with regulated requirements? Email TigerBeetle directly.
  • Have ops capacity and want full control? Self-host with proper multi-replica consensus on a private network.
  • Want hosted TigerBeetle on Layerbase Cloud? Watch the newsletter; it's coming.

TigerBeetle is one of those databases where the engineering quality is high enough that it deserves to be used by more people. The reason it isn't is mostly that the on-ramp has been awkward. SpinDB and Desktop solve the local on-ramp today. The cloud on-ramp is the next thing on my list.

If you want to dig into TigerBeetle itself, the official documentation is excellent and the TigerStyle document is worth reading even if you're not building a database, because it's one of the more thoughtful pieces of engineering philosophy I've come across.

Something not working?