Connecting overview
Choose a supported Parix connection path and understand the access boundary for shared and dedicated databases.
Use this page to choose how an application or operator should access a Parix database. Every plan uses the Parix gateway; Parix does not expose TigerBeetle replica addresses or a raw TigerBeetle protocol endpoint to customers.
Before you connect
You need:
- a database whose status is Ready
- the database ID shown on its dashboard, not only its display name
- an active API key with access to that database
db:readfor read operations anddb:writefor write operations
An owner or administrator can create a key from the global Settings > API keys page. See API keys for the complete workflow.
Choose an access path
| Goal | Supported path | Best for |
|---|---|---|
| Inspect or test data manually | The database Query page | An operator running an occasional request |
| Integrate an application | POST /api/v1/databases/{databaseId}/tb/{operation} | Production code and repeatable scripts |
| Review language examples | The database Connect wizard | Choosing a language and learning the credential flow |
The shipped, executable application interface is the HTTP TigerBeetle operations route. The language tabs in the Connect wizard are reference material; they do not reveal a direct native endpoint and must not be used to infer one.
Plan access boundary
The connection path is the same across plans, but the surrounding product surfaces differ.
| Capability | Developer shared | Dedicated and Production |
|---|---|---|
| Parix gateway operations | Yes | Yes |
| Database dashboard and Query page | Yes | Yes |
| Database Connect and Settings pages | Yes | Yes |
| Tenant-scoped project metrics | Yes | Yes |
| Direct access to replicas or provider addresses | No | No |
| Cluster, backup, logs, CDC, diagnostics, or upgrade controls | No | Available where the selected plan and configuration support them |
Developer databases run in a shared namespace and have shared-plan request and usage quotas. Dedicated-family databases are isolated, but they still use the same public gateway boundary. Compare current entitlements in Plans and limits.
How a request reaches TigerBeetle
- Your application sends an HTTPS request to the Parix public API.
- Parix authenticates the API key and checks its organization, database reach, and required scope.
- Parix validates the operation and JSON payload.
- The control plane resolves the private target for the requested database.
- The gateway performs the TigerBeetle operation and returns a Parix response envelope.
Provider hosts, replica addresses, tunnels, and signed internal routes remain implementation details. Do not put infrastructure addresses found in logs or configuration output into application code.
Expected result
A successful request returns HTTP 200 with the requested operation, the database identity, responsePayload, and gateway execution metadata. For write operations, accept the write as committed only when the response contains persisted: true.
Important limits
- A key scoped to one database cannot access another database, even in the same organization.
- Read and write permissions are checked independently.
- TigerBeetle batch schemas allow at most 8,190 items. Your database plan can enforce a lower request or rate limit.
- Requests can be throttled with
429or temporarily unavailable with503; clients should use bounded retry with jitter for retryable failures. - A successful HTTP response with
persisted: falseis not a committed write.
Troubleshooting
Use API keys and authentication for 401, 403, an inaccessible database, or confusion between a database name and ID. Use Provisioning and configuration when the database is not yet Ready.
Next steps
- Follow Connect to a database for a complete read verification.
- Read Gateway before implementing request and retry handling.
- Review payload fields and operation semantics in TigerBeetle operations.