{"id":35060,"date":"2026-09-23T08:35:42","date_gmt":"2026-09-23T15:35:42","guid":{"rendered":"https:\/\/www.pingcap.com\/?p=35060"},"modified":"2026-09-24T08:54:06","modified_gmt":"2026-09-24T15:54:06","slug":"separation-of-compute-and-storage-lakebase-tidb-x","status":"publish","type":"post","link":"https:\/\/www.pingcap.com\/ko\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/","title":{"rendered":"Lakebase, TiDB X, and the Database Architecture AI Demands"},"content":{"rendered":"<blockquote class=\"wp-block-quote is-layout-flow wp-block-quote-is-layout-flow\">\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Key_Takeaways\"><\/span><strong>\ud575\uc2ec \uc694\uc57d<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lakebase and TiDB X both keep durable data in object storage, separate from compute.<\/li>\n\n\n\n<li>For AI agents, fast, cheap database lifecycles matter as much as query speed.<\/li>\n\n\n\n<li>Lakebase branches a single PostgreSQL primary; TiDB X brings branching to distributed SQL.<\/li>\n\n\n\n<li>TiDB Cloud Lake adds separate analytical compute through export and load, not zero-copy access.<\/li>\n<\/ul>\n<\/blockquote>\n\n\n\n<p class=\"wp-block-paragraph\">An AI coding agent can generate an application, change its schema, test several implementations, and discard most of them within a single session. Another agent might spend that session updating orders and querying months of operational history. Both need durable state, correct transactions, and fast access. They also need something query throughput doesn\u2019t measure: databases that are quick to create, cheap to leave idle, safe to experiment on, and unaffected by analysis or maintenance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Databricks\u2019 2026 PVLDB paper, <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">Lakebase: Serverless Postgres over Open Lake Storage<\/a>, and our <a href=\"https:\/\/docs.pingcap.com\/tidbcloud\/tidb-x-architecture\/\">TiDB X architecture documentation<\/a> describe two responses to this workload. They start from PostgreSQL and distributed TiDB, respectively, but converge on one principle: durable data should survive independently of the machines processing it, and different kinds of computation should receive independently managed resources. <a href=\"https:\/\/docs.pingcap.com\/tidbcloudlake\/lake-overview\/\">TiDB Cloud Lake<\/a> adds a complementary analytical service.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This blog looks beneath the phrase \u201ccompute-storage separation\u201d at how Lakebase implements it, how TiDB X approaches the same shift from distributed SQL through shared storage, database branching, and a PAX storage format in development, and what both architectures still need to prove in production.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Lakebase_A_Durable_Storage_Foundation_for_Multiple_Engines\"><\/span><strong>Lakebase: A Durable Storage Foundation for Multiple Engines<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Lakebase gives transactional databases a durable storage foundation that multiple engines can use. The paper describes a PostgreSQL service whose compute runs independently of distributed storage, with WAL and page data ultimately persisted in cloud object storage. It also uses Lakebase as the name for a broader architectural direction.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"556\" src=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-3-1024x556.jpeg\" alt=\"\" class=\"wp-image-35064\" style=\"aspect-ratio:1.8409785932721712;width:602px;height:auto\" srcset=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-3-1024x556.jpeg 1024w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-3-300x163.jpeg 300w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-3-767x417.jpeg 767w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-3-18x10.jpeg 18w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-3.jpeg 1476w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"has-text-align-center wp-block-paragraph\"><em>Figure 1. Lakebase architecture.<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Applications connect through PostgreSQL. Behind that interface, compute can be resized, suspended, or replaced; database history can be branched; and analytical engines can access a consistent view of the underlying data without executing their queries on the PostgreSQL primary.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>The Three-Generation Framework<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Databricks places this design in a three-generation framework:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Generation in the paper<\/strong><\/th><th><strong>Relationship between compute and data<\/strong><\/th><th><strong>Remaining architectural constraint<\/strong><\/th><\/tr><\/thead><tbody><tr><td>First<\/td><td>The database engine and its persistent data are tied to provisioned machines and local storage.<\/td><td>Scaling, recovery, and realistic environment creation often require substantial data movement or operational work.<\/td><\/tr><tr><td>Second<\/td><td>Database compute is separated from a distributed storage service.<\/td><td>In Databricks\u2019 characterization, storage remains internal to the vendor and tied to the database engine\u2019s access path.<\/td><\/tr><tr><td>Third<\/td><td>Durable state is externalized to object storage in an open representation, with independent transactional and analytical compute.<\/td><td>The system must coordinate versions, access, caching, and lifecycle operations across those independent components.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The paper uses conventional PostgreSQL, MySQL, and Oracle deployments to illustrate the first model, and systems such as Aurora, Socrates, and AlloyDB to illustrate the second. This is Databricks\u2019 architectural classification, not an industry certification or a complete ranking of those products. As the <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">paper\u2019s introduction and related-work discussion<\/a> frame it, the useful question is how much of the database\u2019s state remains dependent on a particular machine or execution engine.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>What Makes Lakebase Storage \u201cOpen\u201d<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Under this definition, storing files in S3 is only part of the third generation. Storage must also support independent access and meaningful database operations. Lakebase combines object persistence, PostgreSQL page semantics, versioned timelines, elastic compute, and access by other engines. These mechanisms turn shared bytes into a usable database foundation.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\u201cOpen\u201d also has a precise scope. Lakebase\u2019s persistent representation preserves PostgreSQL page semantics, with page images and WAL organized into storage layers. It is not simply a directory of Parquet files. A reader must understand the relevant metadata, page layout, and transaction visibility. The architecture reduces dependence on a single query engine; it does not make physical database data automatically understandable to every tool.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Why_AI_Agents_Need_Elastic_Database_Lifecycles\"><\/span><strong>Why AI Agents Need Elastic Database Lifecycles<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Applications and agents increasingly need elasticity in database lifecycles as well as in query execution. Earlier architectures can run AI applications, and many already offer managed operations, replicas, cloning, or autoscaling. The pressure comes from combining those capabilities at high frequency, low cost, and across different kinds of work.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Consider an agent evaluating several versions of an order-management application. Each candidate changes both code and database state. One adds an index, another changes the schema, and a third loads additional test data. A shared staging database lets these attempts interfere with each other. Full copies isolate them, but provisioning and copying can take longer than the agent\u2019s useful work. Tiny synthetic databases are cheaper but may miss the behavior that matters on production data.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Now consider the resulting application. Its production database may be quiet for most of the day, then receive a burst of traffic. A second agent might simultaneously inspect historical orders or rebuild derived data. Provisioning for the combined peak is expensive, while putting every activity on the transaction-serving machine risks poor tail latency.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Observed Pressures and Their Economics<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">The Lakebase paper identifies three related pressures: a proliferation of inexpensive applications, development that explores multiple database states, and demand for open ecosystems. Its <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">production telemetry<\/a> shows many short compute lifetimes and database creation dominated by agents. These are observations from the Databricks Lakebase service, not measurements of the entire database market, but they make the workload shift concrete. We see the same pattern on TiDB Cloud: at Manus, agents created more than 90% of new instances, and 99% of those were single-use, as we describe in <a href=\"https:\/\/www.pingcap.com\/ko\/blog\/ai-native-database\/\">why agents are becoming the primary users of AI-native databases<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The economic consequence is straightforward. If application creation becomes cheap, a fixed monthly database cost can dominate the value of each experiment. The approximate resource cost becomes:<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>retained data and history\n  + compute consumed while active\n  + storage operations and supporting services\n<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Independent persistence allows the compute term to fall when a database is idle. Shared history keeps a new branch from immediately paying for a full copy. Neither makes storage or the provider\u2019s infrastructure free, but both reduce the cost of trying another idea.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Data Access and the Mechanisms That Address It<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">There is also a data-access problem. An agent taking action needs current transactional state, while an agent explaining behavior may need broad scans and joins. Exporting everything into another system introduces freshness and integration work. Running the analysis on the transactional primary creates contention. A versioned shared storage layer allows a specialized analytical engine to process a consistent snapshot on separate compute. These are the requirements that define a <a href=\"https:\/\/www.pingcap.com\/ko\/ai\/agentic-ai\/\">database for agentic AI<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The third-generation proposal addresses these pressures through a combination of mechanisms:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Application or agent need<\/strong><\/th><th><strong>Lakebase mechanism<\/strong><\/th><th><strong>Why it helps<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Create a realistic experiment quickly<\/td><td>Copy-on-write timelines<\/td><td>A new branch initially references existing history instead of copying the dataset.<\/td><\/tr><tr><td>Pay little for idle environments<\/td><td>Independent compute and scale-to-zero<\/td><td>Durable data survives while transaction compute is stopped.<\/td><\/tr><tr><td>Resume work quickly<\/td><td>Warm VM pools and compact startup metadata<\/td><td>Provisioning a new cloud machine and copying a database are removed from the usual startup path.<\/td><\/tr><tr><td>Analyze current operational data<\/td><td>Consistent direct storage access<\/td><td>Analytical execution can run outside the PostgreSQL primary.<\/td><\/tr><tr><td>Reuse existing development knowledge<\/td><td>PostgreSQL interface and ecosystem<\/td><td>Applications and agents can use familiar SQL, drivers, and tools.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Object storage supplies the durable foundation. The database protocols and control plane make that foundation useful at application speed.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_Lakebase_Separates_Commit_Page_Reconstruction_and_Query_Execution\"><\/span><strong>How Lakebase Separates Commit, Page Reconstruction, and Query Execution<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Lakebase splits the database into components with distinct jobs: Safekeepers make commits durable, Pageservers reconstruct pages at any point in history, and compute executes queries. A logical database still has one PostgreSQL primary and optional read replicas. Storage spreads across Pageservers, but the primary does not become a horizontally scalable set of OLTP writers. The <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">paper\u2019s system overview<\/a> is explicit on this point, and it matters when comparing Lakebase with TiDB.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"658\" src=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2-1024x658.jpeg\" alt=\"\" class=\"wp-image-35063\" style=\"aspect-ratio:1.5555555555555556;width:602px;height:auto\" srcset=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2-1024x658.jpeg 1024w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2-767x493.jpeg 767w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2-300x193.jpeg 300w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2-18x12.jpeg 18w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2-1536x987.jpeg 1536w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-2.jpeg 1814w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"has-text-align-center wp-block-paragraph\"><em>Figure 2. The main data paths of Databricks\u2019 Lakebase.<\/em><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Durability, Page Reconstruction, and Branching<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Commit path.<\/strong> PostgreSQL sends its write-ahead log (WAL) to three Safekeepers spread across three availability zones, and a quorum must flush it before Lakebase acknowledges a transaction. Upload to object storage happens asynchronously, so the durability boundary is the Safekeeper quorum, not an object-store file.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Page reconstruction.<\/strong> Pageservers consume committed WAL and serve pages at a requested log sequence number (LSN), a position in the log. Image layers hold materialized page versions and delta layers hold WAL records. A Pageserver rebuilds a page by applying records to an earlier image, and compaction keeps those chains short. Compute nodes and Pageservers both cache aggressively, so cache capacity and locality remain central to performance, and Lakebase throttles the WAL producer when ingestion falls behind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Branching.<\/strong> Because pages are versioned, a branch is a child timeline that records its parent and branch LSN. Creating it is an O(1) metadata operation, not a copy proportional to database size. A branch is a snapshot with an independent future: parent changes after the fork are not visible to it, branch points are limited to retained history, and the <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">paper\u2019s section on branching<\/a> states that merging divergent branches is unsupported.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Compute Lifecycle, Analytical Access, and Benchmarks<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Compute lifecycle.<\/strong> Warm VM pools and compact startup metadata keep cloud provisioning off the startup path, and the p95 compute startup below 500 ms under those conditions. The autoscaler sizes memory from the estimated working set, not just CPU, because a database may need memory to preserve cache hits even when CPU looks idle. Fast startup does not mean a warm data cache.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Analytical access.<\/strong> Direct Access lets engines such as Lakehouse\/\/RT read PostgreSQL pages at a consistent snapshot, check MVCC visibility, and execute outside the primary. The paper\u2019s <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">Lakehouse integration design<\/a> also includes wal2delta for pipelines and Synced Tables for serving Lakehouse data back into PostgreSQL, so Lakebase supports both direct reads and synchronization depending on the workload.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Benchmarks.<\/strong> Lakebase delivers roughly 26% more TPROC-C throughput at 24 vCPUs than an anonymized second-generation baseline under a 20 ms p95 NewOrder bound, with the working set in DRAM. On TPC-H at scale factor 10, Direct Access shows about 10x lower aggregate execution time than PostgreSQL on equal hardware. Cold-cache behavior, other workloads, and end-to-end economics remain questions to measure in a deployment.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"How_TiDB_X_Approaches_the_Same_Shift_From_Distributed_SQL\"><\/span><strong>How TiDB X Approaches the Same Shift From Distributed SQL<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">With <a href=\"https:\/\/www.pingcap.com\/ko\/blog\/introducing-tidb-x-a-new-foundation-distributed-sql-ai-era\/\">TiDB X<\/a>, we approach the same architectural shift from distributed SQL. We build on a stateless SQL layer and Region-based distributed transactional storage. The remaining coupling we address lies inside the storage-serving tier, where data placement and background work still influence online capacity.<\/p>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"656\" src=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-1-1024x656.jpeg\" alt=\"TiDB X and separation of compute and storage.\" class=\"wp-image-35062\" style=\"aspect-ratio:1.5636363636363637;width:602px;height:auto\" srcset=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-1-1024x656.jpeg 1024w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-1-300x192.jpeg 300w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-1-18x12.jpeg 18w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-1-768x492.jpeg 768w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080925\/image-1.jpeg 1030w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"has-text-align-center wp-block-paragraph\"><em>Figure 3. Separated layers of TiDB X.<\/em><\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Shared Storage and the LSM Forest<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">In TiDB X, we use object storage for authoritative persistence, with cache layers above it to serve active workloads. We organize the storage engine as an LSM forest, giving each Region an independent LSM tree. Compaction, DDL, statistics, and loading use separate elastic workers, while local Raft logs and asynchronous object uploads retain a fast foreground path. Our <a href=\"https:\/\/docs.pingcap.com\/tidbcloud\/tidb-x-architecture\/#transition-from-shared-nothing-to-shared-storage\">TiDB X architecture guide<\/a> covers this storage and workload separation in detail.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">These choices let retained data, active transactional capacity, and background work grow independently. An application can retain a long interaction history without requiring online compute to grow in proportion to stored bytes. An agent-triggered index build can use temporary workers with a different resource budget from customer-facing transactions. Storage and caches still cost money; separation gives us more freedom to allocate expensive compute according to activity.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The LSM forest reinforces this separation: each Region\u2019s physical files and maintenance work are bounded by that partition. Shared object storage provides the durable location; partition-aware organization makes independent scheduling practical.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Separation of Compute and Compute<\/strong><\/h3>\n\n\n<div class=\"wp-block-image\">\n<figure class=\"aligncenter size-large is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"457\" src=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image-1024x457.png\" alt=\"Separation of compute and compute in TiDB X.\" class=\"wp-image-35061\" style=\"aspect-ratio:2.246268656716418;width:602px;height:auto\" srcset=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image-1024x457.png 1024w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image-300x134.png 300w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image-766x342.png 766w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image-18x8.png 18w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image-1536x686.png 1536w, https:\/\/static.pingcap.com\/files\/2026\/09\/24080923\/image.png 2048w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><\/figure>\n<\/div>\n\n\n<p class=\"has-text-align-center wp-block-paragraph\"><em>Figure 4. Separation of compute and compute in TiDB X.<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is how shared storage enables the principle we call separation of compute and compute. Once workers can obtain data without requiring its permanent owner to do all the processing, the database can assign different executors to different tasks. Lakebase expresses a related separation through Pageservers, PostgreSQL compute, and analytical engines. We explain how this design evolved from our shared-nothing roots in <a href=\"https:\/\/www.pingcap.com\/ko\/blog\/tidbx-origins-architecture\/\">The Making of TiDB X<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">There is no one-to-one component mapping. Lakebase\u2019s Safekeepers protect a PostgreSQL WAL stream, and its Pageservers reconstruct pages along a timeline. TiDB\u2019s Region and Raft design organizes a distributed transactional key space. Their division of transaction, storage, and maintenance responsibilities follows from those different foundations.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Two further capabilities connect TiDB X more directly to the paper\u2019s third-generation vision: database branching, which is available today, and a common PAX storage format on object storage, which we are developing. To be precise about scope: our architecture documentation covers the shared-storage foundation and branching. The PAX work is in development as of September 2026, and neither TiDB Cloud Lake nor the Manus deployment described below uses it. Branching does not include automatic merging, and our implementation should be evaluated on its own terms rather than by analogy to Lakebase\u2019s O(1) timelines.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Database Branching as an Application Primitive<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/docs.pingcap.com\/tidbcloud\/branch-overview\/?plan=starter\">Database branching<\/a> makes isolated database state an application-development primitive. A coding agent can use a branch to test a schema change, exercise generated SQL, or compare implementations without directing experimental writes at production. Both Lakebase and TiDB X therefore address the need for isolated experimentation. In TiDB X, we combine that capability with our distributed transaction and partition-scheduling foundation for production workloads over a large shared dataset.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This is a meaningful connection to third-generation architecture: the useful unit is no longer just a long-lived database server, but also a database state that an application can work with independently.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>PAX: A Common Storage Format for Mixed Workloads<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Our PAX work addresses a complementary question: how should shared data be physically organized so that different workloads can process it efficiently? We are developing a common PAX format on object storage that is intended to remain friendly to transactional processing while also accelerating some analytical workloads.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">PAX stands for Partition Attributes Across, a layout introduced in <a href=\"https:\/\/www.vldb.org\/conf\/2001\/P169.pdf\">Weaving Relations for Cache Performance<\/a> at VLDB 2001. In the original design, a page holds a group of records, but values are grouped by attribute within that page. This preserves page-level locality when reconstructing a record, while scans of selected attributes can use CPU caches more effectively. A query examining order dates and amounts, for example, need not continually bring unrelated customer-description fields into the CPU cache. The original PAX design changes in-page organization, not the amount of page I\/O, so the layout alone does not establish lower object-store traffic.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For us, the opportunity is to make TiDB X\u2019s persistent representation more useful without compromising its transactional role. PAX is not a complete analytical engine or a replacement for every specialized columnar representation; performance still depends on indexes, concurrency control, caching, and workload.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>Manus 1.5: A Production Example of Agent-Scale Churn<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Manus 1.5 provides a production example of this workload. In our <a href=\"https:\/\/www.pingcap.com\/ko\/blog\/how-manus-1-5-uses-tidb-x-to-let-agents-ship-full-stack-apps-at-scale\/\">engineering story on how Manus 1.5 uses TiDB X<\/a>, we reported that Manus agents created tens of thousands of isolated <a href=\"https:\/\/www.pingcap.com\/ko\/tidb\/cloud\/\">TiDB Cloud<\/a> clusters in parallel, with individual clusters ready in seconds.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The deployment model runs from tenants to applications to clusters and branches. Creation and schema-setup bursts alternate with idle periods and returning traffic. In that case study, we connect these demands to shared object storage, elastic compute, online DDL, branching, and Request Unit-based cost visibility.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The architectural lesson is that scale includes the number and turnover of independent database environments, not just transactions per second. Agents need usable, isolated state at the pace they generate software, which is exactly Lakebase\u2019s lifecycle argument. The <a href=\"https:\/\/www.pingcap.com\/ko\/case-study\/manus-agentic-ai-database-tidb\/\">Manus customer story<\/a> covers the business context behind the migration.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Integrating_TiDB_X_With_TiDB_Cloud_Lake_for_Analytical_Compute\"><\/span><strong>Integrating TiDB X With TiDB Cloud Lake for Analytical Compute<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/docs.pingcap.com\/tidbcloudlake\/lake-overview\/\">TiDB Cloud Lake<\/a> gives us a separate service for broad scans, aggregations, and retrieval. Currently in public preview, it supports ANSI SQL, semi-structured processing, vector search, full-text search, and geospatial capabilities. The division is straightforward: TiDB X serves transactional application state, and Cloud Lake provides independently provisioned analytical warehouses.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Each Cloud Lake Warehouse has its own compute resources, which can scale with demand and be released when idle while persisted data remains available. As the <a href=\"https:\/\/docs.pingcap.com\/tidbcloudlake\/tidb-cloud-lake-architecture\/\">Cloud Lake architecture documentation<\/a> describes, its engine combines query optimization with vectorized, pipelined execution. A Raft-backed metadata service manages schemas, resource information, and permissions. Native tables use FuseEngine: compressed columnar data in object storage, with indexes such as MinMax and Bloom filters for pruning work. Both products separate compute from storage, but their native storage representations are different.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>A Batch Integration Pattern<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">You can assemble a concrete batch integration from documented capabilities today:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Export a consistent snapshot.<\/strong> <a href=\"https:\/\/www.pingcap.com\/ko\/tidb-cloud-starter\/\">TiDB Cloud \uc2a4\ud0c0\ud130<\/a> and Essential can <a href=\"https:\/\/docs.pingcap.com\/tidbcloud\/serverless-export\/\">export CSV data to S3<\/a> using separate compute; Starter also supports Parquet export. The documented export limit is currently 1 TiB, and larger exports require support coordination.<\/li>\n\n\n\n<li><strong>Load it into Cloud Lake.<\/strong> Following the <a href=\"https:\/\/docs.pingcap.com\/tidbcloudlake\/integrate-with-amazon-s3\/\">Cloud Lake S3 integration guide<\/a>, configure an S3 data source, choose the exported files, map the target schema, and run an integration task using a Lake Warehouse. Lake accepts both CSV and Parquet.<\/li>\n\n\n\n<li><strong>Analyze on separate compute.<\/strong> Run aggregations or evaluation queries over the loaded data while TiDB X continues serving application transactions. Record the snapshot boundary so consumers know which version of operational state they are analyzing.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">This is a composition of export and ingestion features, not a native zero-copy connector. It creates an analytical copy. Freshness depends on export and ingestion completion, and recurring snapshots need explicit replacement or versioning so repeated loads do not duplicate records. Lake\u2019s <a href=\"https:\/\/docs.pingcap.com\/tidbcloudlake\/integrate-with-amazon-s3\/\">continuous S3 ingestion<\/a> discovers new files; it is not, by itself, replication of source updates and deletes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>How This Compares With Lakebase Direct Access<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">This resembles Databricks\u2019 separation of transactional and analytical execution, but the access paths differ: Lakebase\u2019s Direct Access reads versioned PostgreSQL pages, while this pattern loads a copy into Lake-native storage using one of the paths in the <a href=\"https:\/\/docs.pingcap.com\/tidbcloudlake\/data-integration-overview\/\">Cloud Lake data integration overview<\/a>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Closer integration could reduce data movement and representation conversion. Our PAX work makes that an interesting engineering direction, but it would require agreed metadata, snapshot visibility, and access-control semantics between the two services, and we treat it as future work.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"What_Comes_Next_Making_Database_State_as_Manageable_as_Compute\"><\/span><strong>What Comes Next: Making Database State as Manageable as Compute<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The future of this direction depends on making database state as manageable as compute. The directions below reflect our architectural outlook, not an announced TiDB X roadmap.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The first is a lifecycle API for state: create a consistent snapshot, attach an executor, branch for an experiment, retain a result, and expire what is no longer needed, all integrated with agent permissions, retention policies, and resource budgets. The goal is an experiment that is easy to reproduce and safe to retire, not merely a database that is easy to create.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The second is tighter coordination between transactional and analytical services, measured by how reliably an agent can combine current actions with historical evidence rather than by how many engines can connect to object storage. The third is scheduling tied to intent. An interactive action has a strict latency target while a batch evaluation can trade time for cost, and once execution is separated, a control plane can choose compute, cache, and priority for each.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Isolation also needs precise semantics. An isolated compute group protects a resource budget, a branch protects production from experimental writes, and an authorization policy controls what an agent can see or change. A dependable platform needs all three, plus an explicit, conflict-aware path for applying a successful experiment to live data.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>The Practical Limits to Measure<\/strong><\/h3>\n\n\n\n<p class=\"wp-block-paragraph\">Separation has costs. The <a href=\"https:\/\/www.vldb.org\/pvldb\/vol19\/p4385-pandis.pdf\">Lakebase paper reports<\/a> approximately 7x Pageserver storage amplification relative to the logical current database, including retained history, and Lakebase\u2019s shared components apply backpressure when they fall behind. Fast startup does not eliminate cache warming, and a separate analytical executor still shares storage and network capacity. TiDB X faces the same general need to manage locality, background debt, and shared-resource demand, though neither the paper nor our documentation quantifies identical costs for both systems.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Object storage prices alone cannot tell you whether an architecture is efficient. Evaluate the complete service instead:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Time to a first successful query.<\/li>\n\n\n\n<li>Time to stable performance after a burst.<\/li>\n\n\n\n<li>Transaction tail latency during maintenance.<\/li>\n\n\n\n<li>Total retained bytes across branches.<\/li>\n\n\n\n<li>Cost per completed application task.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">As agents produce more applications, databases will be judged on lifecycle as much as execution: how quickly they establish trustworthy state, how safely they explore alternatives, and how economically they preserve results. For the agent building an order-management application, that means attaching compute to a known state, testing a change in isolation, analyzing the result without disrupting live orders, and releasing resources without losing what matters. Lakebase and TiDB X reach for that workflow from different starting points; with TiDB X, we bring it to horizontally scalable distributed SQL.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If you\u2019re building agent workflows that need isolated, disposable database state, <a href=\"https:\/\/tidbcloud.com\/free-trial\/\">start a free TiDB Cloud Starter cluster<\/a> and follow the <a href=\"https:\/\/docs.pingcap.com\/tidbcloud\/branch-overview\/?plan=starter\">branching guide<\/a> to give your first agent its own branch.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><span class=\"ez-toc-section\" id=\"Frequently_Asked_Questions\"><\/span><strong>Frequently Asked Questions<\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is Lakebase?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lakebase is Databricks\u2019 serverless PostgreSQL service and the name for the architecture described in its PVLDB paper.<\/li>\n\n\n\n<li>It runs PostgreSQL compute independently of storage, with WAL and page data persisted in cloud object storage.<\/li>\n\n\n\n<li>It supports copy-on-write branching and direct analytical access to a consistent snapshot.<\/li>\n\n\n\n<li>Databricks positions it as a third-generation database architecture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How is TiDB X Different From Lakebase?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Both persist durable data in object storage and manage compute independently, but they start from different foundations.<\/li>\n\n\n\n<li>Lakebase has one PostgreSQL primary per logical database, with storage spread across Pageservers.<\/li>\n\n\n\n<li>TiDB X is a distributed SQL database with a stateless SQL layer, Region-based transactional storage with Raft, and separate elastic workers for compaction, DDL, statistics, and loading.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Does TiDB X Support Database Branching?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Yes. TiDB Cloud offers <a href=\"https:\/\/docs.pingcap.com\/tidbcloud\/branch-overview\/?plan=starter\" target=\"_blank\" rel=\"noopener\">database branching<\/a>, which lets an agent or developer test schema changes, generated SQL, or alternative implementations without writing to production.<\/li>\n\n\n\n<li>Branching does not include automatic merging, so applying a successful change to live data remains an explicit operation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Can TiDB Cloud Lake Read TiDB X Storage Directly?<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not today. The documented path exports a consistent snapshot from TiDB Cloud Starter or Essential to S3 and loads it into Cloud Lake, which creates an analytical copy.<\/li>\n\n\n\n<li>A direct-storage connector would require agreed metadata, snapshot visibility, and access-control semantics, which we treat as future work.<\/li>\n<\/ul>","protected":false},"excerpt":{"rendered":"<p>An AI coding agent can generate an application, change its schema, test several implementations, and discard most of them within a single session. Another agent might spend that session updating orders and querying months of operational history. Both need durable state, correct transactions, and fast access. They also need something query throughput doesn\u2019t measure: databases [&hellip;]<\/p>\n","protected":false},"author":99,"featured_media":35070,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[484,147,525,31,440],"class_list":["post-35060","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering","tag-database-branching","tag-distributed-sql","tag-lakebase","tag-tidb-cloud","tag-tidb-x"],"acf":[],"featured_image_src":"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg","author_info":{"display_name":"Jinpeng Zhang","author_link":"https:\/\/www.pingcap.com\/ko\/blog\/author\/jinpeng-zhang\/"},"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v28.2 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Lakebase vs. TiDB X: Separation of Compute and Storage<\/title>\n<meta name=\"description\" content=\"How Lakebase and TiDB X use separation of compute and storage to give AI agents fast branching, elastic compute, and separate analytics.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.pingcap.com\/ko\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/\" \/>\n<meta property=\"og:locale\" content=\"ko_KR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Lakebase vs. TiDB X: Separation of Compute and Storage\" \/>\n<meta property=\"og:description\" content=\"How Lakebase and TiDB X use separation of compute and storage to give AI agents fast branching, elastic compute, and separate analytics.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.pingcap.com\/ko\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/\" \/>\n<meta property=\"og:site_name\" content=\"TiDB\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/pingcap2015\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-23T15:35:42+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-24T15:54:06+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"1800\" \/>\n\t<meta property=\"og:image:height\" content=\"600\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Jinpeng Zhang\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@PingCAP\" \/>\n<meta name=\"twitter:site\" content=\"@PingCAP\" \/>\n<meta name=\"twitter:label1\" content=\"\uae00\uc4f4\uc774\" \/>\n\t<meta name=\"twitter:data1\" content=\"Jinpeng Zhang\" \/>\n\t<meta name=\"twitter:label2\" content=\"\uc608\uc0c1 \ub418\ub294 \ud310\ub3c5 \uc2dc\uac04\" \/>\n\t<meta name=\"twitter:data2\" content=\"19\ubd84\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/\"},\"author\":{\"name\":\"Jinpeng Zhang\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#\\\/schema\\\/person\\\/048b34d093ce7fd733173cc576ab6b29\"},\"headline\":\"Lakebase, TiDB X, and the Database Architecture AI Demands\",\"datePublished\":\"2026-09-23T15:35:42+00:00\",\"dateModified\":\"2026-09-24T15:54:06+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/\"},\"wordCount\":3717,\"publisher\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2026\\\/09\\\/24082925\\\/Blog-Feature.jpg\",\"keywords\":[\"Database Branching\",\"Distributed SQL\",\"Lakebase\",\"TiDB Cloud\",\"TiDB X\"],\"articleSection\":[\"Engineering\"],\"inLanguage\":\"ko-KR\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/\",\"url\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/\",\"name\":\"Lakebase vs. TiDB X: Separation of Compute and Storage\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2026\\\/09\\\/24082925\\\/Blog-Feature.jpg\",\"datePublished\":\"2026-09-23T15:35:42+00:00\",\"dateModified\":\"2026-09-24T15:54:06+00:00\",\"description\":\"How Lakebase and TiDB X use separation of compute and storage to give AI agents fast branching, elastic compute, and separate analytics.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#breadcrumb\"},\"inLanguage\":\"ko-KR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"ko-KR\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#primaryimage\",\"url\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2026\\\/09\\\/24082925\\\/Blog-Feature.jpg\",\"contentUrl\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2026\\\/09\\\/24082925\\\/Blog-Feature.jpg\",\"width\":1800,\"height\":600},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/blog\\\/separation-of-compute-and-storage-lakebase-tidb-x\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.pingcap.com\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Lakebase, TiDB X, and the Database Architecture AI Demands\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#website\",\"url\":\"https:\\\/\\\/www.pingcap.com\\\/\",\"name\":\"TiDB\",\"description\":\"TiDB | SQL at Scale\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.pingcap.com\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"ko-KR\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#organization\",\"name\":\"PingCAP\",\"url\":\"https:\\\/\\\/www.pingcap.com\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"ko-KR\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2021\\\/11\\\/pingcap-logo.png\",\"contentUrl\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2021\\\/11\\\/pingcap-logo.png\",\"width\":811,\"height\":232,\"caption\":\"PingCAP\"},\"image\":{\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/facebook.com\\\/pingcap2015\",\"https:\\\/\\\/x.com\\\/PingCAP\",\"https:\\\/\\\/linkedin.com\\\/company\\\/pingcap\",\"https:\\\/\\\/youtube.com\\\/channel\\\/UCuq4puT32DzHKT5rU1IZpIA\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.pingcap.com\\\/#\\\/schema\\\/person\\\/048b34d093ce7fd733173cc576ab6b29\",\"name\":\"Jinpeng Zhang\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"ko-KR\",\"@id\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2022\\\/10\\\/17234942\\\/avatar.jpg\",\"url\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2022\\\/10\\\/17234942\\\/avatar.jpg\",\"contentUrl\":\"https:\\\/\\\/static.pingcap.com\\\/files\\\/2022\\\/10\\\/17234942\\\/avatar.jpg\",\"caption\":\"Jinpeng Zhang\"},\"description\":\"Senior Engineering Director\",\"url\":\"https:\\\/\\\/www.pingcap.com\\\/ko\\\/blog\\\/author\\\/jinpeng-zhang\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Lakebase vs. TiDB X: Separation of Compute and Storage","description":"How Lakebase and TiDB X use separation of compute and storage to give AI agents fast branching, elastic compute, and separate analytics.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.pingcap.com\/ko\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/","og_locale":"ko_KR","og_type":"article","og_title":"Lakebase vs. TiDB X: Separation of Compute and Storage","og_description":"How Lakebase and TiDB X use separation of compute and storage to give AI agents fast branching, elastic compute, and separate analytics.","og_url":"https:\/\/www.pingcap.com\/ko\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/","og_site_name":"TiDB","article_publisher":"https:\/\/facebook.com\/pingcap2015","article_published_time":"2026-09-23T15:35:42+00:00","article_modified_time":"2026-09-24T15:54:06+00:00","og_image":[{"width":1800,"height":600,"url":"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg","type":"image\/jpeg"}],"author":"Jinpeng Zhang","twitter_card":"summary_large_image","twitter_creator":"@PingCAP","twitter_site":"@PingCAP","twitter_misc":{"\uae00\uc4f4\uc774":"Jinpeng Zhang","\uc608\uc0c1 \ub418\ub294 \ud310\ub3c5 \uc2dc\uac04":"19\ubd84"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#article","isPartOf":{"@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/"},"author":{"name":"Jinpeng Zhang","@id":"https:\/\/www.pingcap.com\/#\/schema\/person\/048b34d093ce7fd733173cc576ab6b29"},"headline":"Lakebase, TiDB X, and the Database Architecture AI Demands","datePublished":"2026-09-23T15:35:42+00:00","dateModified":"2026-09-24T15:54:06+00:00","mainEntityOfPage":{"@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/"},"wordCount":3717,"publisher":{"@id":"https:\/\/www.pingcap.com\/#organization"},"image":{"@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#primaryimage"},"thumbnailUrl":"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg","keywords":["Database Branching","Distributed SQL","Lakebase","TiDB Cloud","TiDB X"],"articleSection":["Engineering"],"inLanguage":"ko-KR"},{"@type":"WebPage","@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/","url":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/","name":"Lakebase vs. TiDB X: Separation of Compute and Storage","isPartOf":{"@id":"https:\/\/www.pingcap.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#primaryimage"},"image":{"@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#primaryimage"},"thumbnailUrl":"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg","datePublished":"2026-09-23T15:35:42+00:00","dateModified":"2026-09-24T15:54:06+00:00","description":"How Lakebase and TiDB X use separation of compute and storage to give AI agents fast branching, elastic compute, and separate analytics.","breadcrumb":{"@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#breadcrumb"},"inLanguage":"ko-KR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/"]}]},{"@type":"ImageObject","inLanguage":"ko-KR","@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#primaryimage","url":"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg","contentUrl":"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg","width":1800,"height":600},{"@type":"BreadcrumbList","@id":"https:\/\/www.pingcap.com\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.pingcap.com\/"},{"@type":"ListItem","position":2,"name":"Lakebase, TiDB X, and the Database Architecture AI Demands"}]},{"@type":"WebSite","@id":"https:\/\/www.pingcap.com\/#website","url":"https:\/\/www.pingcap.com\/","name":"\ud2f0DB","description":"TiDB | SQL at Scale","publisher":{"@id":"https:\/\/www.pingcap.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.pingcap.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"ko-KR"},{"@type":"Organization","@id":"https:\/\/www.pingcap.com\/#organization","name":"PingCAP","url":"https:\/\/www.pingcap.com\/","logo":{"@type":"ImageObject","inLanguage":"ko-KR","@id":"https:\/\/www.pingcap.com\/#\/schema\/logo\/image\/","url":"https:\/\/static.pingcap.com\/files\/2021\/11\/pingcap-logo.png","contentUrl":"https:\/\/static.pingcap.com\/files\/2021\/11\/pingcap-logo.png","width":811,"height":232,"caption":"PingCAP"},"image":{"@id":"https:\/\/www.pingcap.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/pingcap2015","https:\/\/x.com\/PingCAP","https:\/\/linkedin.com\/company\/pingcap","https:\/\/youtube.com\/channel\/UCuq4puT32DzHKT5rU1IZpIA"]},{"@type":"Person","@id":"https:\/\/www.pingcap.com\/#\/schema\/person\/048b34d093ce7fd733173cc576ab6b29","name":"Jinpeng Zhang","image":{"@type":"ImageObject","inLanguage":"ko-KR","@id":"https:\/\/static.pingcap.com\/files\/2022\/10\/17234942\/avatar.jpg","url":"https:\/\/static.pingcap.com\/files\/2022\/10\/17234942\/avatar.jpg","contentUrl":"https:\/\/static.pingcap.com\/files\/2022\/10\/17234942\/avatar.jpg","caption":"Jinpeng Zhang"},"description":"Senior Engineering Director","url":"https:\/\/www.pingcap.com\/ko\/blog\/author\/jinpeng-zhang\/"}]}},"grav_blocks":false,"card_markup":"<a class=\"card-resource bg-white\" href=\"https:\/\/www.pingcap.com\/ko\/blog\/separation-of-compute-and-storage-lakebase-tidb-x\/\"><div class=\"card-resource__image-container\"><img class=\"card-resource__image\" alt=\"Blog - Feature\" src=\"https:\/\/static.pingcap.com\/files\/2026\/09\/24082925\/Blog-Feature.jpg\" loading=\"lazy\" width=1800 height=600 \/><\/div><div class=\"card-resource__content-container\"><div class=\"card-resource__content-head\"><div class=\"card-resource__category\">Engineering<\/div><\/div><h5 class=\"card-resource__title\">Lakebase, TiDB X, and the Database Architecture AI Demands<\/h5><\/div><\/a>","_links":{"self":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/posts\/35060","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/users\/99"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/comments?post=35060"}],"version-history":[{"count":8,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/posts\/35060\/revisions"}],"predecessor-version":[{"id":35076,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/posts\/35060\/revisions\/35076"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/media\/35070"}],"wp:attachment":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/media?parent=35060"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/categories?post=35060"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/tags?post=35060"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}