Bytebase · Rate Limits

Bytebase Rate Limits

Bytebase does not publish fixed per-account API rate limits because the API is most commonly consumed against a self-hosted or single-tenant cloud deployment that the customer operates. Practical limits are therefore a function of the deployment's own capacity and any reverse proxy / ingress in front of it, rather than a vendor-imposed quota. The product's hard caps are expressed as plan limits (instances and users) rather than request-rate ceilings. Access tokens issued by /v1/auth/login are short-lived and must be refreshed.

Bytebase Rate Limits is the machine-readable rate-limit profile for Bytebase on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests, instances, users, and session.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Database, DevOps, Schema Migration, CI/CD, and DevSecOps.

4 Limits Throttle: 429
DatabaseDevOpsSchema MigrationCI/CDDevSecOpsRate LimitingQuotas

Limits

API Request Rate deployment
requests
governed by deployment capacity / operator
No fixed vendor request-rate quota documented; self-hosted limits depend on the operator's infrastructure.
Database Instances (plan cap) workspace
instances
10 on Community/Pro; unlimited on Enterprise
A product plan cap, not a request-rate limit.
Users (plan cap) workspace
users
20 on Community; unlimited on Pro/Enterprise
A product plan cap, not a request-rate limit.
Access Token Lifetime token
session
short-lived; refresh via auth
Tokens from /v1/auth/login expire and must be refreshed (RefreshToken).

Policies

Token Refresh
Re-authenticate or refresh the access token before expiry; do not hardcode long-lived tokens.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on any 429 from a fronting proxy.

Sources