Front Row at TiDB SCaiLE 2026: The Database Built for Billions of Agents

Ravit Jain

Front row, finally

I have wanted to be in this room for 3 years. Today I sat in the front row at TiDB SCaiLE 2026 in Mountain View, and it was worth the wait.

Ravit Jain on stage at TiDB SCaiLE 2026

Representing The Ravit Show at TiDB SCaiLE 2026, Computer History Museum, Mountain View.

PingCAP Co-founder and CEO Max Liu opened the keynote. Vinod Kumar, VP and Head of Engineering at Atlassian, walked through how TiDB runs at Atlassian scale. Yijia Zhang, Head of AI and Platform at Plaud, explained why they left MySQL behind. Patrick Barason closed with the product tiers and a new Postgres-compatible Starter.

One theme ran through every talk. The next wave of database users will not be people. It will be AI agents, and they need infrastructure built for how they work.

Official sources: read PingCAP's official SCaiLE 2026 product announcement and the official press release.

SCaiLE 2026 product keynote title slide: One foundation. More possibilities.

The product keynote theme: one foundation, more possibilities.

The number that stopped the room

In 6 months, TiDB Cloud went from tens of thousands of managed database instances to more than 3 million. More than 99% of them were created by AI agents, not humans.

Max said PingCAP expects billions of agents within 3 years. Most of those workloads are short-lived and spiky. An agent spins up a database, does its job, and moves on.

That changes what a database has to be good at. Fast provisioning, cheap idle time, and isolation now matter as much as raw throughput.

PingCAP's official announcement puts it this way: agents created nearly 3 million database instances on TiDB Cloud Starter in the past 6 months.

Max made the math simple: users times projects times agents. Every multiplication adds databases. On his slide, each tile was 1 user with 15 databases.

Slide: Users x projects x agents. Every multiplication adds databases.

The Manus demo made it concrete. One prompt, "build a client project status portal," produced a working site and its own database with projects, clients, and updates tables, created in seconds.

Slide: One prompt. One site. One database. Manus website builder demo.

Every site an agent builds gets a database of its own: e-commerce, landing pages, dashboards, knowledge bases, status portals. A quiet corporate site sits there with no compute running at all.

Slide: Every site an agent builds gets a database of its own.

Every announcement at a glance

PingCAP announced 1 plan headed to GA, 3 public previews, and an open-source commitment. Release stage matters if you are planning a rollout, so here is where each one stands as of October 15, 2026.

AnnouncementRelease stageWhat it is for
TiDB Cloud PremiumGA announced; available to customers in November 2026Business-critical apps that need isolated resources, automatic scaling, private connectivity, and customer-managed encryption keys
TiDB Cloud EssentialPublic previewGrowing production apps that need control over provisioned compute
BYOC (Bring Your Own Cloud)Public preview, available nowManaged TiDB Cloud operations with data kept in your own cloud account
TiDB Cloud FilesystemPublic preview, available nowA persistent workspace so AI agents keep code, files, and results across sandboxes and sessions
PostgreSQL support on TiDB Cloud StarterPublic preview, open signupPostgres developers building on TiDB with familiar tools
TiDB X core codeOpen source by end of 2026Inspecting and adapting the architecture behind TiDB Cloud

Starter, Essential, and Premium all run on TiDB X. Starter stays generally available, and Dedicated remains available for teams that need broader cloud and regional coverage. Source

Max Liu on TiDB X

Max's core argument: one engine should serve both enterprise systems of record and agent workloads, with the same SQL, vector, and full-text search.

TiDB X is how PingCAP plans to do that. It uses what Max called dual decoupling.

  • Compute from storage. Separating the two cuts costs by up to 10x.
  • Compute from compute. Compactions, index builds, and queries each run in their own dynamic resource pools. That cuts costs by up to 100x and keeps transaction latency flat.

The first separation answers a simple problem. In the classic model, every database carries its own compute, sized for its peak and mostly idle. With TiDB X, the data stays and compute comes and goes.

Slide: TiDB X separation 1 of 2, compute from storage. Data stays. Compute comes and goes.

The production numbers he shared:

MetricClassic TiDBTiDB XChange
P95 latency10.09 ms5.05 msDown 50%
P99 latency22.09 ms7.76 msDown 65%
P99.9 latency51.93 ms14.23 msDown 73%
Index creationNot given5.5 million rows per second

Slide: Same production workload. Lower tail latency, Classic TiDB vs TiDB X.

Max Liu walking through the tail latency results on the same production workload.

Adoption is moving fast. TiDB X made up 14% of cloud revenue over the last 3 months, and PingCAP expects 30% by year end. Every new TiDB Cloud cluster now defaults to TiDB X.

PingCAP also confirmed it will open source the core code of TiDB X by the end of 2026. Max framed it simply: every team should be able to start small on a data foundation that can grow with its ambitions.

Details: Open Sourcing the Core of TiDB X, official announcement and PingCAP's introduction to TiDB X.

For customers running classic TiDB today, the upgrade goal is no downtime. The path to TiDB X is in development, with compatibility across versions, behavior, and integrations as the first priority.

Slide: TiDB to TiDB X. Our upgrade goal: no downtime.

Two launches built for agents

TiDB Cloud Zero gives an agent its own database instance in 8 seconds, with no signup or setup in the way.

TiDB Cloud Filesystem, now in public preview, gives agents a persistent workspace that outlasts the sandbox they run in. When an agent starts a new session in a new sandbox, its saved code, context files, and results are still there. The preview supports:

  • Git workspace resume. Restore an agent's saved Git state in another sandbox instead of cloning fresh.
  • Shared files. Access the same files from sandboxes, local tools, and CI jobs.
  • Coding-agent profile. Keep rebuildable folders like node_modules local and persist test results, logs, and patches.
  • Search by name, content, or meaning. Semantic search over files with your own embedding provider.
  • Checkpoints and forks. Checkpoint before an experiment, fork from the saved state, or roll back.

Moonshot AI, the company behind Kimi, helped shape it and already runs coding-agent work across 1 million+ persistent filesystems.

The design is simple to explain: the working repository survives the sandbox. Load metadata first and hydrate content next, work with familiar Git commands, and let authorized agents mount and share saved work across environments.

Slide: TiDB Cloud Filesystem. The working repository survives the sandbox.

Official links: TiDB Cloud Filesystem in the SCaiLE 2026 announcement, the TiDB Cloud Filesystem product page, the quick start, and the Kimi case study.

Put together, an agent can create a database, branch it, try something risky in a sandbox, and throw it away if it fails. That is how agents actually work: lots of attempts, most of them discarded.

Atlassian: TiDB at serious scale

Vinod Kumar presenting Atlassian's TiDB journey at SCaiLE 2026

Vinod Kumar on Atlassian's TiDB journey: operating relational data at internet and AI scale.

Vinod Kumar, VP and Head of Engineering at Atlassian, brought the numbers that make CIOs pay attention. The headline: for Forge SQL, Atlassian consolidated 750+ PostgreSQL clusters into 16 TiDB clusters supporting 3 million+ tables. Atlassian runs 130+ production TiDB clusters across 17 Kubernetes environments in 13 regions, on both AWS and GCP. Together they handle 70 million SQL reads and writes a month.

  • Forge. Atlassian's developer platform gives every app installation its own relational TiDB database. The densest shared clusters hold 50,000+ databases and 250,000 tables on 1,600+ pods.
  • Assets CMDB. It supports 30 million objects and 300 million relationships per tenant. With TiFlash analytical replicas, it scales to 100 million objects and 1 billion relationships.
  • DynamoDB migration. Atlassian moved 200+ internal services from Amazon DynamoDB to TiDB with zero downtime. They used bidirectional TiCDC sync, historical backfills, and shadow traffic.

The Forge model stood out to me. One database per app install is the same pattern agents need: lots of small, isolated databases running on shared infrastructure.

Official links: Atlassian in the SCaiLE 2026 announcement and how Atlassian scaled to 3 million tables on TiDB.

The agent-native customers

Alongside Atlassian and Plaud, PingCAP shared proof from companies built around agents and from long-time enterprise users.

CompanyWhat they shared
ManusScaled to 1.5 million+ TiDB Cloud clusters for apps its agents create; expanded use of Filesystem and BYOC
Moonshot AI (Kimi)1 million+ persistent filesystems for coding agents; data infrastructure costs down by an order of magnitude
PinterestRetired several in-house systems and saved around 50% on infrastructure costs

These two groups start from opposite ends. Enterprises need to add agents without building a second data stack. Agent-native companies need to become durable businesses without rebuilding their data layer. PingCAP is pitching one foundation for both.

Official links: customer proof in the SCaiLE 2026 announcement, the Manus case study, and the Kimi case study.

Plaud: from MySQL to TiDB

Yijia Zhang presenting When Memory Is the Product at SCaiLE 2026

Yijia Zhang, Head of AI and Platform at Plaud, titled his talk "When Memory Is the Product" and brought a hardware story. Plaud has shipped 2.5 million note-taking devices across 170 countries and crossed $100 million in ARR. A cellular-connected earphone device ships early next year.

Their sharded MySQL setup hit 2 walls: performance after 5 to 10 years of data, and schema changes that locked tables. Plaud moved to TiDB across 4 global regions and saw 10x throughput in stress tests.

The schema speed is what impressed me. Plaud went from 19 to 49 tables in 3 months, running 5 to 6 migrations a week.

Here is how a Plaud agent task flows end to end. Requests move through Redis queues and Kafka into TiDB, which records each step and its cost per workspace.

  1. User request
  2. Master agent plans the task
  3. Agent loads local skills
  4. Agent recalls and searches data in TiDB
  5. Agent produces output
  6. Agent acts and sends the output
  7. Changes stream through CDC into the retrieval index

Patrick Barason: picking the right tier

Patrick laid out TiDB's deployment options and announced PostgreSQL support on Starter, open to anyone for prototyping and agent workflows.

TierWhat it isStatus
Self-ManagedRun TiDB on your own infrastructure, including on premises or air-gapped; version 8.5 today, moving to TiDB X next yearAvailable
StarterServerless, scales to zero, free usage quota, copy-on-write branchingGA
Starter with PostgreSQLPostgres-compatible, with SQL embedding generation, vector search, and full-text search; open signup, no production SLA yetPublic preview
EssentialMulti-tenant managed; set a compute limit and it scales with demand, up to 110 TB storage and 100,000 resource unitsPublic preview
PremiumIsolated compute, 3-zone availability, 99.99% monthly uptime SLA, private connectivity, customer-managed keysGA, available November 2026
BYOCDatabase stays in your cloud account while PingCAP runs operations; aimed at existing Self-Managed customersPublic preview

Slide: One engine. Five ways to run it. Self-managed, Starter, Essential, Premium, BYOC.

One TiDB engine, 5 operating choices.

For production, the split is clear. Essential is multi-tenant with predictable performance and cost. Premium adds isolation, higher capacity, and customization for mission-critical workloads.

Slide: Capacity you can plan around. Essential in public preview, Premium GA November 2026.

Official links: Starter, Essential, Premium, and BYOC in the SCaiLE 2026 announcement and TiDB Cloud pricing.

He also made the case for agent-first platform features: checkpointing, branch-and-eval workflows, and scale to zero. His example: run 100 trials at once, keep the winner, kill the other 99. Scale to zero means you stop paying for compute and tokens you are not using.

Hello, PostgreSQL

The Postgres launch is a limited free public preview built to meet developers where they are. You pick MySQL-compatible or PostgreSQL-compatible Starter from the same console. The preview includes open signup, pgvector-compatible vector search, and full-text search, with defined usage and compatibility limits.

Slide: Hello, PostgreSQL. Choose a starting point: MySQL-compatible or PostgreSQL-compatible Starter.

Official links: PostgreSQL support on Starter in the SCaiLE 2026 announcement and the TiDB Cloud Starter page.

BYOC: your account, managed by TiDB

With BYOC, application data and observability stay in your cloud account. TiDB Cloud runs the control plane and reaches your data plane over PrivateLink with scoped IAM. Logs and metrics are stored in your account too.

Slide: BYOC. Your account. Managed by TiDB.

Ownership is split clearly. You own the cloud account, landing zone, permissions, and security policies. TiDB Cloud owns deployment, maintenance, monitoring, recovery workflows, and agreed service responsibilities.

Slide: BYOC. Clear ownership. Shared responsibility.

Official links: BYOC in the SCaiLE 2026 announcement and the BYOC onboarding guide.

A new TiCDC for Self-Managed

Self-Managed customers got news too: a new TiCDC architecture. Replication capacity now grows as you add nodes, where classic TiCDC flattened out. A cluster of nodes can work on one large table to catch up faster. Independent table DDLs run in parallel when it is safe, so there is less waiting.

Slide: TiCDC New Architecture. Scalability unleashed.

What is coming next

The biggest commitment on the roadmap: PingCAP will open-source the core TiDB X codebase by late December 2026.

WhenMilestone
End of November 2026TiDB Cloud Premium moves from public preview to GA
Late December 2026Core TiDB X codebase goes open source
Early 2027Plaud ships its cellular-connected hardware
October 2027Zero-downtime migration and rolling upgrade tools from TiDB to TiDB X

Release dates and stages are confirmed in the official SCaiLE 2026 announcement and the official press release.

My take

I have done 750+ interviews with data and AI leaders, and the same question keeps coming up: what does infrastructure look like when agents do most of the work? Today was the clearest answer I have heard.

3 things stayed with me.

The 99% stat changes the buyer. If agents create almost every new database, the developer experience that matters most is the one an agent sees. Provisioning in 8 seconds is the product.

Cost is the real story. Agents try a lot of things and throw most of them away. Separating compute from compute, branching, and scaling to zero are what keep that from becoming a huge bill.

The customer proof is real. Atlassian and Plaud are very different companies with very different workloads. Both are betting on the same engine for scale and for speed of change.

The open-source TiDB X release in December is the one I will watch most closely. That is when the wider community gets to test these claims for itself.

If you want the full details from PingCAP, start with the official SCaiLE 2026 announcement.

3 years of planning to be here. It was worth every one of them.

Sources

You might also like

Front Row at TiDB SCaiLE 2026: The Database Built for Billions of Agents | The Ravit Show