Introducing Parix

Hey. We're shipping Parix.

Parix is managed TigerBeetle. You create a database, connect through a gateway, and run the cluster from a control plane that handles the boring (and scary) parts: provisioning, access, billing checks, logs, metrics, backups, restore eligibility, and CDC config. TigerBeetle is still the database. We host the platform around it so you don't have to.

We're going live for early teams now. The platform is real, the docs match what the dashboard does, and we're still tightening things as the first workloads land. That felt like the right moment to say what this is and why we built it.

Why this exists

A lot of products quietly turn into ledgers.

An AI app meters tokens, credits, or seats. A wallet moves money between customers, merchants, and settlement. A marketplace tracks fees, holds, refunds, and payouts. A SaaS product needs a billing history that still makes sense six months later when support asks what happened.

Those systems need strong ordering and durable writes. They need idempotency. They need a clean answer when two requests try to spend the same balance at once. And they need a history you can show a customer, an auditor, or whoever is on call at 3 a.m.

Postgres and MySQL are great. We use relational databases for control-plane state ourselves. But transfer-heavy products are a different beast. Once money, credits, or quotas sit in ordinary rows, the app starts collecting locks, retries, queues, reconciliation jobs, and homemade audit trails. That's the signal you've outgrown "just a balance column."

TigerBeetle is built for this. Fast, durable, ordered financial transactions with clear account and transfer semantics. We like it a lot. We also think most teams shouldn't have to become a TigerBeetle ops team just to use it.

That's Parix.

What "managed" actually means here

Spinning up a process and opening a port is the easy part. The hard questions show up later:

• Who can write to this ledger?
• Which cloud and region own the live cluster?
• How do requests reach TigerBeetle without putting replicas on the public internet?
• When is a backup safe to restore?
• How do logs, metrics, CDC, billing, and org permissions stay in sync?
• What happens when provision, import, backup, restore, or upgrade takes longer than one HTTP request?

Parix is shaped around those questions. There's a control plane and a data plane.

The control plane is the product surface: web app, orgs and members, API keys, metadata, artifacts, queues, workflows, read models. It's where you create databases, manage access, watch logs and metrics, configure CDC, track backups, and see whether billing is ready.

The data plane sits next to TigerBeetle: replicas, a provider-local gateway, private networking, CDC transport. Provider specifics stay behind our boundary.

Product state lives in the control plane. Ledger execution lives near TigerBeetle. The gateway is the line between them.

Gateway only

We don't expose raw TigerBeetle networking as a product feature. Shared, dedicated, and production all go through the gateway.

Rough path: request hits the Parix edge, we auth it, resolve the database, pick the provider route, hop private networking to a provider-local tb-gateway, and the gateway talks to TigerBeetle.

That one choke point is where we enforce tenancy, API key scope, rate limits, validation, and later quotas. It also keeps TigerBeetle private to the provider network instead of hanging every replica on the public internet.

For your app, the loop is simple: create a database, mint an API key, call the TigerBeetle operation endpoint for accounts, transfers, balances, and history. We handle routing and ops behind that.

Why we structured it this way

A few things get easier when you commit to this split early.

Lifecycle work is real workflows, not browser requests that hope for the best. Provision, import, backup, restore, storage changes, topology changes, upgrades, CDC, deletion: they need durable state. We queue them, record what happened, and show the result in the dashboard.

Observability is product, not an afterthought. "Up or down" is not enough for a ledger. You get host metrics, TigerBeetle metrics, gateway request metrics, runtime logs, and operational history without SSH.

Backups and restores are platform jobs with rules. We track jobs, artifacts, replica metadata, retention, and restore eligibility. Restore is strict on purpose. Putting a ledger back into the wrong shape is worse than saying no.

Billing and capacity share the same model as provisioning. Provider, region, topology, CPU, memory, storage, usage events all live in control-plane state so pricing and infra don't drift apart.

And we can add providers without changing your app interface. Routing stays inside the platform. You shouldn't rewrite client code because the cluster moves from one supported path to another.

Who this is for

Anyone where ledger correctness is not optional.

AI usage billing. Meter tokens, requests, credits, or model usage in real time. Reject over-limit traffic when it happens, not days later in a spreadsheet. Keep a trail that works for invoices and support.

Wallets and money-adjacent products. Move balances between customers, merchants, reserves, fees, and settlement. Block double-spend under load. Keep history you can explain.

Marketplaces, subscriptions, internal credits, game economies, B2B billing. Same pressure: starts as a feature, ends up as infrastructure.

We want those teams modeling product rules, not babysitting replica networking.

What's in today (and what isn't)

In today:

• Create managed TigerBeetle databases from the dashboard (and shared create via API), with Developer shared, Dedicated single-node, and Production multi-replica plans
• AWS and Google Cloud provider paths, region catalog, storage and size options that match what the create form actually offers
• Gateway-only TigerBeetle operations: accounts, transfers, balances, history over HTTPS
• Orgs, members, invitations, API keys
• Logs and metrics in the product (host, TigerBeetle, gateway), plus cluster change history
• Manual and scheduled backups on supported dedicated deployments, with restore when the backup matches the live cluster shape
• CDC configuration and webhooks
• Import an existing TigerBeetle database into Parix
• Billing: provisioned compute, payment setup, invoices, usage surfaces
• Cross-region Production HA as a fail-closed beta: when the flag and config open it for your org, you can place replicas across regions of the same provider at create time (still not the default self-serve path)

Not in today (on purpose or not yet):

• Direct TigerBeetle protocol access to replicas. Every plan is gateway-only.
• Point-in-time recovery. Recovery is restore from a completed backup that is eligible for the target shape.
• Cross-region HA as an always-on self-serve default, post-create region adds, or cross-provider replication
• A few provider-specific restore and migration paths (for example AWS EBS restore is still out; GCP has more post-create change paths than AWS)

The docs and create catalog are the source of truth for your org and environment. If a control is missing from the form, treat that feature as unavailable for you right now, not "hidden somewhere."

Come build

If you're shipping AI billing, a wallet, a marketplace, credits, quotas, or anything else where balances have to be exact and history has to stick, try Parix.

Read the docs, create a database, run a transfer. Tell us where it hurts. We'll keep shipping in public: more docs, ops notes, architecture posts, and concrete examples of modeling real products on TigerBeetle.

We're glad you're here.