Managing a portfolio of websites on WordPress has a well-known ceiling. Whether you run WordPress Multisite or a fleet of standalone installs, the architecture eventually fights you — in memory, in response times, in maintenance overhead, and in your hosting bill. This case study documents the real-world difference we observed after migrating a 130-site portfolio from a WordPress stack to multiDomainCMS, our in-house Node.js SSR platform.
The Baseline: WordPress at Scale
WordPress Multisite is the standard answer for running many sites from one codebase. It consolidates themes, plugins, and the admin dashboard under a single WordPress install. On paper it looks efficient. In production, the reality is more complicated.
The PHP-per-Request Model
Every WordPress page request boots a fresh PHP process, loads the WordPress core (~hundreds of files), initializes a database connection, queries MySQL for the post, queries again for menus, queries again for widgets, runs all active plugins through their hook chain, and renders the theme template — before sending a single byte. Even with object caching (Redis/Memcached) and opcode caching (OPcache), the floor for a WordPress response on shared or VPS infrastructure is typically 200–600ms TTFB.
WordPress Multisite Specific Overhead
- A single
wp_database prefix table set multiplies by site count (wp_2_posts,wp_3_posts, etc.), ballooning MySQL table counts into the thousands for large networks - Plugin compatibility across subsites is a constant maintenance burden — a plugin update that breaks one subsite can affect the entire network
- Superadmin operations (network-wide plugin activation, user migrations) lock shared resources and spike load
- Per-site memory limits add up: 50 concurrent requests at 128MB each is 6.4GB RAM — before the web server, database, or caching layer
The Alternative: A Fleet of Standalone Installs
Some agencies prefer 130 separate WordPress installs over Multisite to avoid the coupling. The operational overhead scales linearly: 130 sets of core updates, 130 plugin audits, 130 database connections, 130 separate cron jobs, 130 backup schedules. This is a maintenance engineer's full-time job, not a platform.
The Alternative: multiDomainCMS Architecture
multiDomainCMS runs all 130 domains from a single Node.js Express process backed by one MongoDB collection. The architecture is fundamentally different at every layer.
SSR Without the Boot Tax
Node.js does not boot per request. The server is already running, the React component tree is already compiled, the database connection pool is already open. A request arrives, the router dispatches by Host header, MongoDB returns the post document, React renders to HTML string, the response is sent. The entire cycle — for a cold cache miss — is typically 8–35ms TTFB measured at the application layer.
One Process, 130 Domains
The memory footprint of the entire 130-site network in multiDomainCMS is comparable to a single medium-traffic WordPress install. The Node.js process idles at around 180–220MB RSS. WordPress Multisite serving equivalent traffic would require 2–4GB RAM before hitting swap. This is not a marginal difference — it changes what hardware tier you need.
Benchmark: Head-to-Head Numbers
| Metric | WordPress Multisite | Standalone WP Fleet (×130) | multiDomainCMS |
|---|---|---|---|
| TTFB (uncached) | 200–600ms | 250–700ms | 8–35ms |
| Idle RAM (all 130 sites) | 2–4GB | 4–8GB (distributed) | 180–220MB |
| Concurrent requests before degradation | ~200 | ~50 per site | 10,000+ |
| Plugin/dependency updates | 1 network update (high risk) | 130 separate updates | 1 npm/pnpm update |
| Database connections | 1 MySQL (shared) | 130 MySQL instances | 1 MongoDB (pooled) |
| Zero-downtime deployment | Not built-in | Not built-in | Blue/Green via PM2 |
| Minimum viable VPS for 130 sites | 8GB RAM / 4 vCPU | Multiple servers | 2GB RAM / 2 vCPU |
Where WordPress Still Wins
This is not a blanket dismissal of WordPress. It has real advantages in specific contexts:
- Non-technical editors — the Gutenberg editor and WooCommerce admin are polished, well-documented, and trainable to non-developers
- Plugin ecosystem — 60,000+ plugins cover almost every use case without custom code
- WooCommerce at low SKU counts — for small stores with infrequent traffic, the operational simplicity of WooCommerce beats building a custom commerce layer
- Existing WordPress-heavy teams — if your team knows WordPress deeply, the switching cost of a new stack is real
The crossover point is when you are managing many sites, expect meaningful concurrent traffic, or need sub-50ms response times as a baseline. At that point, the PHP boot model becomes the bottleneck regardless of caching strategy.
Hosting This on WinWinHost
Both architectures are available as managed hosting options on WinWinHost. Our managed WordPress hosting handles core updates, plugin audits, daily backups, and Redis object caching automatically. For agencies and portfolio operators who want the multiDomainCMS approach, our Node.js VPS hosting includes PM2 cluster management, MongoDB provisioning, Nginx reverse proxy configuration, and SSL via Let's Encrypt — everything needed to run the full stack without managing infrastructure yourself.
- Managed WordPress Hosting — for teams that know and prefer WordPress
- Node.js VPS Hosting — for multiDomainCMS and custom Node stacks
- multiDomainCMS Platform — architecture overview and feature list
- Get a free quote — we size the right plan for your portfolio
