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
Stress test of 6 September 2026 on a single virtual machine: 6 vCPU, 24 GB of memory, no swap, the complete platform on it, with a fact table of 60 million rows as the data. Every scenario went through the secured interface, with authentication, authorization and audit.
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 second compute node on the same machine gains nothing: it shares the same cores and trailed the simple configuration in almost every scenario. A further node is worthwhile only on its own machine, bringing its own cores.
- Below the limit: give the engine more memory, as much as the hardware safely allows
- At the limit: add another machine with its own cores
- Never: put several nodes on the same machine — that manages more without computing faster
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.
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 one machine and one data volume. There is no measurement for terabyte estates, for a cluster of machines, or for query patterns other than those tested. 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.37.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