Plans and limits
Current Parix plan families, feature gates, and enforced Developer quotas.
Parix uses five canonical plan codes. Replica count is part of the plan/configuration mapping, not an independent add-on.
| Plan | Code | Placement | Intended use | Self-service create |
|---|---|---|---|---|
| Developer | developer | Shared Parix cell | Learning, prototypes, SDK testing | Yes |
| Dedicated Single Node | single_node | Dedicated, 1 replica | Isolated development, staging, non-HA work | Yes |
| Production HA | production_ha | Dedicated, 3 replicas | Production high availability | Yes |
| Production 6 | production_6 | Dedicated, 6 replicas | Higher replica count for production | Yes |
| Enterprise | enterprise | Contract-defined | Custom topology, networking, compliance, or support | No; sales-assisted |
Legacy shared codes are normalized to developer by the application.
Feature matrix
This table describes shipped plan gates. A check means the plan permits the product surface; provider, region, storage, workflow, and billing prerequisites can still make a particular action unavailable.
| Capability | Developer | Single Node | Production HA | Production 6 | Enterprise |
|---|---|---|---|---|---|
| Gateway API and query surface | Yes, quota-limited | Yes | Yes | Yes | Contract-defined |
| Raw TigerBeetle protocol | No | No | No | No | No |
| Production allowed | No | No | Yes | Yes | Yes |
| Production SLA | No | No | Separate written SLA | Separate written SLA | Contractual |
| Customer-managed topology/storage | No | Yes, provider limits | Yes, provider limits | Yes, provider limits | Contractual |
| Self-service backups and restore | No | Plan permits; provider limits | Plan permits; provider limits | Plan permits; provider limits | Contractual |
| Infrastructure logs | No | Yes | Yes | Yes | Contractual |
| Metrics | Project quota/usage metrics | Infrastructure and TigerBeetle metrics | Infrastructure and TigerBeetle metrics | Infrastructure and TigerBeetle metrics | Contractual |
| Self-service TigerBeetle upgrades | No | Yes, provider limits | Yes, provider limits | Yes, provider limits | Contractual |
| Webhooks / CDC | No | Entitlement enabled; runtime prerequisites apply | Entitlement enabled; runtime prerequisites apply | Entitlement enabled; runtime prerequisites apply | Contractual |
| Support | Community/email, no response SLA | Priority | Priority | Contractual |
Shared Developer databases can open the dashboard, Connect, Query, Settings, and project Metrics surfaces. Backups, cluster configuration, infrastructure logs, webhooks/CDC, gateway diagnostics, and version upgrades are plan-restricted in the customer dashboard.
Production placement and priority support do not create an unconditional SLA. An SLA applies only when a separate written SLA or customer contract says it does.
Developer pricing and database count
Each verified user can claim one complimentary Developer database during their lifetime. Deleting it does not restore the grant. Additional Developer databases are $5 per month; the checked-in annual entitlement price is $49.
An organization can have at most 10 active Developer databases in the current entitlement seed. The complimentary grant is per verified user, while the 10-database ceiling is per organization.
Developer operation quotas
The developer entitlement row stores paid quotas. Application code applies the lower complimentary overrides when the active placement belongs to a user's lifetime free grant.
| Limit | Complimentary Developer | Paid Developer |
|---|---|---|
| Events per request | 100 | 1,000 |
| Lifetime accounts | 5,000 | 100,000 |
| Lifetime transfers | 250,000 | 25,000,000 |
| Monthly read events | 100,000 | 5,000,000 |
| Monthly transfers created | 25,000 | 1,000,000 |
| Open pending transfers | 100 | 1,000 |
| Read requests per second / burst | 10 / 50 | 25 / 100 |
| Write requests per second / burst | 1 / 10 | 5 / 50 |
| Pending-transfer timeout | 7 days | 7 days |
| Shared project metrics retention | 72 hours | 72 hours |
The Developer entitlement also defines 500 ledgers, 50 API keys, and a 100-seat plan limit. Complimentary quota overrides do not change those values.
Quota counters are enforced at the database/project boundary. Rate limits use separate read and write buckets, and shared-cell admission can reject work before a project reaches its own numeric quota when the cell is not accepting traffic.
Organization-level limits
Current runtime limits that apply alongside plan entitlements:
| Limit | Current value | Notes |
|---|---|---|
| Organizations per user | 5 | Authentication-service membership limit. |
| Active members per organization | 50 | This is stricter than the seeded 100-seat plan entitlement. |
| Enabled API keys | 50 | Plan-derived once the organization has a current database. A mixed-plan organization uses the strictest non-null active-plan limit. |
| API key name length | 2–40 characters | Enforced by the key generator. |
| Organization backup retention setting | 1–365 days | Default 7; capability still depends on plan/provider support. |
Pending invitations count with active members for plan-seat enforcement. An organization with no current non-deleted database has no plan from which to derive the API-key quota, so the current service skips the 50-key check until a database plan exists. A null numeric entitlement on a dedicated plan means no plan-specific cap is configured in that row; it is not a promise of unlimited provider capacity or usage.
Get current availability and pricing
The create catalog is the runtime authority for provider, region, topology, size, storage, and price combinations. Use the dashboard create flow or GET /api/v1/catalog/create with an organization-wide credential containing db:write.
See Providers and regions before treating a seeded catalog row as production-available.