TiDB CLOUD ZEROBUILT FOR AGENTS

TiDB Cloud Zero is a zero-signup, zero-config, zero-friction database experience that gives AI agents and developers instant access to a real TiDB Cloud SQL environment (MySQL-compatible, TLS-secured).

It is optimized for:

• AI agents that need a database on demand
• rapid prototyping, testing, and demos
• automation and CI workflows
• "try now" experiences that can later convert into a full TiDB Cloud account

Zero removes the traditional registration barrier for first use, while still preserving strong isolation, governance, and upgrade paths.

TiDB Cloud Zero is designed for:

• AI agents / agent platforms that provision disposable environments per task
• Developers validating SQL or building quick prototypes
• DevRel / community tutorials that embed instant "try now" workflows
• Teams evaluating TiDB Cloud before onboarding into a persistent environment

No for the initial session. You can start instantly without registration or payment details. If you want persistence, ownership, or higher limits, you can later Claim the environment and create (or log into) a standard TiDB Cloud account.

1. The agent (or client) calls create_session via OpenAPI.
2. TiDB Cloud Zero validates the request (rate limits, anti-abuse, global capacity checks).
3. Zero allocates a pre-warmed Starter instance from a managed warm pool (target: sub-second allocation for most requests).
4. The client receives:

• session_token
• expires_at
• MySQL TLS connection string
• limits profile

5. The client connects via MySQL/TLS and executes SQL under strict limits.
6. If persistence is desired, the client generates a Claim link and upgrades into a full TiDB Cloud account.

Each session is single-tenant: one session = one dedicated Starter instance. This simplifies isolation and reduces cross-tenant risk.

Sessions are ephemeral and automatically expire unless claimed. We model TTL as:

• Session TTL: maximum lifetime of the environment
• Idle TTL (optional): expires earlier if unused
• Token TTL: session_token validity (aligned with session TTL)

Upon expiration:

• session token is revoked
• DB credentials are revoked
• instance is terminated or securely wiped and recycled

TTL duration and limits may evolve based on product phase and usage patterns.

Zero sessions are intentionally constrained for safety and fairness. Typical limits include:

• max concurrent connections
• connection attempt rate
• max QPS / concurrent queries
• max statement execution time
• max rows returned / result size
• max storage
• restricted privileges

When a limit is hit, deterministic error codes are returned. Users may choose to Claim for persistence or higher capacity.

Yes, within strict privilege and resource boundaries. Forbidden capabilities include high-risk operations such as:

• CREATE USER
• GRANT
• SUPER
• FILE
• LOAD DATA
• global configuration changes

Zero is intended for lightweight experimentation. Larger workflows should transition to a standard TiDB Cloud environment via Claim.

Yes, by design.

• Each session gets a dedicated Starter instance (single-tenant per session)
• Credentials are unique and scoped to that environment
• Cross-session access is impossible

Security controls include:

• mandatory TLS
• least-privileged DB user
• strict resource governance
• automatic cleanup on expiry

Claim converts an ephemeral Zero session into a persistent TiDB Cloud experience. When you claim:

1. You open a short-lived, one-time Claim link.
2. You sign up or log in.
3. The system migrates the session environment into your account.
4. You receive persistent access in the TiDB Cloud console.
5. You may upgrade to Essential or Premium tiers.

Claim links are:

• short-lived
• one-time redeemable
• non-guessable

Claim bridges "disposable" and "registered" models while respecting TiDB Cloud's product architecture.

Default approach:

• logical migration (export/import or internal logical copy)
• eligibility checks (size, duration, usage thresholds)

Migration behavior may evolve as One Console architecture matures.

To keep behavior predictable:

• writes are temporarily rejected during migration
• no CDC / dual-write sync
• migration is bounded and deterministic

If migration fails:

• one controlled retry may be attempted
• a short grace period may be granted (bounded to prevent abuse)

TiDB Cloud Zero is designed to protect global stability. If warm pool capacity is temporarily exhausted:

• the request returns HTTP 503 or 429 with Retry-After
• instances are not created on demand in the request path
• a fallback path (sign-up link) may be suggested

Zero prefers fail-fast over degrading the global control plane.

Agents integrate via:

• OpenAPI for session provisioning
• (future) SDKs / CLI for automation
• MySQL/TLS connectivity for maximum compatibility

MVP focuses on MySQL/TLS to leverage the existing ecosystem of drivers and tools. SQL-over-HTTP is a planned evolution for serverless or restricted environments.

MySQL/TLS provides:

• compatibility with existing tooling
• mature authentication and privilege controls
• well-understood security boundaries

SQL-over-HTTP will expand reach later without compromising governance.

Zero uses layered safeguards:

• global rate limits and throttling
• WAF and adaptive IP controls
• mandatory Idempotency-Key support
• strict TTL and limits profiles
• automated load-shedding under stress
• internal kill switches for containment

Protection is system-level rather than invite-based.

Zero measures end-to-end signals to improve reliability and conversion:

• sessions created
• time-to-first-query (median/P95)
• limit hit distribution
• claim link -> signup -> claim completion
• retention and upgrade
• pool hit/miss rates
• cost per session

High-level roadmap: M1 - Technical Preview (current✅) Single region, limited warm pool, strict limits, fail-fast.

M2 - Public Preview Claim workflow maturity, multi-region pools, stronger observability.

M3 - GA Higher reliability, mature anti-abuse, optional Dedicated Paid tier.

Dedicated Paid Zero (future):

• reserved warm pools
• region pinning / allowlists
• configurable TTL and limits (within guardrails)
• enhanced observability
• SLA (post-GA)

Free Zero:

• shared warm pools
• strict limits
• best-effort provisioning
• no SLA