What is Parix?

Parix is a managed TigerBeetle platform for products that need exact balances, ordered transfers, and a durable ledger without operating TigerBeetle infrastructure themselves.

TigerBeetle remains the database and data model. Parix provides the surrounding platform: organizations and access control, database provisioning, gateway authentication and routing, plan enforcement, billing, observability, configuration workflows, backups, restores, and Change Data Capture (CDC).

What Parix manages

Parix divides responsibility between a control plane (product, identity, and lifecycle) and private TigerBeetle data planes.

Parix manages:

• database lifecycle for Developer and isolated plans
• provider and region placement from the active create catalog
• private routing to TigerBeetle through the Parix gateway
• API keys, organization membership, sessions, and security activity
• shared-plan quotas and request rate limits
• dedicated cluster shape, storage, parameter, CDC, and upgrade workflows
• metrics, logs, notifications, and change history where the plan supports them
• billing setup, usage calculation, invoices, and payment state
• manual and scheduled backup artifacts and eligible in-place restores

Your application remains responsible for:

• designing TigerBeetle accounts, transfers, ledgers, codes, and flags
• storing API-key secrets safely and rotating them
• retrying safely and preserving idempotent TigerBeetle identifiers
• monitoring application-level outcomes and business invariants
• choosing a plan whose availability and recovery posture matches the workload

Plans and feature boundary

The active create catalog is the source of truth for plans, providers, regions, sizes, and prices available to a particular organization.

The first eligible Developer database is complimentary once per verified user. Later Developer databases are paid and use the higher shared limits shown in Plans and limits.

Shared and dedicated plans deliberately have different navigation. A missing cluster, logs, backups, or webhooks page on a Developer database is an entitlement boundary, not a broken dashboard link.

Gateway-only database access

Every customer operation goes through the Parix gateway. Parix does not expose raw TigerBeetle replica endpoints on Developer, Dedicated, or Production plans.

The request path is:

1. The client calls a versioned Parix API endpoint.
2. Parix authenticates an API key or a supported first-party access token.
3. The control plane checks organization, database scope, and operation permission.
4. Parix resolves the current shared-cell or dedicated route for that database.
5. Private connectivity carries the request into the data plane.
6. Parix executes the TigerBeetle operation and returns a structured result.

This boundary lets Parix enforce shared quotas, request limits, routing changes, and database-specific authorization before the operation reaches TigerBeetle.

Read Connecting overview for client-facing behavior and Parix architecture for the system explanation.

Database lifecycle

Parix supports two creation paths:

• New database provisions an empty shared or isolated TigerBeetle deployment.
• Import database validates and stages one .tigerbeetle replica file per selected replica index, then provisions the target deployment.

Developer shared databases become active after Parix reserves and assigns capacity in a healthy shared cell. Dedicated and Production databases show Provisioning until infrastructure is ready, or Error if setup fails.

Deletion is also asynchronous. If provisioning is still active, deletion can remain deferred until it is safe to tear down or release the target. See Delete a database before performing a destructive operation.

Operations and observability

All plans provide:

• database status and identifiers
• plan, placement, quota, and cost context
• the guided Connect flow
• the Query explorer
• plan-appropriate Metrics
• exact-name deletion protection

Dedicated and Production plans additionally provide supported combinations of:

• cluster instances and topology changes
• storage and TigerBeetle parameter changes
• runtime logs and dedicated metrics
• manual and scheduled backups
• in-place restore for eligible completed backups
• CDC configuration (managed webhooks or a direct message-queue destination when offered)
• webhook delivery history
• TigerBeetle upgrade and cluster-change history

These pages queue durable workflows. A successful form submission means Parix accepted the requested change; the database reaches the new state only after the workflow completes.

Providers and regions

Google Cloud and AWS are supported providers. What you can create depends on the create catalog for your organization: provider, region, plan, capacity, and billing eligibility are all reflected there.

Do not hard-code provider or region lists into automations. Use the create form or the create-catalog API so you only receive combinations that can be provisioned at that time.

Cross-region Production HA is limited beta and appears only when enabled for your organization in the create catalog. Default self-service remains single-region unless the catalog offers otherwise.

Backups and recovery

Dedicated and Production databases can expose manual and scheduled backups when the plan and catalog allow them. Restore eligibility is narrower than backup creation:

• the target database must still be active
• the completed backup must include every required replica artifact
• the backup must match the current region, topology, size, storage, network mode, development mode, and TigerBeetle version
• some storage types support backup but not in-place restore; the dashboard and restore checks show what is eligible for a given database

Backup artifacts are retained independently according to the organization retention policy, including after database deletion. Point-in-time recovery is not available.

See Backup and restore for the exact operator workflow.

API and integration surface

The versioned API includes session context, create-catalog discovery, database lifecycle endpoints, and TigerBeetle operations. The current generated schemas are published in the live OpenAPI document.

The TigerBeetle operation route currently supports:

• querying accounts and transfers
• creating accounts and transfers
• looking up accounts and transfers
• reading account balances and account transfer history

API keys can cover all databases or one database. Read operations require the read capability; write and lifecycle operations require the corresponding write capability.

Current product boundaries

Treat these as unavailable unless the create catalog or a specific manual page says otherwise:

• direct TigerBeetle protocol access to replicas
• self-service cluster, logs, backups, upgrades, or webhooks for Developer shared databases
• point-in-time recovery
• cross-provider or asynchronous geo-replication
• arbitrary post-create addition of regions to a Production cluster
• Enterprise provisioning without a contractual setup

Start with the Quickstart or compare the exact entitlement and quota values in Plans and limits.