{"id":24043,"date":"2025-06-17T23:17:57","date_gmt":"2025-06-18T06:17:57","guid":{"rendered":"http:\/\/dev-en.pingcap.com\/?page_id=23709"},"modified":"2026-03-24T11:19:54","modified_gmt":"2026-03-24T18:19:54","slug":"horizontal-scaling-vs-vertical-scaling","status":"publish","type":"page","link":"https:\/\/www.pingcap.com\/ko\/horizontal-scaling-vs-vertical-scaling\/","title":{"rendered":"Pillar Page-Horizontal Scaling"},"content":{"rendered":"","protected":false},"excerpt":{"rendered":"","protected":false},"author":184,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"templates\/page-pillar-page.php","meta":{"ub_ctt_via":""},"class_list":["post-24043","page","type-page","status-publish","hentry"],"acf":[],"featured_image_src":null,"yoast_head":"\nHorizontal Scaling vs. Vertical Scaling: Choosing the Right Strategy<\/title>\n<meta name=\"description\" content=\"Explore horizontal vs. vertical scaling for data-intensive applications. Understand their trade-offs and choose the right strategy.\" \/>\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\/horizontal-scaling-vs-vertical-scaling\/\" \/>\n<meta property=\"og:locale\" content=\"ko_KR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Horizontal Scaling vs. Vertical Scaling: Choosing the Right Strategy\" \/>\n<meta property=\"og:description\" content=\"Explore horizontal vs. vertical scaling for data-intensive applications. Understand their trade-offs and choose the right strategy.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.pingcap.com\/ko\/horizontal-scaling-vs-vertical-scaling\/\" \/>\n<meta property=\"og:site_name\" content=\"TiDB\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/pingcap2015\" \/>\n<meta property=\"article:modified_time\" content=\"2026-03-24T18:19:54+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/static.pingcap.com\/files\/2024\/09\/11005522\/Homepage-Ad.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1440\" \/>\n\t<meta property=\"og:image:height\" content=\"714\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@PingCAP\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/\",\"url\":\"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/\",\"name\":\"Horizontal Scaling vs. Vertical Scaling: Choosing the Right Strategy\",\"isPartOf\":{\"@id\":\"https:\/\/www.pingcap.com\/#website\"},\"datePublished\":\"2025-06-18T06:17:57+00:00\",\"dateModified\":\"2026-03-24T18:19:54+00:00\",\"description\":\"Explore horizontal vs. vertical scaling for data-intensive applications. Understand their trade-offs and choose the right strategy.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/#breadcrumb\"},\"inLanguage\":\"ko-KR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.pingcap.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Pillar Page-Horizontal Scaling\"}]},{\"@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\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Horizontal Scaling vs. Vertical Scaling: Choosing the Right Strategy","description":"Explore horizontal vs. vertical scaling for data-intensive applications. Understand their trade-offs and choose the right strategy.","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\/horizontal-scaling-vs-vertical-scaling\/","og_locale":"ko_KR","og_type":"article","og_title":"Horizontal Scaling vs. Vertical Scaling: Choosing the Right Strategy","og_description":"Explore horizontal vs. vertical scaling for data-intensive applications. Understand their trade-offs and choose the right strategy.","og_url":"https:\/\/www.pingcap.com\/ko\/horizontal-scaling-vs-vertical-scaling\/","og_site_name":"TiDB","article_publisher":"https:\/\/facebook.com\/pingcap2015","article_modified_time":"2026-03-24T18:19:54+00:00","og_image":[{"width":1440,"height":714,"url":"https:\/\/static.pingcap.com\/files\/2024\/09\/11005522\/Homepage-Ad.png","type":"image\/png"}],"twitter_card":"summary_large_image","twitter_site":"@PingCAP","schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/","url":"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/","name":"Horizontal Scaling vs. Vertical Scaling: Choosing the Right Strategy","isPartOf":{"@id":"https:\/\/www.pingcap.com\/#website"},"datePublished":"2025-06-18T06:17:57+00:00","dateModified":"2026-03-24T18:19:54+00:00","description":"Explore horizontal vs. vertical scaling for data-intensive applications. Understand their trade-offs and choose the right strategy.","breadcrumb":{"@id":"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/#breadcrumb"},"inLanguage":"ko-KR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.pingcap.com\/horizontal-scaling-vs-vertical-scaling\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.pingcap.com\/"},{"@type":"ListItem","position":2,"name":"Pillar Page-Horizontal Scaling"}]},{"@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"]}]}},"grav_blocks":[{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<p>Data-intensive applications generate and consume data at an unprecedented rate, placing immense pressure on underlying database scaling strategies. User expectations for performance and availability are higher than ever, demanding instantaneous results and seamless handling of fluctuating loads. Consequently, a database’s ability to scale\u2014adjusting its capacity to meet demand\u2014is a fundamental requirement for business success.<\/p>\n<p>Effective scalability <a href=\"https:\/\/www.dbta.com\/Editorial\/Think-About-It\/Scalability-and-Performance-Different-but-Crucial-Database-Management-Capabilities-161866.aspx\">ensures applications remain responsive and efficient<\/a>, preventing performance degradation, slow queries, user frustration, downtime, and lost revenue. Scalability includes both expansion (scale up vs. scale out) and contraction (scaling down or in) to optimize resources and reduce costs.<\/p>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">Organizations typically face two primary scaling strategies:<\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Horizontal Scaling (Scaling Out):<\/b><span style=\"font-weight: 400;\"> Adding more machines to distribute the workload.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Vertical Scaling (Scaling Up):<\/b><span style=\"font-weight: 400;\"> Enhancing the power of a single machine.<\/span><\/li>\n<\/ol>\n<h2>Which Database Scaling Approach Should I Choose: Scale Up vs. Scale Out?<\/h2>\n<p><span style=\"font-weight: 400;\">If your workloads are highly dynamic, require high availability, or need to handle millions of concurrent requests, horizontal scaling is likely the better fit. For simpler architectures or predictable growth, vertical scaling may offer short-term simplicity, even if it comes with hard limits.<\/span><\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<table style=\"width: 100%; height: 200px; border-collapse: collapse; background-color: #c0e0ef; border-style: none;\">\n<tbody>\n<tr>\n<td style=\"width: 100%;\"><strong>Choose Vertical Scaling if:<\/strong><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\">You need a fast and simple upgrade path<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">You\u2019re dealing with modest growth<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">You\u2019re not yet constrained by single-node limits<\/li>\n<\/ol>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""},{"type":"wysiwyg","wysiwyg":"<table style=\"width: 100%; height: 200px; border-collapse: collapse; background-color: #c0e0ef; border-style: none;\">\n<tbody>\n<tr>\n<td style=\"width: 100%;\"><strong>Choose Horizontal Scaling if:<\/strong><\/p>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\">You need scale-out elasticity<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">You can\u2019t tolerate single points of failure<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\">You\u2019re building for long-term growth or distributed workloads<\/li>\n<\/ol>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<p><span style=\"font-weight: 400;\">Choosing the right strategy impacts performance, cost, complexity, and long-term viability. Neither approach is universally superior; understanding their trade-offs is crucial for addressing current bottlenecks and ensuring sustainable growth. In the cloud era, cloud database scaling is linked to business agility and cost-efficiency, making this choice central to cloud architecture.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This guide explores both strategies, compares their strengths and weaknesses, examines the business drivers for scaling, and provides a modern solution leveraging horizontal scaling.<\/span><\/p>\n <div class=\"pillar-cta \" style=\"background-image: url(https:\/\/static.pingcap.com\/files\/2025\/06\/29200020\/CTA-Backgroud.png)\"> <div class=\"pillar-cta-container\"> <div class=\"image-container\"> <img alt=\"Pillar Page-Horizontal Scaling\" src=\"https:\/\/static.pingcap.com\/files\/2025\/06\/29200045\/SaaS-cover-image.png\" \/> <\/div> <div class=\"content-container\"> <div class=\"title\">Discover how leading SaaS teams horizontally scale to millions of tables and support AI-native workloads.<\/div> <div> <a class=\"button button-white\" href=\"https:\/\/www.pingcap.com\/ebook-whitepaper\/scaling-saas-platforms-real-world-strategies-high-growth-resilience\/\">Download White Paper<\/a> <\/div> <\/div> <\/div> <\/div>\n<h2>What is Horizontal Scaling (Scaling Out)?<\/h2>\n<p>Horizontal scaling (“scaling out”) adds <i><span style=\"font-weight: 400;\">more machines<\/span><\/i><span style=\"font-weight: 400;\"> (nodes or instances) to a resource pool and distributes the workload across them, like adding lanes to a highway.<\/span><\/p>\n<h3>How It Works<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">Horizontal scaling uses a distributed architecture:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Load Balancing:<\/b><span style=\"font-weight: 400;\"> Distributes incoming requests across multiple servers.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Database Sharding\/Partitioning:<\/b><span style=\"font-weight: 400;\"> Divides data into subsets stored on separate nodes.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Database Replication:<\/b><span style=\"font-weight: 400;\"> Maintains data copies on multiple nodes for read scaling or high availability.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Distributed Frameworks:<\/b><span style=\"font-weight: 400;\"> Technologies like Kubernetes manage scaling across machine clusters.<\/span><\/li>\n<\/ul>\n<div style=\"width: 2102px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/static.pingcap.com\/files\/2025\/07\/18022910\/Figure-1.png\" alt=\"Figure 1\" width=\"2092\" height=\"802\" \/><p class=\"wp-caption-text\">Figure 1. A representation of horizontal scaling in a typical multi-tenant SaaS architecture.<\/p><\/div>\n<p><span style=\"font-weight: 400;\">Implementation typically requires designing applications for a distributed environment.<\/span><\/p>\n<h3>Horizontal Scaling Advantages<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>High Scalability & Elasticity:<\/b><span style=\"font-weight: 400;\"> Offers virtually limitless scaling by adding nodes. Highly elastic, allowing easy scaling out and in to match demand and optimize costs.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>High Availability & Fault Tolerance:<\/b><span style=\"font-weight: 400;\"> Eliminates single points of failure; if one node fails, others continue operating. Enables rolling updates without downtime. Crucial for mission-critical systems.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Potential Performance Gains:<\/b><span style=\"font-weight: 400;\"> Distributes load, preventing bottlenecks. Ideal for parallel processing and high concurrency. Geographic distribution can reduce latency.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Cost-Effectiveness (Long-Term):<\/b><span style=\"font-weight: 400;\"> Often uses commodity hardware, offering better price\/performance at scale. Costs are more linear and predictable. Reduced downtime lowers overall costs. Supports pay-as-you-go models.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Flexibility & Future-Proofing:<\/b><span style=\"font-weight: 400;\"> Adapts to changing workloads. Allows adding newer, efficient nodes over time. Supports varied node configurations.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Auto-Sharding Capability<\/b><span style=\"font-weight: 400;\">: Automatically handles data sharding and rebalancing across nodes, eliminating the need for manual partitioning and complex data distribution logic. Reduces operational overhead, simplifies scaling, and ensures consistent performance as workloads grow or shift.<\/span><\/li>\n<\/ul>\n <div class=\"pillar-cta \" style=\"background-image: url()\"> <div class=\"pillar-cta-container\"> <div class=\"image-container\"> <img alt=\"Pillar Page-Horizontal Scaling\" src=\"https:\/\/static.pingcap.com\/files\/2025\/06\/22090645\/dify-logo-white.svg\" \/> <\/div> <div class=\"content-container\"> <div class=\"title\">Find out how Dify consolidated 500,000+ SQLite containers into a single horizontally scalable database cluster.<\/div> <div> <a class=\"button button-white\" href=\"https:\/\/www.pingcap.com\/case-study\/dify-consolidates-massive-database-containers-into-one-unified-system-with-tidb\/\">Read Case Study<\/a> <\/div> <\/div> <\/div> <\/div>\n<h3>Horizontal Scaling Disadvantages & Limitations<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Increased Complexity:<\/b><span style=\"font-weight: 400;\"> Managing distributed systems (multiple nodes, load balancers, data distribution) is more complex. Requires specialized skills.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Application Architecture Changes:<\/b><span style=\"font-weight: 400;\"> Often requires significant application redesign for distributed operation.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Data Consistency Challenges:<\/b><span style=\"font-weight: 400;\"> Ensuring consistency across nodes, especially for ACID transactions, is difficult. Database joins become more complex. Requires sophisticated mechanisms.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Network Latency & Overhead:<\/b><span style=\"font-weight: 400;\"> Relies on network communication between nodes, introducing latency.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Higher Initial Setup Costs:<\/b><span style=\"font-weight: 400;\"> Requires multiple servers\/instances, load balancers, and potentially more complex monitoring solutions initially.<\/span><\/li>\n<\/ul>\n<p>Horizontal scaling dominates large-scale applications but requires careful planning and often specialized distributed database architecture.<\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2>What is Vertical Scaling (Scaling Up)?<\/h2>\n<p>Vertical scaling (“scaling up”) increases the capacity of an individual server by enhancing its resources, like upgrading a computer’s CPU, RAM, or storage. The goal is to make the existing machine more powerful to handle increased load without adding more servers.<\/p>\n<h3>How It Works<\/h3>\n<p><span style=\"font-weight: 400;\">Vertical scaling involves upgrading components on the <\/span><i><span style=\"font-weight: 400;\">same machine<\/span><\/i><span style=\"font-weight: 400;\">: CPU, RAM, storage, or network interfaces. In cloud environments, this usually means restarting the virtual machine on a larger instance type with more resources. The principle remains: enhance a <\/span><i><span style=\"font-weight: 400;\">single<\/span><\/i><span style=\"font-weight: 400;\"> node.<\/span><\/p>\n<div style=\"width: 2102px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/static.pingcap.com\/files\/2025\/07\/18031914\/Figure-2.png\" alt=\"Figure 2\" width=\"2092\" height=\"1204\" \/><p class=\"wp-caption-text\">Figure 2. A representation of vertical scaling in a typical SaaS application.<\/p><\/div>\n<h3>Vertical Scaling Advantages<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Simplicity:<\/b><span style=\"font-weight: 400;\"> Often seen as simpler and faster than redesigning for distribution.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Application Transparency:<\/b><span style=\"font-weight: 400;\"> Usually requires few or no application code changes.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Potential Initial Cost-Effectiveness:<\/b><span style=\"font-weight: 400;\"> Upgrading might be cheaper initially than buying multiple new servers.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Lower Communication Latency:<\/b><span style=\"font-weight: 400;\"> Processes communicate faster within a single machine.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Simpler Data Management:<\/b><span style=\"font-weight: 400;\"> Data consistency is easier with data on a single node.<\/span><\/li>\n<\/ul>\n<h3>Vertical Scaling Disadvantages Limitations<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Hardware Ceiling:<\/b><span style=\"font-weight: 400;\"> There’s an absolute maximum capacity for any single server or instance type.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Downtime Required:<\/b><span style=\"font-weight: 400;\"> Upgrades almost always necessitate taking the server offline, which is unacceptable for high-availability applications. This downtime carries <\/span><a href=\"https:\/\/multishoring.com\/blog\/managing-database-slowness-issues\/\">significant business costs<\/a>.<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Single Point of Failure (SPOF):<\/b><span style=\"font-weight: 400;\"> If the single machine fails, the entire system becomes unavailable, increasing risks of data loss and prolonged outages.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Exponentially Increasing Costs:<\/b><span style=\"font-weight: 400;\"> High-end hardware costs increase non-linearly, offering diminishing performance returns. Cloud upgrades can also be inefficient.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Resource Bottlenecks & Amplified Problems:<\/b><span style=\"font-weight: 400;\"> Bottlenecks can shift, and larger hardware might amplify existing application flaws, sometimes leading to <\/span><i><span style=\"font-weight: 400;\">slower<\/span><\/i><span style=\"font-weight: 400;\"> performance despite upgrades.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Limited Elasticity:<\/b><span style=\"font-weight: 400;\"> Scaling down often requires disruptive downtime, making it inflexible for fluctuating workloads.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Vertical scaling can work for predictable growth and downtime tolerance but is problematic for large-scale, mission-critical systems due to its inherent limits.<\/span><br \/>\n <div class=\"pillar-cta \" style=\"background-image: url(https:\/\/static.pingcap.com\/files\/2025\/06\/22092103\/1000011430.png)\"> <div class=\"pillar-cta-container\"> <div class=\"content-container\"> <div class=\"title\">Join leading data experts as they explain why teams are replacing vertically scaled systems with distributed SQL.<\/div> <div> <a class=\"button button-white\" href=\"https:\/\/www.pingcap.com\/event\/why-distributed-sqls-moment-is-now\/\">Watch the Webinar<\/a> <\/div> <\/div> <\/div> <\/div><\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2>Scale Up vs. Scale Out: An In-Depth Comparison of Database Scaling Strategies<\/h2>\n<p><span style=\"font-weight: 400;\">Choosing between vertical and horizontal scaling involves trade-offs across key dimensions.<\/span><\/p>\n<h3>Key Comparison Points<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Scalability Limit:<\/b><span style=\"font-weight: 400;\"> Vertical has a hard ceiling; Horizontal is theoretically limitless.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Performance Profile:<\/b><span style=\"font-weight: 400;\"> Vertical boosts single-node power; Horizontal excels at distributed load and concurrency but adds network latency.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Cost Profile:<\/b><span style=\"font-weight: 400;\"> Vertical has lower initial cost but high TCO at scale; Horizontal has higher initial cost but potentially lower TCO long-term.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Complexity:<\/b><span style=\"font-weight: 400;\"> Vertical is simpler initially and to manage; Horizontal is more complex in architecture, implementation, and management.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Reliability\/Availability:<\/b><span style=\"font-weight: 400;\"> Vertical has a SPOF; Horizontal offers high availability and fault tolerance.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Downtime Risk:<\/b><span style=\"font-weight: 400;\"> Vertical requires downtime for upgrades; Horizontal allows scaling\/maintenance with minimal\/zero downtime.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Data Consistency:<\/b><span style=\"font-weight: 400;\"> Vertical is simple; Horizontal is challenging for distributed transactions.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Elasticity:<\/b><span style=\"font-weight: 400;\"> Vertical has low elasticity; Horizontal has high elasticity, ideal for auto-scaling databases.<\/span><\/li>\n<\/ul>\n<h3><b>Summary Table: Comparing Horizontal and\u00a0Vertical\u00a0Scaling<\/b><\/h3>\n<div class=\"table-wrapper\">\n<table>\n<tbody>\n<tr>\n<td><b>Feature<\/b><\/td>\n<td><b>Horizontal Scaling (Scale Out)<\/b><\/td>\n<td><b>Vertical Scaling (Scale Up)<\/b><\/td>\n<\/tr>\n<tr>\n<td><b>Scalability Limit<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Theoretically limitless (add more nodes)<\/span><\/td>\n<td>Hard hardware\/instance ceiling<\/td>\n<\/tr>\n<tr>\n<td><b>Primary Performance<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Distributed load handling, high concurrency, parallel processing<\/span><\/td>\n<td>Increased single-node power (CPU, RAM, I\/O)<\/td>\n<\/tr>\n<tr>\n<td><b>Cost Profile<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Higher initial cost; Potentially lower TCO (commodity hardware, elasticity, reduced downtime)<\/span><\/td>\n<td>Lower initial cost; High TCO at scale (premium hardware, downtime)<\/td>\n<\/tr>\n<tr>\n<td><b>Implementation Complexity<\/b><\/td>\n<td><span style=\"font-weight: 400;\">More complex (requires distributed architecture\/app changes)<\/span><\/td>\n<td>Simpler (upgrade existing system)<\/td>\n<\/tr>\n<tr>\n<td><b>Management Complexity<\/b><\/td>\n<td><span style=\"font-weight: 400;\">More complex (manage cluster, distribution, consistency)<\/span><\/td>\n<td>Simpler (single node)<\/td>\n<\/tr>\n<tr>\n<td><b>Reliability\/Availability<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Higher (Fault tolerant, no SPOF)<\/span><\/td>\n<td>Lower (Single Point of Failure)<\/td>\n<\/tr>\n<tr>\n<td><b>Downtime for Scaling<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Minimal\/Zero (add\/remove nodes, rolling updates)<\/span><\/td>\n<td>Required for upgrades\/changes<\/td>\n<\/tr>\n<tr>\n<td><b>Data Consistency Mgmt<\/b><\/td>\n<td><span style=\"font-weight: 400;\">Complex (across distributed nodes)<\/span><\/td>\n<td>Simple (single node)<\/td>\n<\/tr>\n<tr>\n<td><b>Elasticity<\/b><\/td>\n<td><span style=\"font-weight: 400;\">High (easy scale out\/in, suitable for auto-scaling)<\/span><\/td>\n<td>Low (scaling up\/down often disruptive)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p> <\/p>\n<p><span style=\"font-weight: 400;\">Hybrid approaches exist, combining larger nodes within a horizontal architecture. The best approach depends on workload characteristics and requirements. Vertical scaling may suit predictable growth and downtime tolerance. Horizontal scaling is preferred for unpredictable workloads, high concurrency, <a href=\"https:\/\/www.pingcap.com\/article\/scaling-microservices-efficiently-with-tidb\/\">microservices<\/a>, and high availability needs, often requiring databases designed for distribution.<\/span><\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2>Why Database Scaling Strategies Become Critical: Business Challenges & Technical Pain Points<\/h2>\n<p><span style=\"font-weight: 400;\">The need for database scaling strategies stems from tangible business problems caused by the inability to handle growing demands.<\/span><\/p>\n<h3><b>Common Triggers & Pain Points<\/b><\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Performance Degradation & Latency:<\/b><span style=\"font-weight: 400;\"> Applications slow down, queries take longer, impacting user satisfaction and productivity. Databases not optimized for distributed workloads often struggle under high concurrency.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Increased Downtime & Availability Issues:<\/b><span style=\"font-weight: 400;\"> Overloaded systems crash more often. Vertical scaling’s SPOF and maintenance windows cause unavailability. Downtime means lost revenue and damaged trust. A <\/span><span style=\"font-weight: 400;\"><a href=\"https:\/\/www.pingcap.com\/blog\/why-distributed-sql-databases-elevate-modern-app-dev\/\">distributed SQL database<\/a><\/span><span style=\"font-weight: 400;\"> can mitigate this with built-in fault tolerance and online scaling.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Inability to Handle Growth:<\/b><span style=\"font-weight: 400;\"> Existing architecture cannot keep pace with increasing data, users, or transactions, stifling business expansion and opportunities. A distributed database architecture\u2019s horizontal scalability makes it easier to grow without re-architecting.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>High Operational Costs & Complexity:<\/b><span style=\"font-weight: 400;\"> Vertical scaling leads to expensive high-end hardware. Manual horizontal scaling (sharding) is complex and requires specialized skills. Cloud database scaling costs can escalate without elasticity. This diverts resources from innovation. A distributed database architecture can simplify this with auto-sharding and cloud-native elasticity, helping control infrastructure and ops costs.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Architectural Limitations:<\/b><span style=\"font-weight: 400;\"> Monolithic applications are hard to scale incrementally. Traditional relational databases struggle with horizontal write scaling and distributed consistency. Poor schema design or indexing becomes problematic at scale. A distributed database architecture can support both online transactional processing (OLTP) and online analytical processing (OLAP) workloads.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Resource Bottlenecks:<\/b><span style=\"font-weight: 400;\"> Systems hit limits on CPU, RAM, IOPS, or network bandwidth, causing performance issues. A distributed database architecture\u2019s separation of compute and storage allows for more flexible and efficient resource scaling.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Addressing these pain points is critical, as poor scalability directly impacts revenue, productivity, reputation, and growth. A proactive approach to scaling, anticipating future needs, prevents costly emergency fixes and supports smoother growth.<\/span><\/p>\n<h2>Four Hidden Costs of Database Scaling<\/h2>\n<p><span style=\"font-weight: 400;\">While cloud bills and instance pricing are often the most visible costs of scaling, they\u2019re far from the most expensive. Choosing the wrong scaling path\u2014or delaying the right one\u2014can introduce operational drag, engineering inefficiencies, and lost business opportunities. Here are four hidden costs every team should weigh when planning for growth:<\/span><\/p>\n<h3>1. Downtime and Disruption<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">Outages caused by vertical scaling limits or brittle sharding schemes don\u2019t just hurt uptime SLAs. They damage user trust, derail internal roadmaps, and divert resources to firefighting.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Example:<\/b><span style=\"font-weight: 400;\"> Schema changes on monolithic databases often require maintenance windows or cause lock contention, creating unacceptable service disruption at scale.<\/span><\/li>\n<\/ul>\n<h3>2. Engineering Time and Context Switching<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">Maintaining and working around systems that weren\u2019t designed to scale horizontally drains developer productivity. Manual sharding, custom routing logic, and hand-stitched failover mechanisms all represent time engineers could spend building features\u2014not fighting infrastructure.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Opportunity cost:<\/b><span style=\"font-weight: 400;\"> Every hour spent on scaling workarounds is an hour not spent shipping differentiated product value.<\/span><\/li>\n<\/ul>\n<h3>3. Operational Complexity and Tooling Overhead<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">Workarounds for scaling limitations often lead to fragmented infrastructure\u2014multiple databases, duplicated monitoring stacks, and brittle deployment pipelines. This increases the surface area for bugs and makes it harder to enforce consistency, observability, and compliance.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Result:<\/b><span style=\"font-weight: 400;\"> Ops teams struggle to manage and monitor a growing patchwork of systems, increasing the risk of human error and prolonged incidents.<\/span><\/li>\n<\/ul>\n<h3>4. Business Agility and Opportunity Cost<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">The real cost of not scaling effectively? Missed market opportunities. Whether it\u2019s delaying an international launch, avoiding a high-growth customer segment, or failing to capitalize on real-time analytics, slow scaling can limit your business model.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Strategic impact:<\/b><span style=\"font-weight: 400;\"> Scaling should be an enabler of growth\u2014not a blocker.<\/span><\/li>\n<\/ul>\n<h2>Introducing TiDB: A Distributed SQL Solution That Solves Horizontal Scaling Challenges<\/h2>\n<p><span style=\"font-weight: 400;\">Traditional scaling limitations necessitate modern, inherently scalable solutions like TiDB.<\/span><\/p>\n<h3><b>What is TiDB?<\/b><\/h3>\n<p><a href=\"https:\/\/github.com\/pingcap\/tidb\">TiDB<\/a><span style=\"font-weight: 400;\"> is an open-source, distributed SQL database designed for horizontal scalability, strong consistency (ACID compliance via Raft), and high availability (automatic failover). It aims to combine the strengths of relational databases with NoSQL scalability.<\/span><\/p>\n<h3><b>Key Differentiators<\/b><\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Horizontal Scalability by Design:<\/b><span style=\"font-weight: 400;\"> Separates compute and storage, enabling independent, elastic scaling by adding nodes.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>MySQL Compatibility:<\/b><span style=\"font-weight: 400;\"> Speaks the MySQL protocol, simplifying migration from MySQL-based applications, often requiring minimal code changes.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Mixed Workload Processing:<\/b><span style=\"font-weight: 400;\"> Integrates row-based and columnar-based storage. Real-time data replication allows analytics on fresh data without impacting OLTP <a href=\"https:\/\/www.pingcap.com\/article\/mastering-tidb-performance-tuning-a-comprehensive-guide\/\">database performance<\/a> or needing separate ETL pipelines. This simplifies architecture and reduces costs.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Cloud-Native Architecture:<\/b><span style=\"font-weight: 400;\"> Runs effectively on public\/private clouds and Kubernetes. <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb-in-kubernetes\/stable\/tidb-operator-overview\/\">TiDB Operator<\/a><span style=\"font-weight: 400;\"> automates Kubernetes management, and TiDB Cloud offers a fully managed DBaaS.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>AI-Ready Platform<\/b><span style=\"font-weight: 400;\">: TiDB serves as a <\/span><a href=\"https:\/\/www.pingcap.com\/ai\/\">unified data platform for AI workloads<\/a><span style=\"font-weight: 400;\">, combining transactional data, analytical insights, vector search capabilities, and knowledge graph integration. This makes it ideal for building intelligent applications that require real-time context, flexible data models, and low-latency search.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">TiDB provides SQL familiarity and strong consistency with massive horizontal scalability, automating the complexities of distributed data management.<\/span><br \/>\n <div class=\"pillar-cta \" style=\"background-image: url(https:\/\/static.pingcap.com\/files\/2025\/06\/22184957\/1000011432.png)\"> <div class=\"pillar-cta-container\"> <div class=\"content-container\"> <div class=\"title\">Experience horizontal scaling, mixed workload processing, and MySQL compatibility with zero infrastructure setup.<\/div> <div> <a class=\"button button-white\" href=\"https:\/\/tidbcloud.com\/free-trial\/\">Try TiDB for Free<\/a> <\/div> <\/div> <\/div> <\/div><\/p>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2>The SQL Horizontal Scaling Challenge<\/h2>\n<p><span style=\"font-weight: 400;\">For decades, horizontal scaling was considered the domain of NoSQL databases, while traditional SQL systems remained largely confined to single-node vertical scaling. This belief stemmed from the architectural complexity involved in preserving strong consistency, ACID compliance, and SQL semantics in distributed environments. As a result, many teams assumed they had to choose between scale and structure\u2014either give up SQL\u2019s expressive power or forgo elastic scale-out.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">But data-intensive application demands have outgrown that trade-off.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">From real-time financial transactions to large-scale SaaS workloads, today\u2019s systems need both: the rigor of relational models and the elasticity of horizontal scaling. TiDB is purpose-built to meet that challenge. As a distributed SQL database, TiDB retains full MySQL compatibility while delivering native horizontal scalability, automatic data sharding, and strong consistency powered by the Raft consensus algorithm.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The result? You get the familiar power of SQL\u2014joins, transactions, indexes\u2014without the bottlenecks of monolithic infrastructure. TiDB makes horizontal scaling a reality for SQL workloads, empowering teams to scale predictably, simplify operations, and meet the performance demands of modern data-intensive systems.<br \/>\n<\/span><\/p>\n<h2>How TiDB Excels at Horizontal Scaling: A Distributed Database Architecture Deep Dive<\/h2>\n<p><span style=\"font-weight: 400;\">TiDB’s horizontal scalability stems from its distributed architecture, separating compute and storage layers for independent scaling.<\/span><\/p>\n<h3>Distributed SQL Architecture Overview<\/h3>\n<p><span style=\"font-weight: 400;\">The cornerstone of TiDB’s scalability is the clear separation of its computing and storage layers. This allows each layer to be scaled independently based on specific workload demands, providing flexibility and optimizing resource utilization. This contrasts sharply with traditional databases where compute, storage, and transaction management are tightly integrated within a single system, often leading to bottlenecks and scaling limitations.<\/span><\/p>\n<p><img decoding=\"async\" src=\"https:\/\/static.pingcap.com\/files\/2025\/07\/18034426\/Figure-3-1.png\" alt=\"Figure 3\" \/><\/p>\n<h3>Core Components<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">The TiDB cluster comprises several key components working in concert:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tidb-architecture\/#tidb-server\">Compute Layer<\/a><b>:<\/b><span style=\"font-weight: 400;\"> This layer acts as the stateless SQL interface to the cluster. It receives SQL queries from applications (using the MySQL protocol), parses them, performs query optimization (leveraging statistics from the storage layer), and generates distributed execution plans. Because TiDB\u2019s compute layer is stateless (it doesn’t store persistent user data), this layer can be easily scaled horizontally by adding or removing instances behind a load balancer (like <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tiproxy-overview\/\">TiProxy<\/a><span style=\"font-weight: 400;\">, LVS, HAProxy) to match query processing demand. This elasticity is crucial for handling variable query loads without impacting the underlying storage or requiring complex data migrations, embodying the core principles of <a href=\"https:\/\/www.pingcap.com\/blog\/tidb-auto-scaling-distributed-sql-cloud-native-apps\/\">auto-scaling databases<\/a>.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tidb-architecture\/#storage-servers\">Row Store<\/a><b>:<\/b><span style=\"font-weight: 400;\"> This is the core distributed, transactional key-value storage engine where the actual data resides. Data is automatically partitioned into manageable chunks called “Regions,” typically based on key ranges. Each Region is replicated (usually 3 times by default) across different row store nodes using the Raft consensus protocol for consistency and high availability. The row store layer is horizontally scalable; adding more row store nodes increases both the total storage capacity and the aggregate I\/O throughput of the cluster. Row store uses RocksDB as its underlying storage engine on each node.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tidb-architecture\/#placement-driver-pd-server\">Metadata Cluster Orchestrator<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Often described as the “brain” of the TiDB cluster, this orchestrator manages crucial metadata. It maintains the real-time topology of the cluster, tracks the location of each Region replica on the row store nodes, and allocates globally unique, monotonically increasing timestamps (TSO) for distributed transactions. Critically, this orchestrator actively monitors the state of row store nodes (load, storage usage). It also orchestrates data movement by issuing scheduling commands to split Regions that grow too large, merging small or inactive Regions, and migrating Region replicas between row store nodes. This orchestration ensures even load distribution and handles node additions\/removals or failures. This active orchestration is the key to TiDB’s automated scaling and self-healing capabilities. This orchestrator is deployed as a cluster (typically 3 or 5 nodes) using Raft for its own high availability, and orchestrator followers can handle read requests for Region information to <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tune-region-performance\/\">reduce load on the leader<\/a><span style=\"font-weight: 400;\">.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tiflash-overview\/\">Columnar Store (Optional)<\/a><b>:<\/b><span style=\"font-weight: 400;\"> This component provides a columnar storage replica of row store data, optimized for fast analytical (OLAP) queries. Columnar store nodes act as special Raft learners, receiving real-time updates from the row store Raft groups, ensuring strong data consistency between rows and the columns. Queries involving large scans or aggregations can be intelligently routed by the compute layer to the columnar store for significantly faster execution, enabling true <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/explore-htap\/\">mixed workload processing capabilities<\/a><span style=\"font-weight: 400;\">. The columnar store can also scale horizontally and independently from the row store and compute layer.<\/span><\/li>\n<\/ul>\n<h3>Key Mechanisms Enabling Horizontal Scaling: Auto-Scaling Databases in Practice<\/h3>\n<p><span style=\"font-weight: 400;\">Several core mechanisms underpin TiDB’s horizontal scalability:<\/span><\/p>\n <div> <a class=\"block-columns__video-container js--trigger-video-modal ignore-link-styles\" href=\"https:\/\/www.youtube.com\/watch?v=uYUqKWJDBN0\"> <img class=\"block-columns__video-image\" src=\"https:\/\/static.pingcap.com\/files\/2024\/12\/20002926\/Distributed-SQL-in-60-seconds.jpg\"> <span class=\"play-video-overlay\"> <svg width=\"45\" height=\"45\" viewbox=\"0 0 45 45\" fill=\"none\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" version=\"1.1\" xmlns:xlink=\"http:\/\/www.w3.org\/1999\/xlink\" xml:space=\"preserve\" x=\"0px\" y=\"0px\" class=\"play-video-overlay__play-icon\"><use xlink:href=\"#general-icon-play\"><\/use><\/svg> <\/span> <\/a> <\/div>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Automatic Sharding (Regions):<\/b><span style=\"font-weight: 400;\"> TiDB automatically partitions table data into Regions (defaulting to around 256MB, but configurable) based on key ranges and distributes these Regions across the available row store nodes. As data is inserted or updated, the metadata and cluster orchestrator monitors Region sizes and access patterns. If a Region grows too large or becomes a “hotspot” with excessive traffic, the orchestrator automatically triggers a split operation, creating smaller Regions, and then rebalances these Regions across the cluster. This <\/span><a href=\"https:\/\/www.pingcap.com\/blog\/comparing-vitess-tidb-cross-shard-queries-consistency-az-outages\/#:~:text=With%20TiDB%2C%20database%20sharding%20is,manual%20resharding%20or%20application%20changes.\">dynamic, automatic sharding and rebalancing<\/a><span style=\"font-weight: 400;\"> eliminates the immense complexity and operational burden of manual database sharding required by many traditional systems.<\/span><\/li>\n<li><b>Raft Consensus Protocol:<\/b><span style=\"font-weight: 400;\"> TiDB\u2019s row store uses the <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tidb-best-practices\/#raft\">Raft algorithm<\/a><span style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"> to replicate each Region’s data across multiple nodes (typically 3). Raft ensures that writes are only acknowledged after being persisted on a majority of replicas, guaranteeing strong consistency (no data loss) even if a minority of replicas fail. Raft also handles automatic leader election within each Region’s replica group. If the leader node becomes unavailable, a follower is quickly elected to take over, ensuring high availability and enabling automatic failover with minimal disruption.<\/span><\/span>\n<p><div style=\"width: 2102px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/static.pingcap.com\/files\/2025\/07\/18022915\/Figure-4.png\" alt=\"Figure 4\" width=\"2092\" height=\"860\" \/><p class=\"wp-caption-text\">Figure 4. A diagram depicting how Raft consensus works in TiDB.<\/p><\/div><\/li>\n<li><b>Automatic Load Balancing:<\/b> The metadata and cluster orchestrator continuously monitors the load (CPU, storage usage, read\/write traffic) on each row store node and proactively migrates Region replicas between nodes to maintain a balanced distribution. This prevents individual nodes from becoming performance bottlenecks and ensures efficient utilization of cluster resources, especially as nodes are added or removed. Load balancing can also occur at the compute layer via proxies like TiProxy. This mechanism directly supports the concept of auto-scaling databases.<\/li>\n<li><b>Distributed Transactions:<\/b> TiDB supports ACID-compliant distributed transactions that can span multiple Regions and nodes. It employs an optimized two-phase commit (2PC) protocol, often leveraging Percolator’s model with PD-managed timestamps, to ensure atomicity and consistency across the distributed system. This complex coordination is handled transparently by the database, simplifying application development.\n<p><div style=\"width: 2102px\" class=\"wp-caption alignnone\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/static.pingcap.com\/files\/2025\/07\/18022912\/Figure-5.png\" alt=\"Figure 5\" width=\"2092\" height=\"1096\" \/><p class=\"wp-caption-text\">Figure 5. A diagram depicting how distributed transactions work in TiDB.<\/p><\/div><\/li>\n<\/ul>\n<h3>Addressing Scaling Limitations<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">Through this distributed database architecture, TiDB directly addresses the core limitations of traditional database scaling strategies:<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Overcomes Vertical Limits:<\/b><span style=\"font-weight: 400;\"> Horizontal scaling by adding compute layer, row store, or columnar store nodes provides a path to virtually limitless scale for compute, storage, and analytical capacity, making it a true scale out solution.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Eliminates Single Points of Failure:<\/b><span style=\"font-weight: 400;\"> The distributed nature, combined with Raft replication and <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb-in-kubernetes\/stable\/use-auto-failover\/\">automated failover mechanisms<\/a><span style=\"font-weight: 400;\"> orchestrated by the metadata and cluster orchestrator, ensures high availability and resilience to failures.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Simplifies Horizontal Complexity:<\/b><span style=\"font-weight: 400;\"> By automating sharding (Regions), load balancing, consistency management (Raft, distributed transactions), and failover, TiDB significantly reduces the operational burden and application-level complexity associated with manual horizontal scaling strategies.<\/span><\/li>\n<\/ul>\n<p>In essence, TiDB uses intelligent automation (primarily via the metadata and cluster orchestrator) and proven distributed systems principles (like Raft) to deliver the benefits of horizontal scaling without imposing the traditional complexities onto the user.<\/p>\n<h2>Real-World Database Scaling Strategies<\/h2>\n<p><span style=\"font-weight: 400;\">Not every system needs to scale the same way. Your database scaling strategies should match your product maturity, user base, and infrastructure goals. Below are three typical growth stages and how vertical vs. horizontal scaling fits into each.<\/span><\/p>\n<h3>Startup (0\u20131M Users): When Vertical Scaling Makes Sense<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">In the early stages, simplicity matters. You\u2019re optimizing for speed of development, low operational overhead, and getting to product-market fit\u2014not building for hyperscale. Vertical scaling (i.e., upgrading to a larger instance) often provides a faster, cheaper path to support modest workloads without the complexity of distributed database architecture.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>When to use it:<\/b> <span style=\"font-weight: 400;\">You\u2019re running a monolithic application, working with relatively small datasets, and need to iterate quickly.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>What to watch for:<\/b><span style=\"font-weight: 400;\"> As traffic grows, latency spikes, and write throughput or memory constraints may emerge\u2014signaling it\u2019s time to reevaluate your database scaling strategies.<\/span><\/li>\n<\/ul>\n<h3>Growth Stage (1M\u201310M Users): Transitioning to Scale Out<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">As usage climbs, the limitations of vertical scaling begin to surface. You may find yourself upgrading hardware frequently or dealing with service interruptions during maintenance. It\u2019s at this point that architectural debt compounds, and retrofitting horizontal scalability becomes harder the longer you delay.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>What to consider:<\/b><span style=\"font-weight: 400;\"> If you\u2019re experiencing regular downtime during schema changes, slow failover, or region-specific latency, you\u2019re likely hitting the boundaries of a vertically scaled system.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Best practice:<\/b> <span style=\"font-weight: 400;\">Begin evaluating distributed SQL options that maintain SQL semantics but allow for future elastic growth, like TiDB.<\/span><\/li>\n<\/ul>\n<h3>Enterprise (10M+ Users): When Horizontal Scaling Becomes Essential<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">At scale, availability, elasticity, and global performance are no longer nice-to-haves\u2014they\u2019re mandatory. Vertical scaling maxes out fast, and infrastructure that can\u2019t scale out forces brittle workarounds like manual sharding. This increases operational complexity and slows innovation.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>What\u2019s needed:<\/b><span style=\"font-weight: 400;\"> A system that can grow with your business, automatically rebalance load, isolate workloads, and scale reads\/writes across multiple regions or AZs. This is where auto-scaling databases become invaluable.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>How TiDB helps:<\/b><span style=\"font-weight: 400;\"> TiDB provides built-in horizontal scalability, strong consistency, and MySQL compatibility\u2014eliminating the need for custom sharding logic while future-proofing your stack. Its distributed database architecture is designed to handle these demands effortlessly.<\/span><\/li>\n<\/ul>\n<h2>TiDB in Action: Real-World Use Cases and Success Stories<\/h2>\n<p><span style=\"font-weight: 400;\">TiDB delivers tangible benefits across demanding industries facing scaling challenges.<\/span><\/p>\n<h3>Target Industries & Scenarios<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/solutions\/saas\/\">SaaS High-Growth Tech<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Provides elastic scalability, high availability, and simplified operations compared to manual sharding. MySQL compatibility aids migration.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/solutions\/fintech\/\">Financial Services Fintech<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Meets high demands for consistency, reliability, and availability for payments and core systems. Offers financial-grade high availability, ACID compliance, and horizontal scaling. Mixed workload processing aids real-time fraud detection. Plaid migrated from Aurora due to write bottlenecks, seeking a more robust distributed database architecture.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/solutions\/e-commerce\/\">E-commerce<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Handles massive concurrent traffic, especially during peaks, with horizontal scaling and strong consistency for orders\/inventory. Mixed workload processing enables real-time analytics.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/customers\/?industry=gaming\">Gaming<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Manages unpredictable loads, low latency needs, and vast player data. Horizontal scaling handles player surges; low latency ensures smooth gameplay; consistency protects player progress. Mixed workload processing allows real-time behavior analysis.<\/span><\/li>\n<\/ul>\n<h3><b>Quantifiable Benefits Across Use Cases<\/b><\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/video\/user-story-how-pinterest-modernized-its-nosql-data-infrastructure\/\">Cost Savings (30-80%+)<\/a><b>:<\/b> <span style=\"font-weight: 400;\">Pinterest Senior Engineering Manager Lianghong Xu commented: <\/span><span style=\"font-weight: 400;\">\u201cWith HBase, we had multiple instances, and the maintenance overhead was very high. For TiDB, we\u2019ve been operating it for over two years now, and we haven\u2019t experienced any major production issues.\u201d\u00a0This highlights the long-term TCO benefits of a well-implemented distributed database architecture.\u00a0<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/case-study\/catalyst-rearchitects-core-saas-platform-tidb-60x-faster-performance\/\">Performance Improvements (up to 60x-1000x)<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Former Catalyst CTO Sha Ma said her company chose TiDB because: \u201cWe have a very diverse set of customers, so our data is more or less schemaless. We actually have wide tables with dynamic DDL formats that we\u2019re storing \u2014\u00a0and we need that transactional level of performance to power our application. TiDB outshines all of the other database technologies we looked at in terms of performance and costs.\u201d<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/video\/why-plaid-migrated-from-managed-mysql-to-tidb\/\">Operational Efficiency<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Plaid <\/span><span style=\"font-weight: 400;\">Experienced Database Reliability Engineer Zander Hill noted: <\/span><span style=\"font-weight: 400;\">\u201cWe ended up going with TiDB for a few specific characteristics. <\/span><span style=\"font-weight: 400;\">One was around being able to do upgrades with zero downtime. That\u2019s not something we were able to previously achieve on our former hosted MySQL solution.\u201d\u00a0<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/www.pingcap.com\/case-study\/bolt-modernizing-mysql-tidb-scale-thousands-microservices-aws\/\">Scalability Demonstrated<\/a><b>:<\/b><span style=\"font-weight: 400;\"> According to Bolt Director of Engineering <\/span><span style=\"font-weight: 400;\">\u0141ukasz Gr\u0105dzki:<\/span><span style=\"font-weight: 400;\"> \u201cTiDB scales much more seamlessly than our previous MySQL database<\/span><span style=\"font-weight: 400;\">. It requires much less effort from our engineers to scale up or scale down our clusters, depending on how the business goes. As it scales very well horizontally, it also gives us more time to redesign and improve our overall architecture.\u201d\u00a0<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">These successes show TiDB delivers scalability, performance, availability, and operational simplicity, making it compelling for organizations outgrowing traditional databases.<\/span><\/p>\n <div class=\"pillar-cta medium\" style=\"background-image: url(https:\/\/static.pingcap.com\/files\/2025\/06\/22201025\/1000011436.png)\"> <div class=\"pillar-cta-container\"> <div class=\"image-container\"> <img alt=\"Pillar Page-Horizontal Scaling\" src=\"https:\/\/static.pingcap.com\/files\/2025\/06\/29200118\/customers.png\" \/> <\/div> <div class=\"content-container\"> <div class=\"title\">See how companies across SaaS, FinTech, and E-commerce scale effortlessly with TiDB.<\/div> <div> <a class=\"button button-white\" href=\"https:\/\/www.pingcap.com\/customers\/\">View Case Studies<\/a> <\/div> <\/div> <\/div> <\/div>\n","accordion_column_title":"","accordion_sections":false,"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"wysiwyg","wysiwyg":"<h2>Implementing and Managing Scalable Solutions: Cloud Database Scaling with TiDB<\/h2>\n<p><span style=\"font-weight: 400;\">Adopting TiDB involves practical considerations like implementation, management, and TCO.<\/span><\/p>\n<h3>Implementation Effort Comparison<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Vertical Scaling:<\/b><span style=\"font-weight: 400;\"> Simpler initially (hardware\/instance upgrade), main challenge is downtime.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Manual Horizontal Scaling:<\/b><span style=\"font-weight: 400;\"> Highly complex (app redesign, custom sharding logic, consistency management).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Adopting TiDB:<\/b><span style=\"font-weight: 400;\"> Shifts complexity to deploying\/configuring the cluster. TiDB automates sharding, balancing, and consistency. Effort involves understanding architecture, choosing deployment, and migrating data (eased by MySQL compatibility). This streamlined approach is a key benefit of a well-designed distributed database architecture.<\/span><\/li>\n<\/ul>\n<h3>TiDB Deployment Options<\/h3>\n<ol>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/overview\/\">TiDB Self-Managed<\/a><b>:<\/b><span style=\"font-weight: 400;\"> Deploy on your own infrastructure (on-prem\/cloud VMs).<\/span><span style=\"font-weight: 400;\"> Maximum control, full operational responsibility.<\/span>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><em><span style=\"font-weight: 400;\">Using <\/span><a href=\"https:\/\/docs.pingcap.com\/tidb\/stable\/tiup-overview\/\">TiUP<\/a><span style=\"font-weight: 400;\">:<\/span><\/em><span style=\"font-weight: 400;\"> Command-line tool simplifying deployment, scaling, upgrades for self-managed clusters.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><em><a href=\"https:\/\/docs.pingcap.com\/tidb-in-kubernetes\/stable\/get-started\/\">Using TiDB Operator on Kubernetes<\/a><span style=\"font-weight: 400;\">:<\/span><\/em><span style=\"font-weight: 400;\"> Recommended for containerized environments (EKS, GKE, AKS, etc.).<\/span><span style=\"font-weight: 400;\"> Automates full lifecycle management (deployment, scaling, upgrades, backup, failover) via Kubernetes CRDs and controllers.<\/span><span style=\"font-weight: 400;\"> Reduces operational friction for Kubernetes users.<\/span><\/li>\n<\/ul>\n<\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>TiDB Cloud (DBaaS):<\/b><span style=\"font-weight: 400;\"> A fully-managed service offered by PingCAP, the company behind TiDB (handles infrastructure, admin, maintenance, and availability). Reduces user operational overhead. Available on AWS, GCP, and Azure.<\/span>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><em><a href=\"https:\/\/www.pingcap.com\/tidb-cloud-dedicated\/\">TiDB Cloud Dedicated<\/a><span style=\"font-weight: 400;\">:<\/span><\/em><span style=\"font-weight: 400;\"> Reserved resources for predictable workloads. Node-based pricing. Suitable for production; offers compliance certifications.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><em><a href=\"https:\/\/www.pingcap.com\/tidb-cloud-starter\/\">TiDB Cloud Starter<\/a><span style=\"font-weight: 400;\">:<\/span><\/em><span style=\"font-weight: 400;\"> Usage-based pricing (Request Units + storage). Auto-scales compute\/storage, scales to zero when idle. Cost-effective for variable workloads, dev\/test. Includes a free tier.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h3>Management Overhead & Operations<\/h3>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Vertical Scaling:<\/b><span style=\"font-weight: 400;\"> Simple single-node management, but upgrade disruption remains.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Manual Horizontal Scaling:<\/b><span style=\"font-weight: 400;\"> Highest overhead (manual node\/load balancing\/data management).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>TiDB Self-Managed:<\/b><span style=\"font-weight: 400;\"> Reduced overhead vs. manual sharding via TiUP and TiDB Operator. Users still manage infrastructure, Kubernetes (if used), monitoring, and tuning. Requires distributed systems expertise.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>TiDB Cloud:<\/b><span style=\"font-weight: 400;\"> Lowest overhead. PingCAP manages infrastructure and DB admin tasks. Users can focus on application development.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The choice between TiDB Self-Managed and TiDB Cloud balances control vs. operational cost\/complexity.<\/span><\/p>\n<h3>Total Cost of Ownership (TCO)<\/h3>\n<p style=\"font-weight: 400; margin-bottom: 1.5rem;\">TCO includes infrastructure, software, labor, and downtime costs.<\/p>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>Vertical Scaling TCO:<\/b><span style=\"font-weight: 400;\"> Can be very high due to expensive hardware, potential license fees, and downtime impact.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"1\"><b>TiDB TCO:<\/b><span style=\"font-weight: 400;\"> Aims for lower TCO.<\/span>\n<ul>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><i><span style=\"font-weight: 400;\">TiDB Self-Managed:<\/span><\/i><span style=\"font-weight: 400;\"> Benefits from commodity hardware\/instances and open-source license. Costs driven by infrastructure and internal operations (reduced by automation).<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><i><span style=\"font-weight: 400;\">TiDB Cloud Dedicated:<\/span><\/i><span style=\"font-weight: 400;\"> Predictable node-based pricing. Compare vs. RDS\/Aurora considering specs, storage, data transfer, and I\/O costs. Often better price-performance for write-intensive, mixed workload processing.<\/span><\/li>\n<li style=\"font-weight: 400;\" aria-level=\"2\"><i><span style=\"font-weight: 400;\">TiDB Cloud Starter:<\/span><\/i><span style=\"font-weight: 400;\"> Pay-for-use model can drastically cut TCO for variable workloads vs. provisioned models. Scale-to-zero eliminates idle costs. Case studies show <\/span><a href=\"https:\/\/www.pingcap.com\/tidb-cloud-serverless-vs-amazon-rds\/\">significant savings (30-80%) vs. Aurora\/RDS<\/a><span style=\"font-weight: 400;\">.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">When comparing TCO, consider reduced engineering effort (vs. workarounds), consolidated mixed workloads, and managed service savings.<\/span><\/p>\n<h2>Choosing the Right Path for Scalable Growth: Database Scaling Strategies with TiDB<\/h2>\n<p><span style=\"font-weight: 400;\">The choice between vertical and horizontal scaling involves a trade-off between initial simplicity and long-term capability. Vertical scaling is straightforward but hits hard limits, requires downtime, creates single points of failure, and becomes costly. Horizontal scaling offers limitless potential and high availability but traditionally involves significant complexity.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">TiDB bridges this gap, providing the benefits of horizontal scaling (scale up vs. scale out elasticity, fault tolerance, performance) while mitigating complexity through its intelligent distributed database architecture and automation (automatic sharding, load balancing, Raft consensus). Its MySQL compatibility eases adoption, and its mixed workload processing capability simplifies architecture and enables real-time insights.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Choosing a scalable, cloud-native solution like TiDB is a strategic investment in future-proofing data infrastructure, avoiding the limitations of vertical scaling and the burdens of manual horizontal scaling. Its proven success across demanding industries makes it a compelling option for any organization implementing Cloud database scaling or leveraging Auto-scaling databases for data-intensive applications.<\/span><\/p>\n <div class=\"pillar-cta \" style=\"background-image: url(https:\/\/static.pingcap.com\/files\/2025\/06\/22211020\/1000011435.png)\"> <div class=\"pillar-cta-container\"> <div class=\"content-container\"> <div class=\"title\">To evaluate TiDB, sign up for a free trial to enjoy a hands-on, managed experience \u2014 and build a resilient, high-performing foundation for rapid data growth.<\/div> <div> <a class=\"button button-white\" href=\"https:\/\/tidbcloud.com\/free-trial\/\">Try Now<\/a> <\/div> <\/div> <\/div> <\/div>\n","accordion_column_title":"FAQ","accordion_sections":[{"section_title":"Can I combine horizontal and vertical scaling?","section_content":"<p>Yes, many modern systems use a combination of horizontal and vertical scaling. Typically, businesses start by vertically scaling servers until reaching cost or performance limits, then move to horizontal scaling to handle additional growth efficiently. Combining both strategies offers flexibility and optimizes resource usage based on workload needs.<\/p>\n"},{"section_title":"What are the main disadvantages of vertical scaling?","section_content":"<p>Vertical scaling has physical and financial limits. High-end servers become increasingly expensive, and downtime is often required for upgrades. Additionally, a single point of failure risk remains, meaning if one powerful machine goes down, the entire system may be impacted.<\/p>\n"},{"section_title":"Why is horizontal scaling better for cloud-native applications?","section_content":"<p>Horizontal scaling is ideal for cloud-native applications because it allows organizations to add or remove resources dynamically based on demand. This approach improves availability, resilience, and cost-efficiency, especially when serving global user bases or handling unpredictable traffic patterns.<\/p>\n"},{"section_title":"Is TiDB a horizontally scalable database?","section_content":"<p>Yes, TiDB is built specifically for horizontal scalability. It enables businesses to add more nodes easily without service interruption, ensuring high availability, strong consistency, and seamless performance even as workloads grow.<\/p>\n"},{"section_title":"How do I know if my application needs horizontal scaling?","section_content":"<p>If your application is experiencing frequent slowdowns during traffic spikes, requires global accessibility, or faces hardware limitations with vertical upgrades, it\u2019s a strong sign that you need horizontal scaling to ensure future growth and stability.<\/p>\n"}],"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top","block-options-padding-remove-bottom"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false},{"acf_fc_layout":"columns","format":"","enable_box_container":false,"column_num":"12","columns":[{"type":"accordion","wysiwyg":"","accordion_column_title":"FAQ","accordion_sections":[{"section_title":"Can I combine horizontal and vertical scaling?","section_content":"<p>Yes, many modern systems use a combination of horizontal and vertical scaling. Typically, businesses start by <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#what-is-vertical-scaling-scaling-up\">vertically scaling<\/a> servers until reaching cost or performance limits, then move to <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#what-is-horizontal-scaling-scaling-out\">horizontal scaling<\/a> to handle additional growth efficiently. Combining both database scaling strategies offers flexibility and optimizes resource usage based on workload needs.<\/p>\n"},{"section_title":"What are the main disadvantages of vertical scaling?","section_content":"<p>Vertical scaling has physical and financial limits. High-end servers become increasingly expensive, and downtime is often required for upgrades. Additionally, a single point of failure risk remains, meaning if one powerful machine goes down, the entire system may be impacted.<\/p>\n"},{"section_title":"Why is horizontal scaling better for cloud-native applications?","section_content":"<p>Horizontal scaling is ideal for cloud-native applications because it allows organizations to add or remove resources dynamically based on demand. This approach improves <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#horizontal-scaling-advantages\">availability, resilience, and cost-efficiency<\/a>, especially when serving global user bases or handling unpredictable traffic patterns. This is precisely what cloud database scaling aims to achieve.<\/p>\n"},{"section_title":"Is TiDB a horizontally scalable database?","section_content":"<p>Yes, TiDB is <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#how-tidb-excels-at-horizontal-scaling-a-distributed-database-architecture-deep-dive\">built specifically for horizontal scalability<\/a>. Its distributed database architecture enables businesses to add more nodes easily without service interruption, ensuring high availability, strong consistency, and seamless performance even as workloads grow. This makes it a leading solution for scale up vs. scale out requirements.<\/p>\n"},{"section_title":"How do I know if my application needs horizontal scaling?","section_content":"<p>If your application is experiencing frequent slowdowns during traffic spikes, requires global accessibility, or faces hardware limitations with vertical upgrades, it\u2019s a strong sign that you need horizontal scaling to ensure future growth and stability. These are common indicators that your current database scaling strategies are insufficient.<\/p>\n"},{"section_title":"What are the main disadvantages of horizontal scaling?","section_content":"<p>Horizontal scaling introduces <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#horizontal-scaling-disadvantages-limitations\">complexity in system management, requires specialized distributed database architecture expertise, and can face data consistency challenges across multiple nodes<\/a>. Initial setup costs are typically higher, and network latency between nodes can impact performance. However, modern distributed databases like TiDB address many of these challenges through automated management and built-in consistency mechanisms.<\/p>\n"},{"section_title":"Is vertical scaling more expensive than horizontal scaling?","section_content":"<p>Vertical scaling often has lower initial costs but becomes exponentially more expensive as you reach high-end hardware limits. Horizontal scaling requires higher upfront investment but offers better long-term cost efficiency through commodity hardware usage and linear cost scaling. The <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#total-cost-of-ownership-tco\">total cost of ownership (TCO)<\/a> typically favors horizontal scaling for growing applications. This is a core consideration in database scaling strategies.<\/p>\n"},{"section_title":"Why can't traditional SQL databases scale horizontally?","section_content":"<p>Traditional SQL databases <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#the-sql-horizontal-scaling-challenge\">struggle with horizontal scaling<\/a> due to ACID compliance requirements, complex join operations across distributed data, and monolithic architecture designed for single-node operation. These databases rely on strong consistency models that are difficult to maintain across multiple nodes. Modern distributed SQL databases like TiDB solve this by redesigning the architecture specifically for horizontal scaling while maintaining SQL compatibility and ACID guarantees.<\/p>\n"},{"section_title":"When should I choose vertical scaling over horizontal scaling?","section_content":"<p><a href=\"\/horizontal-scaling-vs-vertical-scaling\/#scale-up-vs-scale-out-an-in-depth-comparison-of-database-scaling-strategies\">Choose vertical scaling<\/a> when you have predictable, moderate growth patterns, simple applications that can tolerate brief downtime, limited distributed systems expertise, or when your current hardware is significantly underutilized. It’s also suitable for applications with tight data consistency requirements that are difficult to distribute.<\/p>\n"},{"section_title":"What's the difference between scaling up and scaling out?","section_content":"<p><a href=\"\/horizontal-scaling-vs-vertical-scaling\/#what-is-vertical-scaling-scaling-up\">“Scaling up” (vertical scaling)<\/a> means adding more power to existing machines – more CPU, RAM, or storage. <a href=\"\/horizontal-scaling-vs-vertical-scaling\/#what-is-horizontal-scaling-scaling-out\">“Scaling out” (horizontal scaling)<\/a> means adding more machines to your resource pool. Scaling up is like upgrading your car’s engine, while scaling out is like adding more cars to your fleet.<\/p>\n"},{"section_title":"How does auto-scaling work with horizontal scaling?","section_content":"<p><a href=\"\/horizontal-scaling-vs-vertical-scaling\/#key-mechanisms-enabling-horizontal-scaling-auto-scaling-databases-in-practice\">Auto-scaling with horizontal scaling<\/a> automatically adds or removes server instances based on demand metrics like CPU usage, memory consumption, or request volume. Cloud platforms and distributed databases like TiDB can automatically provision new nodes during traffic spikes and scale down during low-demand periods, optimizing both performance and costs.<\/p>\n"}],"video_image":false,"video_url":"","video_content":""}],"block_background":"block-bg-none","block_background_video_type":"url","block_background_video_url":"","block_background_video_file":false,"block_background_image":false,"block_background_overlay":false,"unique_id":"","block_option_custom_class":"","block_option_padding":["block-options-padding-remove-top"],"block_option_hide":[],"block_add_top_arc":false,"block_increase_bottom_padding":false}],"_links":{"self":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages\/24043","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/users\/184"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/comments?post=24043"}],"version-history":[{"count":4,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages\/24043\/revisions"}],"predecessor-version":[{"id":28963,"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/pages\/24043\/revisions\/28963"}],"wp:attachment":[{"href":"https:\/\/www.pingcap.com\/ko\/wp-json\/wp\/v2\/media?parent=24043"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}