What a second server brings under peak load

Month-end close, planning round, quarterly report: load on a data warehouse rarely arrives evenly. On most days one machine is plenty. On a few days a month, everyone wants large analyses at the same time. Those are the days we tested for.

The setup#

Two small cloud servers with six vCPU each. The first runs the complete platform including the data; the second runs only an additional compute node of the query engine. They are connected through an encrypted WireGuard tunnel; the second node fetches the data through that tunnel and keeps frequently read blocks in its own cache.

We measured with TPC-H, the standard benchmark for analytics: a simulated wholesaler with 60 million line items, 15 million orders and 1.5 million customers, plus eight standard queries from the pricing summary to large orders. The queries went straight to the query engine, without the cache that speeds up dashboards day to day. That is the least favourable case, and it is the one we wanted to see.

Under load: at the result twice as fast#

Two minutes of sustained load per step over the mix of eight TPC-H queries, both variants with the same tool, one directly after the other. Our own measurement of 26 September 2026.

The decisive row is the last one. With one machine, queries pile up at 20 users and throughput drops. With two machines the work spreads across twelve cores instead of six, and the platform holds its pace: 23 completed queries a minute, whether four people are computing or twenty.

With the second server, performance stays stable under peak load: 77 per cent more throughput, half the waiting time.

For a single user the difference is smaller, as expected: all eight queries in a row took 34 instead of 40 seconds. Large scans and joins benefit clearly; the pricing summary, for example, ran in 1.4 instead of 3.0 seconds. Queries that exchange a lot of data between nodes gain little across an internet tunnel. A second server is a tool for many concurrent users, not a turbo for the single query.

The test showed one more thing: with a single machine and 20 heavy queries at once, the query engine reached its memory limit and restarted after half a minute. With the second server it carried the same load without interruption. For the single machine we are setting the limits so that overload is queued cleanly.

When the second server pays off#

• When four or more heavy analyses regularly run at the same time
• When the main machine shows more than 70 per cent CPU for long stretches
• For predictable peaks such as month-end close and planning rounds

Before that, another step pays off: get the most out of the one machine. Give the engine more memory and, where possible, choose a server with more cores. Our test machines had six vCPU; a typical company server has 16 to 32 cores and carries the same load correspondingly more easily. Dashboards and metrics mostly come from the cache anyway and answer in seconds, even on one machine.

Peak load as a fixed quantity#

How a cloud warehouse absorbs the same peak is well documented. With Snowflake, each larger warehouse size doubles the credits per hour. For many concurrent users, a multi-cluster warehouse starts additional clusters, each with its own consumption; this feature requires Enterprise Edition. The peak is elastic, and it shows up on the invoice as a peak.

With lavalake the second server is a fixed quantity: a machine whose monthly price you know in advance, in your own data center or rented. The license does not change, because it counts active users, not servers. Whether month-end close takes two hours or two days, the cost stays the same.

More power for the peak, without the peak setting the bill: the second server costs the same every month.

Next#

Two measurements are coming. The same load on a server with 16 cores, to set the gain from a larger server beside the gain from a second one. And the second server on a private network instead of across the internet, so the data takes the shorter path. The results will go into the sizing documentation.