{"id":74790,"date":"2026-08-06T10:45:00","date_gmt":"2026-08-06T16:45:00","guid":{"rendered":"https:\/\/www.scalahosting.com\/blog\/?p=74790"},"modified":"2026-08-05T03:36:06","modified_gmt":"2026-08-05T09:36:06","slug":"one-server-vs-cluster","status":"publish","type":"post","link":"https:\/\/www.scalahosting.com\/blog\/one-server-vs-cluster\/","title":{"rendered":"One Server vs. Cluster: When Should Your Business Scale Out?"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Move from one server to a cluster when an hour of downtime costs more than the extra nodes, or when a single machine can no longer keep up on its busiest day.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That&#8217;s the entire decision. Most sites never reach it &#8211; one well-backed-up machine handles the majority of workloads without complaint. But when a kernel panic at 2 a.m. means lost orders rather than an awkward morning, the arithmetic changes.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A cluster spreads your sites across several servers that share one storage volume, so the site keeps serving when one of them fails. With <a href=\"https:\/\/www.scalahosting.com\/cluster-hosting.html\"><strong>Managed Cluster Hosting<\/strong><\/a>, our team designs and provisions the topology your workload needs, and <a href=\"https:\/\/www.scalahosting.com\/spanel.html\"><strong>SPanel<\/strong><\/a> gives you live status and health across every node.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Three things worth knowing before the detail:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>One server is the right default for most sites. <\/strong>Scale out for availability or capacity, never for prestige.<\/li>\n\n\n\n<li><strong>A cluster is not a speed upgrade. <\/strong>It changes how much traffic you can absorb and what happens when hardware dies &#8211; not how fast a single page renders.<\/li>\n\n\n\n<li><strong>Cluster operations run through our technical team. <\/strong>The panel is where you watch; we handle the changes.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>When One Server Is Still the Right Call<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Stay on a single machine if your site fits comfortably inside it and a short outage wouldn&#8217;t seriously hurt you. A portfolio site, a local service business, a blog, a store handling a few hundred orders a week &#8211; all of these run fine on one <a href=\"https:\/\/www.scalahosting.com\/blog\/top-9-benefits-of-managed-vps-hosting\/\"><strong>managed VPS<\/strong><\/a>, and the money is better spent on developing your business.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The threshold gets easier to see once you <strong>price <\/strong>it.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Industry-standard SLA uptime of 99.9% works out to roughly 8.7 hours of downtime a year. Push to 99.99%, and that drops to about 52 minutes. If 8.7 hours offline during your busiest weeks costs less than the extra infrastructure, you have your answer. If it costs more, you also have your answer.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The second trigger is <strong>capacity<\/strong>.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When load, memory, or disk regularly run near their limits in a normal week &#8211; not just on Black Friday &#8211; you&#8217;re one traffic spike away from a bad afternoon. If the constraint is raw power rather than resilience, note that <strong>moving from a VPS to a cluster hosting plan<\/strong> is sometimes the logical fix.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What a Cluster Actually Fixes<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The most common misconception is that clusters make pages faster.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">They don&#8217;t. A single request still runs on one node, at that node&#8217;s speed. A page that crawls because of unindexed queries or an uncached theme will crawl identically on a second machine. Fix the application first &#8211; a cluster multiplies whatever performance you already have, including the bad kind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">What a cluster does fix:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Single points of failure. <\/strong>Lose a node and the remaining ones keep serving.<\/li>\n\n\n\n<li><strong>Hard ceilings. <\/strong>You add capacity by adding nodes, not by migrating to a bigger box over a tense weekend.<\/li>\n\n\n\n<li><strong>Geography. <\/strong>A multi-datacenter setup places copies of the same environment in different regions, so visitors get served closer to home.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">The other misconception is that scaling out means rebuilding everything by hand. It doesn&#8217;t. Accounts, domains, and system users <strong>stay synchronized across every node automatically<\/strong>, so there&#8217;s no separate copy of each site to maintain.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>How Managed Cluster Hosting Works<\/strong><strong><\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-image size-full mpg-gallery\"><img decoding=\"async\" width=\"1140\" height=\"513\" src=\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2026\/08\/One-Server-vs.-Cluster-When-Should-Your-Business-Scale-Out-how-it-works-1140x513-1.webp\" alt=\"One Server vs. Cluster: When Should Your Business Scale Out?, How Managed Cluster Hosting Works\" class=\"wp-image-74792\" srcset=\"https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2026\/08\/One-Server-vs.-Cluster-When-Should-Your-Business-Scale-Out-how-it-works-1140x513-1.webp 1140w, https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2026\/08\/One-Server-vs.-Cluster-When-Should-Your-Business-Scale-Out-how-it-works-1140x513-1-300x135.webp 300w, https:\/\/www.scalahosting.com\/blog\/wp-content\/uploads\/2026\/08\/One-Server-vs.-Cluster-When-Should-Your-Business-Scale-Out-how-it-works-1140x513-1-768x346.webp 768w\" sizes=\"(max-width: 361px) 660px, (max-width: 767px) 89vw, (max-width: 1000px) 54vw, (max-width: 1071px) 910px, 1140px\" \/><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">A cluster is <strong>several servers acting as one hosting environment<\/strong>. Three technologies do the heavy lifting.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Shared Storage Keeps Files Identical<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">One node is designated as the storage node. It holds all website files and exports them over NFS, and every other node mounts that export as its own \/home. Nothing is copied, and nothing is synced &#8211; there&#8217;s exactly one copy of each file, and every node reads and writes that same copy.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">This setup removes an entire category of bugs. Upload an image on one node, and it&#8217;s instantly visible on all the others, because there was never a second version to fall behind.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mail data, DNS zone files, SSL certificates, and web server virtual host configurations live on the same shared storage. Logs, cron jobs, and the operating system stay local to each machine.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MariaDB Galera Keeps Databases in Sync<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Databases work the opposite way.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Every database-running node keeps its own local MariaDB copy &#8211; routing each query over the network would be too slow &#8211; and Galera replicates writes synchronously. By the time a write is confirmed, it has already landed on every node.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Galera also enforces <strong>quorum<\/strong>: more than half the database nodes must see each other before the cluster accepts writes. That prevents split-brain, where two halves of a partitioned cluster both keep writing and quietly diverge. It&#8217;s also why three nodes, not two, is the smallest practical cluster &#8211; three survives one failure with quorum intact.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>MaxScale Routes Queries to a Healthy Node<\/strong><\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">MaxScale sits between the application and the database nodes. It tracks which nodes are healthy, applies a priority order, and sends each query to the right place: writes to the priority node, reads spread across the rest. If the priority node goes down, MaxScale promotes another one and the application never finds out.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That&#8217;s what lets ordinary applications benefit from a cluster. WordPress has no idea it&#8217;s running on six servers. It connects to one address, and the routing, failover, and load balancing happen underneath it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Node Roles and the Four Cluster Topologies<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Not every node does the same job. Roles range from full-service nodes that run web, database, mail, and DNS, through to ones dedicated to a single function &#8211; a database-only node for query-heavy stores, a mail node added as a backup MX record, or a lightweight DNS node in a separate datacenter.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Those roles combine into four cluster shapes:<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-regular green-rows\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Topology<\/strong><\/th><th><strong>What It Adds<\/strong><\/th><th><strong>Best For<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Full Cluster (All Services)<\/td><td>Every node runs web, database, mail, and DNS<\/td><td>General-purpose workloads with no single bottleneck<\/td><\/tr><tr><td>Dedicated Database Nodes<\/td><td>Separate nodes run MariaDB only, with MaxScale routing queries from the web nodes<\/td><td>Query-heavy stores, SaaS apps, anything analytics-heavy<\/td><\/tr><tr><td>Mail Redundancy (MX)<\/td><td>Dedicated Exim and Dovecot nodes added as additional MX records<\/td><td>Businesses running critical email through their hosting<\/td><\/tr><tr><td>DNS-Only Nodes<\/td><td>Lightweight BIND nodes, usually in another datacenter<\/td><td>Staying resolvable even when the main site has problems<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Local Caching for Read-Heavy Sites<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">NFS is a network read, and a network read is slower than a local disk read. For most files, that difference is invisible. For a WordPress site reading the same plugin and theme files thousands of times per second, it can quickly add up.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Local caching addresses exactly that.&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">On accounts where it helps, we copy selected read-heavy directories to each web node&#8217;s local disk and serve them from there, while everything else keeps running from shared storage. On sequential reads of cached files, throughput is roughly 60 times that of NFS; on the small-file random reads typical of a website, 1.1 to 1.4 times. Up to 30 paths per account can be cached, and changes propagate on a configurable interval &#8211; five minutes by default.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">It&#8217;s enabled per account by our team when the workload justifies it, not by a switch in the panel.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What You See in SPanel<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Cluster Management in the SPanel Admin Interface is where you watch the environment.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The <strong>Status &amp; Health<\/strong> page summarizes the cluster in tiles &#8211; node count with an online-versus-stale split, NFS storage, the MariaDB Galera cluster, and DNS servers &#8211; and three tabs carry the detail:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Nodes. <\/strong>Every member with its hostname, IP address, role, load, disk, memory, replication state, last update, and status.<\/li>\n\n\n\n<li><strong>Services. <\/strong>Per-node daemon status for the web server, PHP-FPM, MariaDB, MaxScale, Exim, Dovecot, BIND, NFS, and the firewall.<\/li>\n\n\n\n<li><strong>Activity Log. <\/strong>Node joins and removals, health changes, service failures, and configuration updates, filterable by severity.<\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">&#8220;Stale&#8221; has a specific meaning here. Every node writes its health data once a minute; if 10 minutes pass without an update, the panel marks that node stale. Stale isn&#8217;t the same as dead &#8211; a broken cron job or a network hiccup will do it &#8211; but it&#8217;s a reliable signal that something needs attention.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">One design decision shapes all of this&nbsp;<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The interface is deliberately read-only. There&#8217;s no &#8220;add node&#8221; button and no way to remove one by misclicking. Cluster operations are consequential enough that we run them ourselves &#8211; you tell us what you need, and our team provisions it. Security doesn&#8217;t get thinner as the cluster gets wider, either: <a href=\"https:\/\/www.scalahosting.com\/website-security.html\"><strong>SShield<\/strong><\/a> runs its real-time monitoring on every node, exactly as it does on a single VPS.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>One Server vs. a Cluster: Side by Side<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Here&#8217;s how the two setups compare on the factors that actually drive the decision:<\/p>\n\n\n\n<figure class=\"wp-block-table is-style-regular green-rows\"><table class=\"has-fixed-layout\"><thead><tr><th><strong>Factor<\/strong><\/th><th><strong>Single SPanel Server<\/strong><\/th><th><strong>Managed Cluster<\/strong><\/th><\/tr><\/thead><tbody><tr><td>Survives a node failure<\/td><td>\u274c One machine, one point of failure<\/td><td>\u2705 Sites stay up on the remaining nodes<\/td><\/tr><tr><td>Adds capacity by<\/td><td>Upgrading the machine (vertical)<\/td><td>Adding nodes (horizontal)<\/td><\/tr><tr><td>File consistency<\/td><td>Local disk<\/td><td>One shared copy over NFS<\/td><\/tr><tr><td>Database consistency<\/td><td>A single MariaDB instance<\/td><td>Galera synchronous replication<\/td><\/tr><tr><td>Per-request page speed<\/td><td>Baseline<\/td><td>Unchanged &#8211; capacity scales, speed doesn&#8217;t<\/td><\/tr><tr><td>Cost and complexity<\/td><td>Lower<\/td><td>Higher &#8211; more machines to coordinate<\/td><\/tr><tr><td>Topology changes<\/td><td>You manage the one machine<\/td><td>Requested through our technical team<\/td><\/tr><tr><td>Best for<\/td><td>Most sites; moderate, predictable traffic<\/td><td>Availability-critical or high-capacity work<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Two Setups From Real Customers<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">A WordPress agency running 50 client sites uses a three-node full cluster with traffic spread evenly across all three. On a single machine, one hardware fault takes all 50 sites down at once &#8211; and brings 50 client phone calls with it. On the cluster, the same fault costs a third of the capacity and nothing else.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">A WooCommerce store doing $1 million a month runs a very different shape: one storage node, two web nodes, three database nodes, a dedicated mail node, and two DNS-only nodes in a second datacenter. The database was the bottleneck, so it got its own hardware. Email is business-critical, so it got redundancy. DNS sits somewhere else entirely, so the store stays resolvable on its worst day.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Different problems, different shapes. That&#8217;s the point of role-based design &#8211; you pay for redundancy where you actually need it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The Limits: What a Cluster Won&#8217;t Do<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The honest limits, because they change the decision for some readers:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>A cluster is not a backup. <\/strong>Replication copies mistakes as faithfully as it copies orders. A bad deployment or a dropped table reaches every node in seconds. If your real fear is one accidental deletion rather than hardware failure, backups with point-in-time recovery matter far more than a second node.<\/li>\n\n\n\n<li><strong>It isn&#8217;t auto-scaling. <\/strong>Nodes are added and removed by our team &#8211; quickly, but not automatically seconds after a spike.<\/li>\n\n\n\n<li><strong>It doesn&#8217;t replace a CDN. <\/strong>Global delivery of images, CSS, and JavaScript is a different problem, best solved by a CDN in front of the cluster.<\/li>\n\n\n\n<li><strong>Storage is one node, not a distributed filesystem. <\/strong>It runs on redundant hardware with hypervisor-level failover beneath it, but adding nodes doesn&#8217;t add storage redundancy inside a single cluster.<\/li>\n\n\n\n<li><strong>Only MariaDB is clustered. <\/strong>PostgreSQL and other engines run on individual nodes; clustering them needs a separate approach.<\/li>\n\n\n\n<li><strong>Across datacenters, replication is asynchronous. <\/strong>Within one datacenter, Galera is synchronous and consistent. Between datacenters, latency makes that impractical, so a regional failover can lose a few seconds of the most recent writes.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>How to Decide Between a Single VPS vs. Cluster Hosting<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Four steps, in order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Price your downtime. <\/strong>Estimate what an hour offline costs during your busiest week, not your quietest. Compare it to the monthly cost of additional nodes.<\/li>\n\n\n\n<li><strong>Check your ceiling. <\/strong>If load, memory, or disk regularly run near their limits in a normal week, capacity is already the constraint.<\/li>\n\n\n\n<li><strong>Rule out the cheaper fix. <\/strong>Slow pages, missing caching, and unindexed queries are application problems. A cluster won&#8217;t solve them, and solving them may remove the reason to scale out at all.<\/li>\n\n\n\n<li><strong>Pick the shape before you call. <\/strong>Decide whether your risk sits in availability, database load, email, or DNS. That determines the topology, and it makes the conversation with our team much shorter.<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Making the Call<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The decision isn&#8217;t about how big your site is. It&#8217;s about what a bad hour costs you and how close your current machine sits to its limit &#8211; and for most sites, most of the time, the honest answer is still one server.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">If it isn&#8217;t, the shape of the cluster matters more than the number of nodes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Frequently Asked Questions<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>When Should a Business Move From One Server to a Cluster?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> Move when downtime costs more than the extra infrastructure, or when one machine can no longer handle peak traffic. If a short outage would seriously hurt revenue, or your server regularly runs near its limits on load, memory, or disk, a cluster earns its keep. Otherwise, one well-backed-up machine is cheaper and simpler.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>Does Clustering Make My Website Faster?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> Not directly. A cluster improves availability and total capacity, but a single request still runs on one node at that node&#8217;s speed. Pages that are slow because of unindexed queries or missing caching stay slow on every node. Fix application performance first, then cluster for resilience and concurrency.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>What Is the Smallest Practical Cluster?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> Three nodes. Two is technically possible, but Galera needs more than half its database nodes online to accept writes, so a two-node cluster stops accepting writes the moment one node drops. Three nodes survive a single failure with quorum intact.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>How Does a Cluster Keep Data Consistent Across Servers?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> Files live in one place: the storage node exports them over NFS and every other node mounts that export as its \/home, so only one copy ever exists. Databases work the opposite way &#8211; each node keeps a local MariaDB copy, and Galera replicates every write to all of them before confirming it. Accounts, domains, and system users stay synchronized automatically.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>Can I Add Cluster Nodes Myself in SPanel?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> No. Cluster Management is built for monitoring &#8211; live status, per-service health, and an activity log across every node. Adding nodes, changing roles, or altering the topology is handled by our technical team. That&#8217;s a deliberate design choice: cluster operations are too consequential to expose as self-service buttons.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>Does a Cluster Replace Backups?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> No. Replication copies every change across nodes, including the ones you regret. A bad deployment or an accidental deletion propagates exactly like legitimate data, so a cluster offers no protection against human error. Keep separate backups, ideally with point-in-time recovery.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>How Quickly Does Failover Happen?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> Database failover through MaxScale takes seconds, usually less time than a visitor would notice. Web traffic failover depends on the load balancer in front of the cluster, which runs its own health checks and stops sending requests to an unresponsive node. Health data in the panel refreshes once a minute, so the dashboard view lags slightly behind the actual failover.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Q:<\/strong> <strong>What Cluster Topologies Are Available?<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>A:<\/strong> Four. A Full Cluster runs every service on every node. Dedicated Database Nodes offload MariaDB to a Galera cluster, with MaxScale routing queries from the web nodes. Mail Redundancy adds dedicated Exim and Dovecot nodes as additional MX records. DNS-Only Nodes run BIND, usually in another datacenter, purely for zone redundancy.<\/p>\n\n\n\n<script type=\"application\/ld+json\">\n    {\n      \"@context\": \"https:\/\/schema.org\",\n      \"@type\": \"FAQPage\",\n      \"mainEntity\": [{\n        \"@type\": \"Question\",\n        \"name\": \"When Should a Business Move From One Server to a Cluster?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"Move when downtime costs more than the extra infrastructure, or when one machine can no longer handle peak traffic. If a short outage would seriously hurt revenue, or your server regularly runs near its limits on load, memory, or disk, a cluster earns its keep. Otherwise, one well-backed-up machine is cheaper and simpler.\"\n        }\n      }, {\n        \"@type\": \"Question\",\n        \"name\": \"Does Clustering Make My Website Faster?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"Not directly. A cluster improves availability and total capacity, but a single request still runs on one node at that node's speed. Pages that are slow because of unindexed queries or missing caching stay slow on every node. Fix application performance first, then cluster for resilience and concurrency.\"\n        }\n      },{\n        \"@type\": \"Question\",\n        \"name\": \"What Is the Smallest Practical Cluster?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"Three nodes. Two is technically possible, but Galera needs more than half its database nodes online to accept writes, so a two-node cluster stops accepting writes the moment one node drops. Three nodes survive a single failure with quorum intact.\"\n        }\n      },{\n        \"@type\": \"Question\",\n        \"name\": \"How Does a Cluster Keep Data Consistent Across Servers?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"Files live in one place: the storage node exports them over NFS and every other node mounts that export as its \/home, so only one copy ever exists. Databases work the opposite way - each node keeps a local MariaDB copy, and Galera replicates every write to all of them before confirming it. Accounts, domains, and system users stay synchronized automatically.\"\n        }\n      },{\n        \"@type\": \"Question\",\n        \"name\": \"Can I Add Cluster Nodes Myself in SPanel?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"No. Cluster Management is built for monitoring - live status, per-service health, and an activity log across every node. Adding nodes, changing roles, or altering the topology is handled by our technical team. That's a deliberate design choice: cluster operations are too consequential to expose as self-service buttons.\"\n        }\n      },{\n        \"@type\": \"Question\",\n        \"name\": \"Does a Cluster Replace Backups?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"No. Replication copies every change across nodes, including the ones you regret. A bad deployment or an accidental deletion propagates exactly like legitimate data, so a cluster offers no protection against human error. Keep separate backups, ideally with point-in-time recovery.\"\n        }\n      },{\n        \"@type\": \"Question\",\n        \"name\": \"How Quickly Does Failover Happen?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"Database failover through MaxScale takes seconds, usually less time than a visitor would notice. Web traffic failover depends on the load balancer in front of the cluster, which runs its own health checks and stops sending requests to an unresponsive node. Health data in the panel refreshes once a minute, so the dashboard view lags slightly behind the actual failover.\"\n        }\n      },{\n        \"@type\": \"Question\",\n        \"name\": \"What Cluster Topologies Are Available?\",\n        \"acceptedAnswer\": {\n          \"@type\": \"Answer\",\n          \"text\": \"Four. A Full Cluster runs every service on every node. Dedicated Database Nodes offload MariaDB to a Galera cluster, with MaxScale routing queries from the web nodes. Mail Redundancy adds dedicated Exim and Dovecot nodes as additional MX records. DNS-Only Nodes run BIND, usually in another datacenter, purely for zone redundancy.\"\n        }\n      }]\n    }\n<\/script>\n","protected":false},"excerpt":{"rendered":"<p>Move from one server to a cluster when an hour of downtime costs more than the extra nodes, or when &#8230;<\/p>\n","protected":false},"author":106,"featured_media":74791,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"One Server vs. Cluster: When to Scale Out %%sep%% %%sitetitle%%","_seopress_titles_desc":"Should you move from one server to a cluster? See what clustering fixes, what it doesn't, and the exact signals that it's time to scale out.","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[3],"tags":[],"class_list":["post-74790","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-hosting-in-general"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/posts\/74790","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/users\/106"}],"replies":[{"embeddable":true,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/comments?post=74790"}],"version-history":[{"count":3,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/posts\/74790\/revisions"}],"predecessor-version":[{"id":74797,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/posts\/74790\/revisions\/74797"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/media\/74791"}],"wp:attachment":[{"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/media?parent=74790"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/categories?post=74790"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.scalahosting.com\/blog\/wp-json\/wp\/v2\/tags?post=74790"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}