AI didn\u2019t just increase workloads. It exposed the part of database architecture least prepared for the future: storage.<\/p>\n\n\n\n
This pattern has repeated across industries, signaling a fundamental shift. The strategic center of database design is moving from compute to the storage layer.<\/p>\n\n\n\n
<\/span>The Shift: Storage Architecture Now Determines System Advantage<\/strong><\/span><\/h2>\n\n\n\nFor many years, improvements in compute delivered the biggest gains in database performance. That era is over.<\/p>\n\n\n\n
Modern workloads are shaped by large and fast-growing datasets, multi-modal query patterns, frequent vector operations, and multi-agent AI systems generating enormous context windows. Traffic is also far less predictable, especially in consumer-facing and AI-driven applications.<\/p>\n\n\n\n
Flipkart\u2019s<\/a> Big Billion Days illustrate this well. Clusters had to be scaled weeks in advance and scaled down slowly afterward. Even then, much of the cost went into preparing disks and replicas rather than compute.<\/p>\n\n\n\nThis challenge is not unique. Across industries, compute is no longer the primary constraint. Storage throughput, IOPS ceilings, replication overhead, and compaction pressure surface first.<\/p>\n\n\n\n
Earlier generations of distributed databases \u2014 including earlier TiDB architectures \u2014 were built on assumptions from a different era of hardware and workloads. As workloads evolved, those assumptions became limiting. Increasingly, competitive advantage depends on how deeply a system is designed around storage.<\/p>\n\n\n\n
<\/span>Three Lessons from Cursor\u2019s Database Journey<\/strong><\/span><\/h2>\n\n\n\nThis shift is clearly illustrated by Cursor\u2019s recent infrastructure journey<\/a>, shared by their CTO and co-founder in a Stanford CS 153 talk.<\/p>\n\n\n\nLesson 1: Distributed SQL is elegant \u2014 until complexity slows you down<\/strong><\/h3>\n\n\n\nCursor initially chose a Spanner-style distributed SQL system for its core indexing workload. On paper, it offered strong consistency, automatic sharding, and horizontal scalability. In practice, the team spent more time managing database behavior than shipping product, and eventually migrated the workload to a simpler managed PostgreSQL setup.<\/p>\n\n\n\n
The takeaway wasn\u2019t that distributed SQL is flawed, but that at scale, simplicity often beats theoretical elegance.<\/p>\n\n\n\n
Lesson 2: Classic databases struggle with heavy, infinite-write AI workloads<\/strong><\/h3>\n\n\n\nPostgreSQL is a strong general-purpose database, but it remains a single-node storage engine built around MVCC and vacuum. For Cursor\u2019s workload \u2014 constant updates, massive tables, and rapid data growth \u2014 tuning eventually hit a wall.<\/p>\n\n\n\n
The sustainable fix wasn\u2019t more optimization. It was a change in architecture. Cursor moved its largest, hottest table onto a system backed by object storage.<\/p>\n\n\n\n
The lesson is clear: for modern AI workloads, classic databases eventually lose to systems built on object storage.<\/p>\n\n\n\n
Lesson 3: The future data architecture is object-storage first<\/strong><\/h3>\n\n\n\nOver time, Cursor arrived at a modern pattern: object storage as the durable home for large data, with compute and query engines layered on top. Object storage handled durability, capacity, and cost-efficient scaling. Databases became compute services, not storage systems.<\/p>\n\n\n\n
<\/span>Why Object Storage Changes the Game for Databases<\/strong><\/span><\/h2>\n\n\n\nObject storage is often framed as low-cost storage for cold data. But when it becomes the foundation of a database, it changes system behavior much more deeply.<\/p>\n\n\n\n
Object storage provides immutable data, extremely high durability, and virtually unlimited capacity. Durability moves to the storage layer instead of living in local replicas, making costs predictable and lifecycle management simpler.<\/p>\n\n\n\n
Once data shifts to object storage, core database components must be rethought. Concurrency control, indexing strategy, compaction flow, caching design, recovery logic, workload isolation, and distributed execution all change. Assumptions that work for local or block storage \u2014 such as tight coupling between compute and data or replica-heavy durability \u2014 no longer apply.<\/p>\n\n\n\n![\"\"](\"https:\/\/static.pingcap.com\/files\/2025\/12\/19215110\/image-5-1024x787.png\")
<\/figure>\n\n\n\nFigure 1: <\/strong>Decoupled compute and shared object storage enable elastic scale and unified workloads.<\/em> <\/em><\/p>\n\n\n\nBecause of this, object storage cannot simply be layered onto an existing architecture. To fully capture its benefits, the system must be redesigned from the ground up.<\/p>\n\n\n\n
<\/span>Why This Matters for TiDB<\/strong><\/span><\/h2>\n\n\n\nTiDB, like many distributed SQL systems, was inspired by Google Spanner<\/a> and built around local disks or cloud volumes. Unlike many peers, it has been hardened at massive scale in mission-critical production environments.<\/p>\n\n\n\nBut Cursor\u2019s story highlights a deeper point: even the best Spanner-style systems still face fundamental pressure as AI workloads explode. Massive embedding stores, long-term histories, agent traces, and the need to serve OLTP<\/a>, analytics<\/a>, \uadf8\ub9ac\uace0 AI retrieval<\/a> over the same logical data all stress disk-centric architectures.<\/p>\n\n\n\nThat\u2019s exactly why we built TiDB X.<\/a><\/p>\n\n\n\n<\/span>TiDB X: Built for an Object-Storage World<\/strong><\/span><\/h2>\n\n\n\nTiDB X is the latest version of our distributed SQL database designed around a simple idea: object storage is the source of truth, and databases are the compute and query layer on top<\/strong>.<\/p>\n\n\n\nAll core data lives in object storage, providing cheap, durable, and independently scalable capacity. Compute is stateless and elastic, making hybrid workloads \u2014 OLTP, analytics, and AI \u2014 a first-class capability rather than a workaround. With pay-as-you-go economics in TiDB Cloud, teams pay for actual work done instead of idle clusters, aligning naturally with spiky, AI-driven workloads.<\/p>\n\n\n\n
<\/span>From One Big Database to Millions of Small Ones<\/strong><\/span><\/h2>\n\n\n\nAI and agentic systems push this architecture even further. Instead of one monolithic database, each agent may generate its own context store, short-lived state, or temporary vector index.<\/p>\n\n\n\n
This shifts the model from one large database to millions of small, elastic, short-lived ones. That model is only viable when durability lives in object storage and compute is stateless and disposable. Without this shift, AI-era architectures quickly become cost-prohibitive and operationally fragile.<\/p>\n\n\n\n
<\/span>Start with TiDB Cloud, Scale Without Rewrites<\/strong><\/span><\/h2>\n\n\n\nIf you\u2019re building an AI coding assistant, an agentic RAG system<\/a>, a multi-tenant SaaS platform, or any product with massive, fast-changing data, you face the same structural questions Cursor did.<\/p>\n\n\n\nYou can follow the familiar path \u2014 start with a traditional database, hit scaling limits, migrate workloads piece by piece, and eventually rebuild around object storage.<\/p>\n\n\n\n
Or you can start where that journey ends.<\/p>\n\n\n\n
TiDB Cloud, powered by TiDB X, gives teams an object-storage foundation from day one: distributed SQL proven at scale, hybrid workloads in one logical system, and elastic, pay-as-you-go economics built for the AI era.<\/p>\n\n\n\n
These architectural shifts are already shaping real AI systems in production. Manus, a general-purpose agentic AI platform, faced the same pressures\u2014 massive context growth, heavy write workloads<\/a>, and the need to scale without re-architecting. By adopting TiDB Cloud powered by TiDB X, they turned object storage into a foundation for viral growth and large-scale agent swarms.<\/p>\n\n\n\n
This challenge is not unique. Across industries, compute is no longer the primary constraint. Storage throughput, IOPS ceilings, replication overhead, and compaction pressure surface first.<\/p>\n\n\n\n
Earlier generations of distributed databases \u2014 including earlier TiDB architectures \u2014 were built on assumptions from a different era of hardware and workloads. As workloads evolved, those assumptions became limiting. Increasingly, competitive advantage depends on how deeply a system is designed around storage.<\/p>\n\n\n\n
<\/span>Three Lessons from Cursor\u2019s Database Journey<\/strong><\/span><\/h2>\n\n\n\nThis shift is clearly illustrated by Cursor\u2019s recent infrastructure journey<\/a>, shared by their CTO and co-founder in a Stanford CS 153 talk.<\/p>\n\n\n\nLesson 1: Distributed SQL is elegant \u2014 until complexity slows you down<\/strong><\/h3>\n\n\n\nCursor initially chose a Spanner-style distributed SQL system for its core indexing workload. On paper, it offered strong consistency, automatic sharding, and horizontal scalability. In practice, the team spent more time managing database behavior than shipping product, and eventually migrated the workload to a simpler managed PostgreSQL setup.<\/p>\n\n\n\n
The takeaway wasn\u2019t that distributed SQL is flawed, but that at scale, simplicity often beats theoretical elegance.<\/p>\n\n\n\n
Lesson 2: Classic databases struggle with heavy, infinite-write AI workloads<\/strong><\/h3>\n\n\n\nPostgreSQL is a strong general-purpose database, but it remains a single-node storage engine built around MVCC and vacuum. For Cursor\u2019s workload \u2014 constant updates, massive tables, and rapid data growth \u2014 tuning eventually hit a wall.<\/p>\n\n\n\n
The sustainable fix wasn\u2019t more optimization. It was a change in architecture. Cursor moved its largest, hottest table onto a system backed by object storage.<\/p>\n\n\n\n
The lesson is clear: for modern AI workloads, classic databases eventually lose to systems built on object storage.<\/p>\n\n\n\n
Lesson 3: The future data architecture is object-storage first<\/strong><\/h3>\n\n\n\nOver time, Cursor arrived at a modern pattern: object storage as the durable home for large data, with compute and query engines layered on top. Object storage handled durability, capacity, and cost-efficient scaling. Databases became compute services, not storage systems.<\/p>\n\n\n\n
<\/span>Why Object Storage Changes the Game for Databases<\/strong><\/span><\/h2>\n\n\n\nObject storage is often framed as low-cost storage for cold data. But when it becomes the foundation of a database, it changes system behavior much more deeply.<\/p>\n\n\n\n
Object storage provides immutable data, extremely high durability, and virtually unlimited capacity. Durability moves to the storage layer instead of living in local replicas, making costs predictable and lifecycle management simpler.<\/p>\n\n\n\n
Once data shifts to object storage, core database components must be rethought. Concurrency control, indexing strategy, compaction flow, caching design, recovery logic, workload isolation, and distributed execution all change. Assumptions that work for local or block storage \u2014 such as tight coupling between compute and data or replica-heavy durability \u2014 no longer apply.<\/p>\n\n\n\n<\/figure>\n\n\n\nFigure 1: <\/strong>Decoupled compute and shared object storage enable elastic scale and unified workloads.<\/em> <\/em><\/p>\n\n\n\nBecause of this, object storage cannot simply be layered onto an existing architecture. To fully capture its benefits, the system must be redesigned from the ground up.<\/p>\n\n\n\n
<\/span>Why This Matters for TiDB<\/strong><\/span><\/h2>\n\n\n\nTiDB, like many distributed SQL systems, was inspired by Google Spanner<\/a> and built around local disks or cloud volumes. Unlike many peers, it has been hardened at massive scale in mission-critical production environments.<\/p>\n\n\n\nBut Cursor\u2019s story highlights a deeper point: even the best Spanner-style systems still face fundamental pressure as AI workloads explode. Massive embedding stores, long-term histories, agent traces, and the need to serve OLTP<\/a>, analytics<\/a>, \uadf8\ub9ac\uace0 AI retrieval<\/a> over the same logical data all stress disk-centric architectures.<\/p>\n\n\n\nThat\u2019s exactly why we built TiDB X.<\/a><\/p>\n\n\n\n<\/span>TiDB X: Built for an Object-Storage World<\/strong><\/span><\/h2>\n\n\n\nTiDB X is the latest version of our distributed SQL database designed around a simple idea: object storage is the source of truth, and databases are the compute and query layer on top<\/strong>.<\/p>\n\n\n\nAll core data lives in object storage, providing cheap, durable, and independently scalable capacity. Compute is stateless and elastic, making hybrid workloads \u2014 OLTP, analytics, and AI \u2014 a first-class capability rather than a workaround. With pay-as-you-go economics in TiDB Cloud, teams pay for actual work done instead of idle clusters, aligning naturally with spiky, AI-driven workloads.<\/p>\n\n\n\n
<\/span>From One Big Database to Millions of Small Ones<\/strong><\/span><\/h2>\n\n\n\nAI and agentic systems push this architecture even further. Instead of one monolithic database, each agent may generate its own context store, short-lived state, or temporary vector index.<\/p>\n\n\n\n
This shifts the model from one large database to millions of small, elastic, short-lived ones. That model is only viable when durability lives in object storage and compute is stateless and disposable. Without this shift, AI-era architectures quickly become cost-prohibitive and operationally fragile.<\/p>\n\n\n\n
<\/span>Start with TiDB Cloud, Scale Without Rewrites<\/strong><\/span><\/h2>\n\n\n\nIf you\u2019re building an AI coding assistant, an agentic RAG system<\/a>, a multi-tenant SaaS platform, or any product with massive, fast-changing data, you face the same structural questions Cursor did.<\/p>\n\n\n\nYou can follow the familiar path \u2014 start with a traditional database, hit scaling limits, migrate workloads piece by piece, and eventually rebuild around object storage.<\/p>\n\n\n\n
Or you can start where that journey ends.<\/p>\n\n\n\n
TiDB Cloud, powered by TiDB X, gives teams an object-storage foundation from day one: distributed SQL proven at scale, hybrid workloads in one logical system, and elastic, pay-as-you-go economics built for the AI era.<\/p>\n\n\n\n
These architectural shifts are already shaping real AI systems in production. Manus, a general-purpose agentic AI platform, faced the same pressures\u2014 massive context growth, heavy write workloads<\/a>, and the need to scale without re-architecting. By adopting TiDB Cloud powered by TiDB X, they turned object storage into a foundation for viral growth and large-scale agent swarms.<\/p>\n\n\n\n
Lesson 1: Distributed SQL is elegant \u2014 until complexity slows you down<\/strong><\/h3>\n\n\n\nCursor initially chose a Spanner-style distributed SQL system for its core indexing workload. On paper, it offered strong consistency, automatic sharding, and horizontal scalability. In practice, the team spent more time managing database behavior than shipping product, and eventually migrated the workload to a simpler managed PostgreSQL setup.<\/p>\n\n\n\n
The takeaway wasn\u2019t that distributed SQL is flawed, but that at scale, simplicity often beats theoretical elegance.<\/p>\n\n\n\n
Lesson 2: Classic databases struggle with heavy, infinite-write AI workloads<\/strong><\/h3>\n\n\n\nPostgreSQL is a strong general-purpose database, but it remains a single-node storage engine built around MVCC and vacuum. For Cursor\u2019s workload \u2014 constant updates, massive tables, and rapid data growth \u2014 tuning eventually hit a wall.<\/p>\n\n\n\n
The sustainable fix wasn\u2019t more optimization. It was a change in architecture. Cursor moved its largest, hottest table onto a system backed by object storage.<\/p>\n\n\n\n
The lesson is clear: for modern AI workloads, classic databases eventually lose to systems built on object storage.<\/p>\n\n\n\n
Lesson 3: The future data architecture is object-storage first<\/strong><\/h3>\n\n\n\nOver time, Cursor arrived at a modern pattern: object storage as the durable home for large data, with compute and query engines layered on top. Object storage handled durability, capacity, and cost-efficient scaling. Databases became compute services, not storage systems.<\/p>\n\n\n\n
<\/span>Why Object Storage Changes the Game for Databases<\/strong><\/span><\/h2>\n\n\n\nObject storage is often framed as low-cost storage for cold data. But when it becomes the foundation of a database, it changes system behavior much more deeply.<\/p>\n\n\n\n
Object storage provides immutable data, extremely high durability, and virtually unlimited capacity. Durability moves to the storage layer instead of living in local replicas, making costs predictable and lifecycle management simpler.<\/p>\n\n\n\n
Once data shifts to object storage, core database components must be rethought. Concurrency control, indexing strategy, compaction flow, caching design, recovery logic, workload isolation, and distributed execution all change. Assumptions that work for local or block storage \u2014 such as tight coupling between compute and data or replica-heavy durability \u2014 no longer apply.<\/p>\n\n\n\n<\/figure>\n\n\n\nFigure 1: <\/strong>Decoupled compute and shared object storage enable elastic scale and unified workloads.<\/em> <\/em><\/p>\n\n\n\nBecause of this, object storage cannot simply be layered onto an existing architecture. To fully capture its benefits, the system must be redesigned from the ground up.<\/p>\n\n\n\n
<\/span>Why This Matters for TiDB<\/strong><\/span><\/h2>\n\n\n\nTiDB, like many distributed SQL systems, was inspired by Google Spanner<\/a> and built around local disks or cloud volumes. Unlike many peers, it has been hardened at massive scale in mission-critical production environments.<\/p>\n\n\n\nBut Cursor\u2019s story highlights a deeper point: even the best Spanner-style systems still face fundamental pressure as AI workloads explode. Massive embedding stores, long-term histories, agent traces, and the need to serve OLTP<\/a>, analytics<\/a>, \uadf8\ub9ac\uace0 AI retrieval<\/a> over the same logical data all stress disk-centric architectures.<\/p>\n\n\n\nThat\u2019s exactly why we built TiDB X.<\/a><\/p>\n\n\n\n<\/span>TiDB X: Built for an Object-Storage World<\/strong><\/span><\/h2>\n\n\n\nTiDB X is the latest version of our distributed SQL database designed around a simple idea: object storage is the source of truth, and databases are the compute and query layer on top<\/strong>.<\/p>\n\n\n\nAll core data lives in object storage, providing cheap, durable, and independently scalable capacity. Compute is stateless and elastic, making hybrid workloads \u2014 OLTP, analytics, and AI \u2014 a first-class capability rather than a workaround. With pay-as-you-go economics in TiDB Cloud, teams pay for actual work done instead of idle clusters, aligning naturally with spiky, AI-driven workloads.<\/p>\n\n\n\n
<\/span>From One Big Database to Millions of Small Ones<\/strong><\/span><\/h2>\n\n\n\nAI and agentic systems push this architecture even further. Instead of one monolithic database, each agent may generate its own context store, short-lived state, or temporary vector index.<\/p>\n\n\n\n
This shifts the model from one large database to millions of small, elastic, short-lived ones. That model is only viable when durability lives in object storage and compute is stateless and disposable. Without this shift, AI-era architectures quickly become cost-prohibitive and operationally fragile.<\/p>\n\n\n\n
<\/span>Start with TiDB Cloud, Scale Without Rewrites<\/strong><\/span><\/h2>\n\n\n\nIf you\u2019re building an AI coding assistant, an agentic RAG system<\/a>, a multi-tenant SaaS platform, or any product with massive, fast-changing data, you face the same structural questions Cursor did.<\/p>\n\n\n\nYou can follow the familiar path \u2014 start with a traditional database, hit scaling limits, migrate workloads piece by piece, and eventually rebuild around object storage.<\/p>\n\n\n\n
Or you can start where that journey ends.<\/p>\n\n\n\n
TiDB Cloud, powered by TiDB X, gives teams an object-storage foundation from day one: distributed SQL proven at scale, hybrid workloads in one logical system, and elastic, pay-as-you-go economics built for the AI era.<\/p>\n\n\n\n
These architectural shifts are already shaping real AI systems in production. Manus, a general-purpose agentic AI platform, faced the same pressures\u2014 massive context growth, heavy write workloads<\/a>, and the need to scale without re-architecting. By adopting TiDB Cloud powered by TiDB X, they turned object storage into a foundation for viral growth and large-scale agent swarms.<\/p>\n\n\n\n
PostgreSQL is a strong general-purpose database, but it remains a single-node storage engine built around MVCC and vacuum. For Cursor\u2019s workload \u2014 constant updates, massive tables, and rapid data growth \u2014 tuning eventually hit a wall.<\/p>\n\n\n\n
The sustainable fix wasn\u2019t more optimization. It was a change in architecture. Cursor moved its largest, hottest table onto a system backed by object storage.<\/p>\n\n\n\n
The lesson is clear: for modern AI workloads, classic databases eventually lose to systems built on object storage.<\/p>\n\n\n\n
Lesson 3: The future data architecture is object-storage first<\/strong><\/h3>\n\n\n\nOver time, Cursor arrived at a modern pattern: object storage as the durable home for large data, with compute and query engines layered on top. Object storage handled durability, capacity, and cost-efficient scaling. Databases became compute services, not storage systems.<\/p>\n\n\n\n
<\/span>Why Object Storage Changes the Game for Databases<\/strong><\/span><\/h2>\n\n\n\nObject storage is often framed as low-cost storage for cold data. But when it becomes the foundation of a database, it changes system behavior much more deeply.<\/p>\n\n\n\n
Object storage provides immutable data, extremely high durability, and virtually unlimited capacity. Durability moves to the storage layer instead of living in local replicas, making costs predictable and lifecycle management simpler.<\/p>\n\n\n\n
Once data shifts to object storage, core database components must be rethought. Concurrency control, indexing strategy, compaction flow, caching design, recovery logic, workload isolation, and distributed execution all change. Assumptions that work for local or block storage \u2014 such as tight coupling between compute and data or replica-heavy durability \u2014 no longer apply.<\/p>\n\n\n\n<\/figure>\n\n\n\nFigure 1: <\/strong>Decoupled compute and shared object storage enable elastic scale and unified workloads.<\/em> <\/em><\/p>\n\n\n\nBecause of this, object storage cannot simply be layered onto an existing architecture. To fully capture its benefits, the system must be redesigned from the ground up.<\/p>\n\n\n\n
<\/span>Why This Matters for TiDB<\/strong><\/span><\/h2>\n\n\n\nTiDB, like many distributed SQL systems, was inspired by Google Spanner<\/a> and built around local disks or cloud volumes. Unlike many peers, it has been hardened at massive scale in mission-critical production environments.<\/p>\n\n\n\nBut Cursor\u2019s story highlights a deeper point: even the best Spanner-style systems still face fundamental pressure as AI workloads explode. Massive embedding stores, long-term histories, agent traces, and the need to serve OLTP<\/a>, analytics<\/a>, \uadf8\ub9ac\uace0 AI retrieval<\/a> over the same logical data all stress disk-centric architectures.<\/p>\n\n\n\nThat\u2019s exactly why we built TiDB X.<\/a><\/p>\n\n\n\n<\/span>TiDB X: Built for an Object-Storage World<\/strong><\/span><\/h2>\n\n\n\nTiDB X is the latest version of our distributed SQL database designed around a simple idea: object storage is the source of truth, and databases are the compute and query layer on top<\/strong>.<\/p>\n\n\n\nAll core data lives in object storage, providing cheap, durable, and independently scalable capacity. Compute is stateless and elastic, making hybrid workloads \u2014 OLTP, analytics, and AI \u2014 a first-class capability rather than a workaround. With pay-as-you-go economics in TiDB Cloud, teams pay for actual work done instead of idle clusters, aligning naturally with spiky, AI-driven workloads.<\/p>\n\n\n\n
<\/span>From One Big Database to Millions of Small Ones<\/strong><\/span><\/h2>\n\n\n\nAI and agentic systems push this architecture even further. Instead of one monolithic database, each agent may generate its own context store, short-lived state, or temporary vector index.<\/p>\n\n\n\n
This shifts the model from one large database to millions of small, elastic, short-lived ones. That model is only viable when durability lives in object storage and compute is stateless and disposable. Without this shift, AI-era architectures quickly become cost-prohibitive and operationally fragile.<\/p>\n\n\n\n
<\/span>Start with TiDB Cloud, Scale Without Rewrites<\/strong><\/span><\/h2>\n\n\n\nIf you\u2019re building an AI coding assistant, an agentic RAG system<\/a>, a multi-tenant SaaS platform, or any product with massive, fast-changing data, you face the same structural questions Cursor did.<\/p>\n\n\n\nYou can follow the familiar path \u2014 start with a traditional database, hit scaling limits, migrate workloads piece by piece, and eventually rebuild around object storage.<\/p>\n\n\n\n
Or you can start where that journey ends.<\/p>\n\n\n\n
TiDB Cloud, powered by TiDB X, gives teams an object-storage foundation from day one: distributed SQL proven at scale, hybrid workloads in one logical system, and elastic, pay-as-you-go economics built for the AI era.<\/p>\n\n\n\n
These architectural shifts are already shaping real AI systems in production. Manus, a general-purpose agentic AI platform, faced the same pressures\u2014 massive context growth, heavy write workloads<\/a>, and the need to scale without re-architecting. By adopting TiDB Cloud powered by TiDB X, they turned object storage into a foundation for viral growth and large-scale agent swarms.<\/p>\n\n\n\n
Object storage is often framed as low-cost storage for cold data. But when it becomes the foundation of a database, it changes system behavior much more deeply.<\/p>\n\n\n\n
Object storage provides immutable data, extremely high durability, and virtually unlimited capacity. Durability moves to the storage layer instead of living in local replicas, making costs predictable and lifecycle management simpler.<\/p>\n\n\n\n
Once data shifts to object storage, core database components must be rethought. Concurrency control, indexing strategy, compaction flow, caching design, recovery logic, workload isolation, and distributed execution all change. Assumptions that work for local or block storage \u2014 such as tight coupling between compute and data or replica-heavy durability \u2014 no longer apply.<\/p>\n\n\n\n Figure 1: <\/strong>Decoupled compute and shared object storage enable elastic scale and unified workloads.<\/em> <\/em><\/p>\n\n\n\n Because of this, object storage cannot simply be layered onto an existing architecture. To fully capture its benefits, the system must be redesigned from the ground up.<\/p>\n\n\n\n TiDB, like many distributed SQL systems, was inspired by Google Spanner<\/a> and built around local disks or cloud volumes. Unlike many peers, it has been hardened at massive scale in mission-critical production environments.<\/p>\n\n\n\n But Cursor\u2019s story highlights a deeper point: even the best Spanner-style systems still face fundamental pressure as AI workloads explode. Massive embedding stores, long-term histories, agent traces, and the need to serve OLTP<\/a>, analytics<\/a>, \uadf8\ub9ac\uace0 AI retrieval<\/a> over the same logical data all stress disk-centric architectures.<\/p>\n\n\n\n That\u2019s exactly why we built TiDB X.<\/a><\/p>\n\n\n\n TiDB X is the latest version of our distributed SQL database designed around a simple idea: object storage is the source of truth, and databases are the compute and query layer on top<\/strong>.<\/p>\n\n\n\n All core data lives in object storage, providing cheap, durable, and independently scalable capacity. Compute is stateless and elastic, making hybrid workloads \u2014 OLTP, analytics, and AI \u2014 a first-class capability rather than a workaround. With pay-as-you-go economics in TiDB Cloud, teams pay for actual work done instead of idle clusters, aligning naturally with spiky, AI-driven workloads.<\/p>\n\n\n\n AI and agentic systems push this architecture even further. Instead of one monolithic database, each agent may generate its own context store, short-lived state, or temporary vector index.<\/p>\n\n\n\n This shifts the model from one large database to millions of small, elastic, short-lived ones. That model is only viable when durability lives in object storage and compute is stateless and disposable. Without this shift, AI-era architectures quickly become cost-prohibitive and operationally fragile.<\/p>\n\n\n\n If you\u2019re building an AI coding assistant, an agentic RAG system<\/a>, a multi-tenant SaaS platform, or any product with massive, fast-changing data, you face the same structural questions Cursor did.<\/p>\n\n\n\n You can follow the familiar path \u2014 start with a traditional database, hit scaling limits, migrate workloads piece by piece, and eventually rebuild around object storage.<\/p>\n\n\n\n Or you can start where that journey ends.<\/p>\n\n\n\n TiDB Cloud, powered by TiDB X, gives teams an object-storage foundation from day one: distributed SQL proven at scale, hybrid workloads in one logical system, and elastic, pay-as-you-go economics built for the AI era.<\/p>\n\n\n\n These architectural shifts are already shaping real AI systems in production. Manus, a general-purpose agentic AI platform, faced the same pressures\u2014 massive context growth, heavy write workloads<\/a>, and the need to scale without re-architecting. By adopting TiDB Cloud powered by TiDB X, they turned object storage into a foundation for viral growth and large-scale agent swarms.<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/span>Why This Matters for TiDB<\/strong><\/span><\/h2>\n\n\n\n
<\/span>TiDB X: Built for an Object-Storage World<\/strong><\/span><\/h2>\n\n\n\n
<\/span>From One Big Database to Millions of Small Ones<\/strong><\/span><\/h2>\n\n\n\n
<\/span>Start with TiDB Cloud, Scale Without Rewrites<\/strong><\/span><\/h2>\n\n\n\n