Mage-OS + Hyvä vs. Magento + Luma: Real Performance Numbers
· david-lambauer · eCommerce Insights · 3 min read
During a recent client pitch, a question came up that vendor benchmarks couldn’t answer cleanly: how much faster is Mage-OS with Hyvä than Magento with Luma under real concurrency?
I decided to find out properly. That meant identical AWS infrastructure for both stacks, a controlled k6 load test, and Full Page Cache deliberately disabled so PHP actually renders every request.
What was tested
Two stacks, zero shared resources. Each ran on its own dedicated EKS node group: four m6i.2xlarge nodes (8 vCPU, 32 GB each). Same Magento 2.4.7-p9 base. Same catalog generated by magento setup:perf:generate-fixtures: 5,000 products across 100 categories. The Luma database was generated first, then dumped and imported into the Hyvä schema to guarantee identical data.
Stack A was standard Magento with Luma: RequireJS, KnockoutJS, jQuery, layout XML with deep block nesting. Stack B was Mage-OS with Hyvä, Alpine.js, Tailwind CSS, and Typesense replacing OpenSearch for storefront search.
The key difference at the PHP level: Luma processes layout XML with complex UI component hierarchies on every request. Hyvä replaces the entire frontend layer with simpler PHTML templates and Alpine.js directives. The server-side rendering path is shorter.
Both stacks had Full Page Cache and Varnish disabled. With FPC on, both serve cached HTML at near-identical speeds. That benchmarks your cache layer, not your platform. Disabling it forces every request through the full rendering pipeline.
The results
250 virtual users, ramped over six minutes, sustained for five minutes, across a realistic traffic mix: 30% browse (homepage + category), 25% search, 25% product detail pages, 20% add-to-cart via REST API. Both stacks ran in parallel in the same time window.
| Metric | Luma | Hyvä | Difference |
|---|---|---|---|
| p50 (median) | 1,040 ms | 201 ms | 5.2x faster |
| p90 | 6,610 ms | 3,580 ms | 1.8x faster |
| p95 | 8,000 ms | 3,680 ms | 2.2x faster |
| Throughput | 36 req/s | 51 req/s | +42% |
The median is the number that matters most for most users. At p50, Hyvä responded in 201 ms while Luma took 1,040 ms. Five times faster, same hardware.
The 42% throughput gap is the capacity planning number. Same infrastructure, same VU count, but Hyvä completed 40,021 requests to Luma’s 28,147 over the 13-minute test. Faster rendering frees PHP-FPM workers sooner, so more requests get through per second.
Neither stack hit a CPU or memory ceiling. Peak CPU on both was around 20-25%. The bottleneck is PHP-FPM worker concurrency, not compute.
Per-page breakdown
The improvement isn’t isolated to one slow endpoint. Every page type shows the same gap.
| Page | Luma p95 | Hyvä p95 | Ratio |
|---|---|---|---|
| Homepage | 7,545 ms | 3,698 ms | 2.0x |
| Category | 7,899 ms | 3,738 ms | 2.1x |
| Search | 8,320 ms | 3,646 ms | 2.3x |
| Product detail | 8,121 ms | 3,703 ms | 2.2x |
| Add to cart (API) | 7,754 ms | 3,670 ms | 2.1x |
Search shows the largest gap at 2.3x. Part of that is the Typesense module returning results faster than OpenSearch for storefront queries. Typesense is also the foundation for the RAG-based AI features described in the companion post about the Shopify pitch.
What the database data shows
Both stacks shared the same RDS MySQL 8.0 instance with separate schemas. Hyvä executed fewer SQL queries per HTTP request (43 vs 56 for Luma) but examined more rows per query. Despite 7x the row I/O, Hyvä’s response times are still 2.2x faster. PHP rendering overhead dominates. Database behavior matters for optimization, but frontend architecture is the bigger lever for perceived performance.
The RDS instance stayed well below its limits throughout. Threads running peaked at 8-10, slow queries were near zero.
I ran this benchmark on 2026-04-12, using Mappia for Kubernetes deployment.
