Sizing
The question before any installation is how much hardware it takes. This page answers it with measurements from a reference installation rather than rules of thumb — and says what was not measured.
On this page
Where the figures come from
Two measurements. The stress test of 6 September 2026 ran on a single virtual machine: 6 vCPU, 24 GB of memory, no swap, the complete platform on it, a fact table of 60 million rows as the data, every scenario through the secured interface with authentication, authorization and audit. The load test of 26 September 2026 added a worker on a second machine of the same class and measured with TPC-H, the standard benchmark for analytics.
What a machine of this class carries
| Concurrent users | Kind of load | Measured |
|---|---|---|
| up to 32 | Heavy analyses over 60M rows | Every query error-free, nothing rejected |
| 50 | Heavy scans only, 90 s | 124 completed analyses, nothing rejected, p90 57 s |
| 64 | Heavy analyses | 77 completed, median 53 s, rejections beyond |
| 32 | Short queries, sustained | 3,176 queries in 60 s, median 0.59 s |
The bulk import of those 60 million rows completed in 73 seconds — more than 800,000 rows per second. Across every run there was no crash; thirty seconds after the harshest load the same installation answered in 76 milliseconds.
How to split the memory
The most important setting is how much memory the query engine receives. On the reference installation it is 16 of the 24 GB. The rest belongs to the other services and to the operating system, which needs headroom when there is no swap.
| Engine memory | Memory per query | Completed analyses at 50 users |
|---|---|---|
| 8 GB | 1.92 GB | 73 |
| 16 GB | 3.84 GB | 124 |
Going from 8 to 16 GB raised completed analyses under peak load by 70 per cent and short-query throughput by 43 per cent. If you need more from one machine, give the engine more memory first — not more nodes.
Extrapolation to larger environments
Planning needs reference points beyond the machine that was measured. The table below extrapolates the measurement, scaling cores and memory together — memory has to grow because it was memory that lifted concurrency for heavy analyses: from 8 to 16 GB, completed analyses rose by 70 per cent. The cores set the ceiling. The cores need not sit in one machine: several machines with that many cores between them are the route the measurement suggests.
| Cores in total | Memory | of which engine | Concurrent analysts | Short queries per second | Rows |
|---|---|---|---|---|---|
| 6 (measured) | 24 GB | 16 GB | ≈ 50 | ≈ 55 | 60M |
| 12 | 48 GB | 32 GB | ≈ 100 | ≈ 105 | ≈ 120M |
| 24 | 96 GB | 64 GB | ≈ 200 | ≈ 210 | ≈ 240M |
| 48 | 192 GB | 128 GB | ≈ 400 | ≈ 425 | ≈ 480M |
Only the first row is measured. Every other row is extrapolated, scaling cores and memory together. Query patterns, data distribution and storage all play a part — measure on your own hardware before going live.
When a second machine helps
A worker on a second machine brings its own cores and its own memory. This was measured on 26 September 2026: two cloud servers with 6 vCPU each, connected through a WireGuard tunnel with 12 to 16 ms latency. The data lived on the main machine; the worker read it through the tunnel and kept frequently read blocks in a 20 GB cache.
| Concurrent users | Queries per minute with / without worker | Wait median with / without | Wait p90 with / without |
|---|---|---|---|
| 4 | 22.5 / 17 | 12 s / 16 s | 19 s / 23 s |
| 10 | 22 / 18.5 | 33 s / 41 s | 41 s / 61 s |
| 20 | 23 / 13 | 71 s / 132 s | 94 s / 155 s |
With a worker the installation holds its throughput even at 20 concurrent users: 77 per cent more completed queries and half the waiting time. Without the worker, queries pile up on six cores.
For a single user the gain is smaller: all eight queries in a row took 34.0 instead of 40.0 seconds. Large scans and joins benefit most; individual queries that exchange a lot of data across the tunnel do not get faster.
| TPC-H query | With worker | Without worker |
|---|---|---|
| Q1 Pricing summary | 1.4 s | 3.0 s |
| Q3 Shipping priority | 2.5 s | 3.1 s |
| Q5 Revenue by nation | 3.6 s | 4.5 s |
| Q6 Discount forecast | 0.8 s | 1.0 s |
| Q9 Profit by product group | 7.9 s | 8.8 s |
| Q10 Returned-item customers | 4.5 s | 4.0 s |
| Q13 Customer distribution | 3.6 s | 6.1 s |
| Q18 Large orders | 9.8 s | 9.7 s |
TPC-H scale factor 10: 60 million line items, 15 million orders, 1.5 million customers. Single-user figures are the median of two runs; sustained load ran two minutes each over the mix of eight queries, straight to the query engine and without the tile cache, so the least favourable case. Both variants ran with the same tool, one directly after the other.
The order in which to scale
- First get the most out of one machine: give the engine more memory and, where possible, choose a larger server with more cores. That avoids the data path between two machines.
- Then add a worker on a machine of its own once around four heavy analyses run at the same time or the main machine sits above 70 per cent CPU for long stretches – typically at month-end close and planning rounds.
- A worker adds little for single short queries, for dashboards served from the tile cache, and for queries on the landing zone, the storage catalog or federated sources, which stay on the main machine.
- Never put several nodes on the same machine: they share the same cores and trailed the simple configuration in almost every scenario.
A short data path
The worker fetches every data block over the network. A private network between the servers instead of a tunnel across the internet shortens that path; so does a copy of the object store on the worker machine.
Since v0.195.0 the console shows every connected node under Administration → Operations → System health → Compute nodes, with role, address, vCPU, memory, CPU load, running tasks and uptime. A worker on another machine carries its own marker. If a node is missing for more than five minutes, the alert “Compute node missing” fires.
Example: a mid-sized company
To put the measurement in context, a typical profile. These values are assumptions, not measurements.
| Assumption | Value |
|---|---|
| Company | 250 employees, 30 to 50 analytics users |
| Data volume | five years of ERP order lines, around 50 to 60M rows – roughly TPC-H scale factor 10 |
| Peak load | 5 to 10 concurrent queries, for example at month-end close in the morning |
| Server | typically 16 to 32 cores and 64 to 128 GB of memory |
Dashboards and metrics are lighter than TPC-H and mostly come from the tile cache: answers in seconds, even on one machine. For heavy analyses the measurement shows 33 instead of 41 seconds at ten concurrent users with a worker. On a typical company server with far more cores than the test machine's six, the first step is therefore the larger server, the worker the second.
When the limits were set too tight
Memory limits that are too tight do not produce wrong results but aborts with a clear message. Importing 60 million rows with an engine limit that was too small caused the watchdog to end the container and restart it, each time within roughly 30 seconds. With the limit appropriate to the data volume, the same import ran through without incident.
Overload without a worker
In the load test of 26 September 2026 the query engine crashed without a worker at 20 concurrent heavy queries on 6 vCPU: the coordinator's Java heap filled up, and for around 30 seconds no queries were possible until Docker had restarted it. With the worker, the same load ran without a crash. The right behaviour is to queue the load or abort individual queries with a clear message; the fix is in progress. Until then, on a single 6-vCPU machine set the workload classes so that 20 heavy queries do not run at once.
Test question after an abort
Does the fault disappear when a number in the configuration goes up? Then it was sizing. Does it remain? Then it is something else — and monitoring is the better place to look than the memory settings.
What was not measured here
These figures apply to a data volume of around 60 million rows and to machines with 6 vCPU. The cluster was measured with exactly two machines across an internet tunnel, not on a private network and not with more than one worker. There is no measurement for terabyte estates, larger servers or other query patterns. If you are planning such an environment, measure on your own hardware rather than extrapolating from these values.
Applies to: This page describes lavalake 0.195.0. Product and documentation live in separate repositories — when in doubt, what the console shows is authoritative.
Something missing?
If these pages do not answer your question, we will walk through the platform against your own case in half an hour.
Book a demo