Skip to content
LayerbaseLayerbase

Managed TigerBeetle: where things actually stand in 2026

10 min readTigerBeetleFinancialDatabases

Short version, updated August 2026: TigerBeetle's own managed offering is still invitation-only and aimed at enterprise partners, so the answer for a regulated production workload is still to email them. What changed since this post first ran is the other end: TigerBeetle is now live in the Layerbase Cloud dashboard, with a ledger console that speaks its structured operations instead of pretending it accepts SQL. Local development through the CLI remains the fastest way to try it at all.

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. That has not changed. What has changed is Layerbase Cloud, which was gated on this engine when this post first ran and is not any more: TigerBeetle is a creatable engine in the dashboard, and the two pieces that were holding it back, the IP-restriction onboarding flow and a query console that understands a binary protocol, have both shipped. So if you're here searching for "managed TigerBeetle," there are now two self-serve answers instead of zero. 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 the Layerbase CLI

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

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

Create an instance:

bash
lbase create tb1 -e tigerbeetle --start

Get the connection info:

bash
lbase 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
lbase stop tb1
lbase start tb1
lbase 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. The Layerbase CLI 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 desktop 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 the Layerbase CLI 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

This section used to say "not yet." It has shipped. TigerBeetle is a creatable engine in Layerbase Cloud: provision an instance, get it over TLS, and let us handle its lifecycle and backups.

The two things that were blocking it are worth naming, because they explain what a hosted TigerBeetle has to solve that a hosted Postgres does not.

The first was authentication. TigerBeetle has no protocol-level auth, so there is no username and password to hand you, and access has to be controlled with IP allowlisting instead. That is a different onboarding flow from every other engine in the catalog, and it needed to be a deliberate path rather than an exception someone stumbles into.

The second was the query console. Every other engine has a generic path: send SQL or a wire command, get rows back. A binary protocol with no query language does not fit that shape, so TigerBeetle has its own ledger console built around its actual operations rather than a SQL box that would never work. Without that, a hosted instance would have landed users on a dashboard that could not show them their own data.

TigerBeetle sits on the Pro plan and draws more reserved capacity than a lighter engine, which is the honest tradeoff for a database that assumes it owns its machine.

For a regulated production financial workload, Option 4 is still the right call. This is the option for everyone whose actual sentence was "I want to run TigerBeetle somewhere without operating it."

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

As of August 2026:

  • Trying out TigerBeetle on a personal project? the Layerbase CLI.
  • Prefer a desktop 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 without operating it? Create one on Layerbase Cloud.

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 wasn't is mostly that the on-ramp was awkward at both ends. The CLI and Desktop fixed the local half; the cloud half is no longer an IOU.

FAQ

Can I use a GUI database tool with TigerBeetle?

No, and this is structural rather than a gap someone will close. TigerBeetle uses a custom binary protocol with no SQL, no HTTP, and no JDBC, so ORMs do not speak to it and there is no curl that pokes at the data. Everything goes through the official SDKs: Node.js, Python, Go, Java, .NET, and Zig.

Is TigerBeetle a general-purpose database?

Deliberately not. It stores accounts and transfers with debit and credit invariants enforced at the database layer, and that is the whole surface. If you are building payments, ledgers, wallets, point-of-sale, in-game economies, or accounting, it is worth serious evaluation. If you are building anything else, you want a different database and the narrowness will only cost you.

How does authentication work if the protocol has none?

Through IP allowlisting rather than credentials. There is no username and password to issue, so the network is the boundary, and that is true whether you self-host or use a managed instance. It is a different onboarding shape from every other engine, which is exactly why hosting it took extra work.

What do I need to know before designing a schema?

Three things catch people. There is no database or schema concept, only accounts, transfers, and ledgers, with code, user_data_*, and flags carrying your application metadata. Account and transfer IDs are 128-bit unsigned integers, so use ULIDs or UUIDs and not auto-incrementing integers. And the flags field is where accounting invariants live, including debits_must_not_exceed_credits, pending for two-phase transfers, and linked for atomic groups.

Should I use the invite-only offering or a managed instance elsewhere?

If you are a regulated financial company with a real production workload, email TigerBeetle and have the conversation; that is what their program is for, and they also run a startup program for earlier-stage fintech. Everyone else is trying to run TigerBeetle without operating it, which is what a self-serve managed instance is for.

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.

Keep reading