Sizing and requirements are two different questions
Requirements are the software versions Magento needs per release (PHP, MariaDB or MySQL, OpenSearch, Valkey, Varnish). Sizing is how much CPU, RAM, storage and how many servers your particular store needs to run those versions well at your peak load, and when to scale.
Adobe documents the versions on its system requirements page, and we keep a current checklist on our Magento 2 prerequisites page with the changes for the current release in what changed in Magento 2.4.9. This guide does not repeat them; it is about capacity.
What Adobe and the vendors actually document
Adobe's hardware guidance sizes CPU by requests, not visitors: cores equal expected requests divided by two, plus cron processes, because "one CPU core can serve around two (sometimes up to four) Commerce requests effectively". PHP memory is documented per role, database memory should be at least close to half the data size, and the only fixed figure is 2 GB of RAM to install or upgrade.
Documented guidanceSources: Adobe hardware recommendations (updated 1 June 2026), software recommendations (16 March 2026), system requirements (September 2026), performance toolkit profiles (24 April 2026); OpenSearch, MySQL and PHP documentation as linked.
| Area | Documented guidance (source) | What it means for sizing |
|---|---|---|
| CPU | Cores = (expected requests ÷ 2) + expected cron processes; one core serves around two, sometimes up to four, requests (Adobe hardware recommendations). Adobe does not state the unit of "expected requests"; the natural reading is requests being handled at once. Adobe recommends scaling manually, or auto-scaling the web tier, for peak sales periods. | Size CPU from concurrent uncached requests at the busiest hour and reserve cores for cron and indexing. |
| PHP memory | About 2 GB on a single-server setup; 256 MB for a storefront-only web node; 1 GB for the admin with a large catalogue; more than 256 MB for cron indexing a large catalogue; 756 MB to compile static assets (Adobe hardware recommendations). memory_limit of 1G in production, 2G for debugging (Adobe software recommendations). | PHP memory is budgeted per role; a single server carries all roles at once. |
| OPcache | opcache.memory_consumption 512 MB, max_accelerated_files 60,000, validate_timestamps off; realpath cache 10 MB; APCu enabled (Adobe software recommendations). | About 0.5 GB of RAM is spoken for by OPcache alone. |
| Database memory | "The amount of memory available should be, at minimum, close to half the size of the data stored in the database" (Adobe hardware recommendations). InnoDB buffer pool instances of at least 1 GB each; max_connections 300 for small and 1,000 for medium environments (Adobe software recommendations). MySQL's innodb_dedicated_server option sets the buffer pool to 50% of memory at 1 to 4 GB and 75% above 4 GB, recommended only when the database has the server to itself (MySQL 8.4 manual). | Database RAM follows database size, which follows catalogue and order history. On a shared single server the pool is a slice, not three quarters of everything. |
| OpenSearch | OpenSearch 3 is required for Magento 2.4.9 (Adobe system requirements). "Tune the number of instances based on search traffic" (Adobe reference architecture). "We recommend setting the heap size to about half the memory available on the system" (OpenSearch configuration documentation). | The half-of-RAM rule is for a node running only OpenSearch; on a shared server budget a slice and move search out when it needs more. |
| Cache | Redis or Valkey with enough memory to hold all caches in memory; separate instances for sessions and default cache in multi-server setups; Varnish as the production full-page cache, on separate infrastructure where possible; up to 1 Gbit of network to Redis for hundreds or thousands of simultaneous requests (Adobe hardware and software recommendations). Valkey 9 for 2.4.9 (Adobe system requirements). | Cache memory follows the working set (pages, blocks, sessions), which follows catalogue and traffic. |
| PHP-FPM workers | pm.max_children "sets the limit on the number of simultaneous requests that will be served" (PHP-FPM configuration reference). No memory ratio is documented. | Workers cap concurrency; the count comes from the PHP memory budget divided by the measured footprint of one worker. |
| Minimum RAM | Installing or upgrading "can require up to 2 GB of RAM"; create a swap file below that (Adobe system requirements). | An install floor, not a production recommendation. |
| Store size classes | Adobe's performance toolkit profiles: small 800 simple products, medium 24,000, large 300,000, extra large 600,000, with 30, 300, 3,000 and 6,000 categories. | The only Adobe-published catalogue size classes; this guide's tiers are anchored to them. |
| Multi-server architecture | Separate web tier, a dedicated Redis instance for sessions, replica and split databases for high traffic, search instances tuned to search traffic, shared media storage (Adobe reference architecture). Commerce Cloud Pro runs three nodes behind a load balancer; "add extra web servers ... should the constriction be at the PHP level rather than the database level" (Adobe Pro architecture). | The documented shape of separated and clustered Magento; capacity numbers are not published. |
How does traffic affect Magento server sizing?
Traffic loads a Magento server only through the requests that reach PHP and the database. With a full-page cache in front, most catalogue and content page views never touch PHP; cart, checkout, customer account, search results and personalised pages always do. Two stores with the same monthly visits can therefore need servers several times apart, and the useful measure is uncached requests at the busiest hour, not visits per month.
- Peak hour, not monthly average. Capacity is consumed in the busiest hour. Read it from your analytics or web logs; as an EveryHost engineering assumption, plan for the busiest hour being several times an average hour, and for campaign peaks being several times that again.
- Uncached share. A store where visitors browse needs far less PHP than one where they log in, hold carts and check out. B2B pricing, customer-group catalogues and logged-in browsing raise the uncached share sharply.
- Checkout and orders. Every order is a chain of uncached requests, payment and tax calls, database writes and queued emails. Adobe recommends processing emails and order grids asynchronously to move that work off the checkout request.
- Concurrency. How many sessions are active at once at peak decides how many PHP-FPM workers must exist, and each worker holds memory whether busy or idle.
- Bots and crawlers. On many catalogue-heavy stores automated traffic that analytics never counts is a large share of the requests reaching PHP. Size from server-side measurements, not only from analytics.
How does catalogue size affect Magento hosting?
Catalogue size sets the memory a store needs before a single visitor arrives. SKUs, attributes, store views and categories decide the size of the database, the OpenSearch index, the flat and index tables and the media library, and therefore the buffer pool, the search heap and the disk the server must carry. A large catalogue on a quiet site can need more RAM than a small catalogue on a busy one.
EveryHost engineering assumptionFor planning, EveryHost assumes roughly 2 GB of database for a small store plus about 0.35 GB per thousand SKUs, growing with order history; about 8 MB of media per SKU including resized copies; and an OpenSearch index that grows with SKUs times store views times searchable attributes. Real figures vary widely, which is why we ask for your actual database and media sizes before quoting. Indexing and imports scale with the catalogue too: Adobe recommends indexers on Update on Schedule because Update on Save causes "significant delays and data unavailability during high loads" (Adobe configuration best practices).
How much RAM does Magento need?
Magento's RAM need is a sum of components, not a single figure: PHP-FPM workers, OPcache, the database buffer pool, the OpenSearch heap, the Valkey or Redis cache, Varnish and the operating system. As an EveryHost starting point, a small production store on one server needs 14 to 16 GB, a growing store with tens of thousands of SKUs 32 to 64 GB, and a store with around 100,000 SKUs 96 GB or more, or its database and search on a separate server.
| Component | Basis | Small store (about 1,000 SKUs) | Growing store (about 25,000 SKUs) | Large catalogue (about 100,000 SKUs) |
|---|---|---|---|---|
| PHP-FPM | Adobe: about 2 GB on a single server; workers × measured footprint above that (EveryHost starting point) | 2 GB | 4 to 8 GB | 8 to 16 GB |
| OPcache | Adobe: 512 MB | 0.5 GB | 0.5 GB | 0.5 GB |
| Database buffer pool | Adobe: at least close to half the data; EveryHost starting point: about three quarters of the data on a combined server | 2 to 3 GB | 8 to 15 GB | 25 to 45 GB |
| OpenSearch | OpenSearch: half of node RAM on a dedicated node; EveryHost starting point on a shared server | 1.5 GB | 2 to 4 GB | 4 to 8 GB, or its own node |
| Valkey or Redis | Adobe: hold all caches in memory; EveryHost starting point | 0.5 to 1 GB | 2 GB | 4 to 8 GB |
| Varnish | Adobe: sufficient memory for popular pages; EveryHost starting point | 0.5 to 1 GB | 1 to 2 GB | 2 to 4 GB |
| Operating system, nginx, cron, monitoring | EveryHost starting point | 2 GB | 2 GB | 2 to 4 GB |
| Total with about 15% headroom | EveryHost starting point | 14 to 16 GB | 32 to 64 GB | 96 GB or more, or separated |
Assumptions: one store on the server; Varnish or the built-in page cache in front of PHP; a current 2.4.x stack; order history of a year or two. Heavy integrations, many store views or a large uncached share push every line up.
How many CPU cores does Magento need?
Adobe does not publish a core count per store size. Its rule is cores equal expected requests divided by two plus cron processes, on the basis that one core serves around two, sometimes four, requests at a time, so the answer depends on how many requests reach PHP at your busiest hour. As an EveryHost starting point we do not build production Magento on fewer than 4 cores, growing stores move to 12 or more cores at high clock speed on a dedicated server, and beyond that cores are added per node rather than to one machine.
Documented guidanceApplying Adobe's rule needs two figures you can measure: the number of uncached requests in flight at peak (PHP-FPM's status page reports active processes) and the number of cron and consumer processes you run. Clock speed matters as much as core count for uncached pages, because a single checkout request runs on one core; EveryHost's dedicated servers run at 3.6 to 4.7 GHz for that reason.
EveryHost starting pointThe CPU starting points in the tiers below are what we build for stores of each profile with an effective page cache. They are configurations we consider reasonable, not thresholds and not Adobe requirements. A store with a poor cache hit rate, heavy extensions or B2B logged-in traffic sits a tier higher than its visits suggest.
EveryHost engineering assumptionCron and indexing deserve their own cores: we reserve one to two cores for cron and consumers on small and medium catalogues and three to four on large ones, following the cron term in Adobe's formula.
Is a VPS enough for Magento?
For most stores with up to a few thousand SKUs and tens of thousands of visits a month, yes, provided it is a properly specified VPS: as an EveryHost starting point, 4 cores, 14 to 16 GB RAM and NVMe storage with the whole stack installed on it. A VPS stops being enough when PHP-FPM saturates at peak with the cache already effective, when the database and search index no longer fit comfortably in RAM alongside PHP, or when you need single-tenant hardware for consistent clock speed and no noisy neighbours.
The word VPS covers a wide range. What matters is dedicated CPU allocation rather than shared vCPUs, NVMe rather than network storage, enough RAM for the full component budget, and the freedom to tune PHP-FPM, MariaDB, OpenSearch and the cache for one store. Our managed Magento 2 hosting is built on that basis.
When should Magento move to a dedicated server?
Move when the store's own peak load needs the whole machine: CPU sustained near capacity through the busiest hour, PHP-FPM workers saturating, memory pressure or swap, checkout slowing while cached pages stay fast, or indexing and queue consumers falling behind. As an EveryHost starting point, that usually happens for stores in the tens of thousands of SKUs with hundreds of thousands of visits a month, earlier with heavy integrations or B2B traffic, and a dedicated server of 12 or more cores at high clock speed with 32 to 64 GB is the usual first dedicated step.
A dedicated server gives consistent single-thread performance for uncached pages, no co-tenants competing for CPU or disk at your peak, and enough RAM to run the database and search comfortably alongside PHP. Our dedicated Magento servers start at 12 cores and 32 GB, and the buyer's questions are on our dedicated hosting explainer. The symptoms table below is the trigger; the visit count is not.
How do I know my Magento store has outgrown its hosting?
Match recurring peak-time symptoms to the component that is saturating. One symptom alone is often configuration; two or more together at the busiest hour usually mean the server is too small.
| Symptom | What is saturating | How to confirm | What resolves it |
|---|---|---|---|
| Sustained CPU pressure at peak | PHP-FPM workers all busy; requests queue; cron and indexers compete | Load average above core count during trading hours; PHP-FPM status shows a listen queue; slow time to first byte on uncached pages | More cores and clock speed; raise the cache hit rate; move cron and indexing off peak |
| Memory exhaustion and swap | PHP workers, buffer pool, OpenSearch heap and caches no longer fit | Free memory near zero, swap in use, out-of-memory kills in the log, cache evictions rising | More RAM; or separate the database and search onto their own server |
| Checkout and cart slow while cached pages stay fast | The uncached request path: PHP and database at the same time | Compare time to first byte of a category page (cached) with add-to-cart and checkout steps under load | CPU and database capacity; asynchronous email and order-grid processing (Adobe's recommendation); a dedicated database server |
| Indexing backlog | Indexers under Update on Schedule cannot keep up; prices and stock go stale | indexer:status shows a growing backlog; reindex durations lengthening | Database capacity and cores for cron; move integrations off peak; separate the database |
| Queue consumer backlog | Message-queue consumers (emails, order grid, asynchronous operations) behind | queue_message table or RabbitMQ queue depth growing; order emails delayed | Consumer processes and cores; RabbitMQ on its own resources at scale |
| Database contention | Lock waits, slow queries, connections near max_connections | Slow-query log growing at peak; "too many connections"; lock wait timeouts | Buffer pool sized to the data; dedicated database server; read replicas and split order and cart databases for high traffic (Adobe's reference architecture) |
| OpenSearch pressure | Heap near its limit during reindex; slow search results | Heap use near maximum in the node stats; search latency rising under load; long reindex times | More heap on a shared server; then search on its own node with heap at half of that node's RAM |
| Poor cache performance | Low full-page cache hit ratio; Valkey evictions | Varnish hit and miss counters; cache eviction statistics; PHP requests per page view far above the uncached share you expect | Fix cacheability (cookies, VCL, personalised blocks) before adding hardware; more cache memory |
| I/O wait during imports | Storage cannot keep up with writes and reindexing | High I/O wait when feeds or imports run; page speed dips at the same time | NVMe storage; schedule imports off peak; database on its own disks |
| Peak-time degradation that recovers off-peak | Whichever of the above is closest to its limit | Same pages, same code, different time of day | The clearest single sign that capacity, not code, is the constraint |
A staged framework: from a single node to multiple servers
Magento infrastructure scales in four stages: a single node carrying every service; a larger dedicated single node; separated database, search and cache services; and multiple web nodes behind a load balancer with a database cluster. The move between stages is triggered by measured signals, not by a visit count.
EveryHost starting pointThe catalogue and traffic figures below are examples of where each stage typically applies, anchored to Adobe's toolkit catalogue classes. They are examples, not thresholds, and not Adobe requirements.
| Stage | Example scale | Architecture | Starting configuration | Signals to watch | Next step |
|---|---|---|---|---|---|
| Smaller store | Up to a few thousand SKUs; tens of thousands of visits a month | Single node: nginx, PHP-FPM, MariaDB, OpenSearch, Valkey and Varnish on one server | 4 CPU cores, 14 to 16 GB RAM, 100 GB NVMe (EveryHost starting point) | Rarely hardware. Usually an uncached page, a heavy extension or missing patches | Add RAM before cores when the database or search index grows |
| Growing store | Roughly 5,000 to 25,000 SKUs; low hundreds of thousands of visits a month, often seasonal | Single dedicated server, all services on one box, with headroom for indexing and cron | 12 or more cores at high clock speed, 32 to 64 GB RAM, 500 GB NVMe (EveryHost starting point) | Sustained CPU pressure at peak, PHP-FPM workers saturating, slow checkout while cached pages stay fast, indexer or consumer backlog | More cores and clock speed first; then move the database and search to their own server |
| High-volume store | Tens of thousands to 100,000+ SKUs; hundreds of thousands to a million visits a month | Separated services: web/PHP node plus a database and search node, Varnish in front, or one large server with 96 GB or more | Web/PHP: 16 or more cores, 32 GB; database and search: 32 to 64 GB RAM on NVMe (EveryHost starting point) | Database contention, OpenSearch heap pressure during reindexing, media disk growth, campaign spikes | Dedicated database and search nodes, a Valkey node, read replicas for reporting |
| Enterprise or very high traffic | Very large catalogues, multiple websites, millions of visits a month, campaign peaks | Multiple web nodes behind a load balancer, database cluster, replicated cache, dedicated OpenSearch, shared media storage (the pattern Adobe uses for Commerce Cloud Pro) | Sized from measured peak concurrency and uncached request rate, not from monthly visits | Any single component becoming a single point of failure; availability requirements | Add web nodes when PHP is the constraint; add database capacity when the database is (Adobe's rule) |
When should MySQL or OpenSearch move to another server?
Move a service out when it needs resources that would starve the others on a single box: a database whose buffer pool should be tens of gigabytes, an OpenSearch index that needs a large heap and its own file cache, or a Varnish cache holding a large multi-store catalogue. Adobe's reference architecture separates the web tier, the cache, the database and search for exactly that reason, and on a dedicated database server MySQL's own rule allows the buffer pool to take three quarters of memory.
EveryHost starting pointIn practice EveryHost separates the database and search when the buffer pool would exceed roughly a third of a single server's RAM, when the OpenSearch heap needs more than about 4 GB, or when reindexing and imports visibly slow shoppers. The first split is usually one web/PHP node and one database-and-search node on NVMe, which also gives the database its own disks for imports and checkout writes. Read replicas for reporting and split order and cart databases come later, as Adobe describes for high-traffic sites. Our OpenSearch for Magento and Valkey for Magento pages cover the per-service configuration.
What changes for high-traffic Magento stores?
At high traffic the constraint stops being one server's size and becomes resilience and measured concurrency. Adobe's Commerce Cloud Pro pattern is the documented shape: three nodes behind a load balancer, each with nginx and PHP-FPM, a Galera MariaDB cluster, replicated Redis or Valkey, OpenSearch and shared file storage, with Adobe's rule that web servers are added when PHP is the constraint and database capacity when the database is.
Documented guidanceAdobe's reference architecture adds a two-tier Varnish configuration with an SSL-terminating load balancer for high availability, a Varnish master to limit cache-flush fan-out, one master node running cron or dedicated admin and worker nodes, and search instances tuned to search traffic.
EveryHost starting pointEveryHost's view is that a cluster is justified when a single server outage is unacceptable, or when measured peak concurrency exceeds what one large server carries with headroom. Below that, a well-specified single dedicated server with tested backups is usually the better trade: fewer moving parts and a fraction of the cost. When a cluster is built, it is sized from measured peak concurrency, uncached request rate and database write load, not from monthly visits.
How should Magento hosting be prepared for Black Friday or traffic spikes?
Size for the busiest hour you expect, decided in advance. Adobe recommends scaling manually, or with an auto-scaling model for the web tier, for peak sales periods. Start from last year's busiest hour, apply the growth you expect, and remember that campaign traffic carries a higher share of cart and checkout requests, which are the uncached ones that consume PHP and database capacity.
EveryHost starting pointEveryHost's practice is to load-test the checkout path rather than the homepage, to have the extra capacity in place before the code freeze, which for most UK merchants is around the end of October, and to keep Varnish, Valkey and OpenSearch memory generous enough that a campaign cannot evict the working set. Our Black Friday readiness checklist and checkout speed under peak load articles cover the preparation in detail.
Does Hyvä reduce Magento server requirements?
Hyvä reduces the work each storefront page causes, not Magento's software requirements. Its published claims concern front-end speed; on the server, a Hyvä storefront makes fewer requests per page than Luma, so less of the traffic reaches PHP for the same number of visitors. EveryHost's engineering assumption is that this lowers PHP load modestly and leaves the database, search and cache needs, which follow the catalogue, unchanged. We have not published a measured multiplier and do not size a Hyvä store to a smaller server on the theme alone.
The hosting considerations for a Hyvä storefront are on our Hyvä theme hosting page.
Worked examples: four store profiles
Each example shows a catalogue and traffic profile, the architecture that usually fits it, an EveryHost starting configuration, what to measure, and what would trigger the next scaling step. They are architectural examples with stated assumptions, not exact requirements.
EveryHost starting pointAssumptions for all four: a current Magento 2.4.x stack; Varnish or the built-in page cache in front of PHP; a mostly browsing audience with a typical uncached share; no heavy integrations; UK trading pattern with a busiest hour several times the average. Database and media sizes are planning estimates from the catalogue.
| Store | Catalogue | Traffic | Likely architecture | Starting configuration | What to measure | Next scaling trigger |
|---|---|---|---|---|---|---|
| 1,000 SKUs, 10,000 visits a month | 1,000 SKUs, one store view, database about 2 to 3 GB, media under 10 GB | A few hundred visitors in the busiest hour; a handful of orders a day | Single node, all services on one server, Varnish or built-in full-page cache in front of PHP | 4 cores, 14 to 16 GB RAM, 100 GB NVMe. RAM budget: 2 GB PHP, 0.5 GB OPcache, 2 to 3 GB buffer pool, 1.5 GB OpenSearch, 1 GB Valkey, 1 GB Varnish, 2 GB system | PHP-FPM active workers at peak, buffer pool hit rate, free memory | Memory pressure from a growing database or index; a heavy extension; personalised traffic that bypasses the cache |
| 5,000 SKUs, 50,000 to 100,000 visits a month | 5,000 SKUs, database 4 to 6 GB, media 40 to 80 GB | Up to about a thousand visitors in the busiest hour; tens of orders a day | Still a single node. Whether it is a 4-core VPS or a small dedicated server depends on the uncached share of traffic and on integrations, not on the visit count | 4 to 8 cores, 16 to 32 GB RAM, 100 to 200 GB NVMe | Peak-hour uncached requests per second, PHP-FPM listen queue, checkout time to first byte versus a cached category page | PHP-FPM saturating at peak with the cache already effective; sustained CPU above about 70% at peak; swap use |
| 25,000 SKUs, 250,000 visits a month | 25,000 SKUs, several store views, database 10 to 20 GB, media 150 to 250 GB | Two to four thousand visitors in the busiest hour, seasonal peaks two or three times that; low hundreds of orders a day | Single dedicated server carrying all services, with the database buffer pool and OpenSearch heap sized to the data and NVMe for indexing and imports | 12 or more cores at high clock speed, 32 to 64 GB RAM, 500 GB NVMe. RAM budget: 4 to 8 GB PHP, 0.5 GB OPcache, 8 to 15 GB buffer pool, 2 to 4 GB OpenSearch, 2 GB Valkey, 1 to 2 GB Varnish, 2 GB system | Uncached request rate and PHP worker occupancy at peak, buffer pool size against data size, reindex duration, slow-query log growth | Indexing or imports competing with shoppers; database contention at peak; more than about 60 to 70% CPU sustained through the busiest hour |
| 100,000 SKUs, 1,000,000 visits a month | 100,000 SKUs, multiple store views, database 30 to 60 GB, media 500 GB to 1 TB | Ten thousand or more visitors in the busiest hour; hundreds of orders a day; campaign spikes | Separated services: a web/PHP node behind Varnish, a database and search node on NVMe with the buffer pool and heap sized to the data, cache on its own instance | Web/PHP: 16 or more cores, 32 GB. Database and search: 32 to 64 GB RAM, 2 TB NVMe. Or one server with 96 GB or more RAM and multi-terabyte NVMe | Per-node CPU and memory, replication lag if replicas are used, OpenSearch heap use during reindex, queue consumer backlog, cache hit ratio | Availability requirements (a single server outage is no longer acceptable), or PHP saturating on one node: add web nodes and a load balancer |
What changes down the table is not the visit count so much as where the memory goes: from PHP and a small buffer pool on one node, to a database and search index that want their own server. Traffic decides the CPU and worker count within each stage; the catalogue decides the stage.
Is your current server the right size?
Start by checking your store against the symptoms table above at your busiest hour. Then put your catalogue size, monthly visits, orders and current disk usage into StormGauge, EveryHost's Magento server calculator. It gives an indicative starting point from those figures; it is an estimate, not a specification, and an EveryHost engineer reviews the actual workload before we quote.
If you would rather start with a conversation, give EveryHost your current server specification, monthly traffic, SKU count and order volume and we will review whether the infrastructure is appropriately sized, tell you plainly if it is, and if it is not, what we would build and what moving would involve. Our migration service is free and zero-downtime, and managed Magento hosting means the stack is built and tuned before your store lands on it.
Magento server sizing: frequently asked questions
Sources
- Adobe Commerce hardware recommendations (updated 1 June 2026): CPU formula, PHP memory by role, database and cache memory guidance, peak-period scaling.
- Adobe Commerce software recommendations (16 March 2026): PHP, OPcache, realpath cache, MySQL settings, Redis and Varnish placement.
- Adobe Commerce configuration best practices (19 August 2026): Varnish, indexer mode, asynchronous processing.
- Adobe Commerce reference architecture (19 August 2026): separating web, cache, database, search and storage; high-availability Varnish.
- Adobe Commerce system requirements (September 2026): 2 GB install memory note; supported versions per release line.
- Adobe Commerce performance toolkit profiles (24 April 2026): small, medium, large and extra-large catalogue classes.
- Adobe Commerce Cloud Pro architecture (1 September 2026): three-node cluster and the horizontal-versus-vertical scaling rule.
- OpenSearch configuration and system settings: heap about half of system memory.
- MySQL 8.4 reference manual, innodb_dedicated_server: buffer pool 50% and 75% bands on a dedicated database server.
- PHP-FPM configuration reference: pm.max_children.
This guide is reviewed against the sources above and updated when they change. Reviewed 22 September 2026.