Skip to main content
PARIXDocs
Platform overview

Compatibility and support boundaries

Check the current Parix access, plan, provider, topology, storage, recovery, and API boundaries.

This page summarizes the compatibility boundary implemented by the current Parix repository and checked-in environment configuration. The runtime create catalog remains authoritative for what a specific organization can provision.

Access compatibility

All plans use the Parix gateway:

  • no plan exposes direct TigerBeetle protocol endpoints to customers
  • clients target a Parix database UUID, not a replica address
  • requests authenticate with a supported bearer token or x-api-key
  • API keys can cover all databases or one database
  • database-specific keys cannot create or delete organization-wide database resources
  • read and write operations require their corresponding permission

The public data route supports the operation families listed in TigerBeetle operations. Direct-connect form inputs are ignored and forced off.

Plan compatibility

SurfaceDeveloper sharedDedicated / Production
Dashboard and ConnectYesYes
Query explorer and gateway operationsYesYes
MetricsShared quota/request metricsInfrastructure, API, and TigerBeetle metrics where configured
Cluster, storage, parameters, changesNo self-service accessYes, subject to provider/storage rules
LogsNoYes
Manual and scheduled backupsNo self-service accessYes
In-place restoreNoEligible completed backups only
CDC and managed webhooksNoYes
TigerBeetle upgradesNo self-service accessYes, when the version path is offered

Enterprise is contractual and is not a general self-service create path.

Provider and region compatibility

Parix has modeled Google Cloud and AWS data-plane support, but environment flags and gateway mappings reduce the customer-visible set.

In the checked-in configuration:

  • development enables Google Cloud and AWS paths
  • production disables AWS in the create catalog
  • production maps Google Cloud asia-southeast1 and us-central1

Do not infer availability from seeded catalog rows alone. GET /api/v1/catalog/create and the dashboard create form filter providers and regions through active catalog data, provider flags, runtime gateway mappings, plan rules, and capacity.

See Providers and regions for the operator-facing rule.

Topology and size compatibility

The active topology model contains:

  • single node
  • high availability with 3 replicas
  • high availability with 6 replicas

The active PX sizes are:

SizevCPUMemory
PX-1028 GiB
PX-20216 GiB
PX-40432 GiB
PX-80864 GiB

Exact machine type, storage support, and price are regional catalog results. Missing provider-region-size-topology-storage combinations are configuration errors; Parix does not silently apply a global fallback.

Cross-region compatibility

Cross-region Production HA is a fail-closed beta rather than the default topology.

When the master flag and environment configuration expose it:

  • all regions must use one provider
  • the topology must have multiple replicas
  • the cluster uses 2 or 3 total regions
  • additional regions are selected at creation time
  • the primary region remains the control-plane, gateway-affinity, and CDC home region

If the create form does not offer additional regions, treat the feature as unavailable for that organization and environment.

Storage and post-create changes

The catalog models durable SSD and local NVMe storage; active capacities depend on provider and region.

Post-create constraints include:

  • storage cannot shrink
  • local NVMe blocks post-create topology, instance-size, and storage changes
  • Google Cloud node-count or storage migrations can use a backup-driven replacement path and require downtime during cutover
  • AWS node-count and storage migrations are blocked until the corresponding migration path exists
  • TigerBeetle parameter controls are Google Cloud-only in the current dashboard

Read Cluster configurations, Storage configurations, and Parameter configurations before queuing a change.

Backup and restore compatibility

Dedicated Google Cloud and AWS deployments can create manual and scheduled backups. Restore has stricter support:

  • the database profile must be active
  • the backup job must be completed
  • every required replica artifact must be present
  • region, node count, vCPU, memory, storage, network mode, development mode, and TigerBeetle version must match the active target
  • active Google Cloud deployments are supported
  • AWS restore supports local NVMe only; AWS EBS restore is unsupported

Point-in-time recovery is unavailable. Backup artifacts can remain after database deletion until retention expiry.

API compatibility

The versioned API exposes a limited but real control-plane surface:

  • session context
  • create-catalog discovery
  • database list, create, get, and delete
  • TigerBeetle operations
  • OpenAPI document

There is a current parity gap for nonshared API creation: the public schema advertises broader plan codes, but the implementation defaults nonshared API creation to Single Node. Use the dashboard for Dedicated and Production creation until the API path is corrected and documented as verified.

The public create response can use HTTP 200 for a queued success, a billing-blocked result, or a partially created result. Clients must inspect the response success and provisioning fields.

Retention compatibility

Current checked-in production values include:

  • dedicated collector logs: 7 days, capped at 50,000 rows
  • shared paid project metrics: up to 72 hours
  • organization audit, notifications, cluster changes, and CDC webhook read models: 14 days and 50,000 rows
  • backup artifacts: 7 days by default, with organization override from 1 to 365 days

Retention configuration and plan entitlements can change independently. Use the relevant dashboard and current plan documentation for the active organization.

Unsupported or non-self-service behavior

Do not design around these as available product features:

  • raw replica protocol access
  • direct-connect mode
  • self-service dedicated controls on Developer shared databases
  • point-in-time recovery
  • AWS EBS restore
  • storage shrink
  • post-create local-NVMe shape changes
  • arbitrary post-create addition of Production regions
  • cross-provider replication
  • production AWS creation while the provider flag is disabled
  • Production or Enterprise creation through the current API parity gap
  • a standalone shipped Parix CLI binary
  • distributed tracing as a customer-facing dashboard surface

How to verify current availability

Before provisioning or automating a feature:

  1. Query the create catalog or open the dashboard create form.
  2. Confirm the plan and organization entitlement.
  3. Confirm provider, region, topology, storage, and size are present as one selectable combination.
  4. Read the feature page for post-create provider restrictions.
  5. Treat an absent option or a 403 plan boundary as unavailable.

Continue with Plans and limits, Providers and regions, or Troubleshooting.