Compose for the reference deployment, Ansible for installation

Observability vs. monitoring in data operations

Monitoring tracks known conditions such as service availability or a threshold being exceeded. Observability supports investigating why a system behaves a certain way. lavalake provides system health, alerts and logs in the console; the metrics endpoint can be integrated into your own monitoring.

Choose a cloud type and operating environment

Public cloud, private cloud and your own data center describe different operating environments. For lavalake, choose the infrastructure and decide who handles installation, backups and updates. Review network access, storage, the identity provider and recovery. Rented servers can be part of the plan alongside existing hardware.

One machine first

A script in the Compose folder generates the secrets on first run, builds console and agent, brings the stack up and configures the Keycloak realm. After that the platform answers on one address. No Kubernetes needed to find out whether the thing is any good.

gateway     nginx, the only door outward
console     the interface
agent       backend, permissions and tools
keycloak    sign-in, roles
trino       the query engine
nessie      versioned Iceberg catalog
minio       S3-compatible storage
postgres    platform state and vector index
ollama      local embedding model (CPU)
backup      daily database and configuration backup

The local embedding model runs alongside and is unloaded when idle so it holds no memory. Semantic search therefore needs no cloud key. The AI assistant does need a backend of your choosing — no model key ships with the platform.

Exactly one door outward

Everything runs behind a reverse proxy, and it knows three routes: the console, the agent interface and Keycloak. Trino, the object store and the platform database are not reachable from outside — not disabled by configuration, simply never published.

What is unreachable needs no hardening. The shortest hardening is a missing route.

That has a consequence worth knowing: BI tools cannot attach to Trino directly. The route there goes through a dedicated read-only feed of the platform, not an open database port.

Customer installation through Ansible

The reference deployment runs as a Compose stack on one machine. The included Ansible playbook prepares a Debian/Ubuntu VM, installs Docker, fetches a pinned release, builds images sequentially and starts the platform. The same workflow handles updates. Existing keys are preserved. A full first run on a fresh VM is still an outstanding acceptance check.

Back up, maintain and attribute usage

A separate service in the Compose stack backs up all PostgreSQL databases daily, including Keycloak and Nessie, together with the configuration and encryption key. Default retention is 14 days; the latest backup is preserved. Monitoring shows age and size and reports missing or overdue backups.

Schedules run reports, threshold alerts and Iceberg maintenance. Monitoring attributes compute time, data read and AI usage to users. Daily quotas limit queries and tokens; AI costs are calculated from configured prices. List prices can be synchronized on demand without overwriting contract prices.

S, M and L workload classes control concurrency and soft memory limits by user role in the Compose stack. Additional workers expand the shared cluster; dedicated warehouse clusters use the Kubernetes deployment path.

What one machine carries

The obvious question before any installation is how large the machine has to be. Since 6 September 2026 there is a measurement rather than an estimate: a reference installation was driven under rising load for a day, until it started rejecting. Every figure below comes from that run.

Across every run that day there was no crash. Thirty seconds after the harshest load, the same installation answered an ordinary query in 76 milliseconds, with no intervention. The bulk import of those 60 million rows completed in 73 seconds — more than 800,000 rows per second.

For sizing this means: a machine of this class carries around 50 concurrent analysts on 60 million rows. If you need more, first get the most out of the one machine – more memory for the engine, a server with more cores – and then add further machines with their own cores.

A second node on the same machine gained nothing: it shares the same six cores. More memory for the one engine gained a great deal — going from 8 to 16 GB raised completed analyses under peak load by 70 per cent. Beyond that it takes more cores: in a larger server or on a second machine.

Only the first row is measured; the others are extrapolated, scaling cores and memory together. Useful for initial planning, not a substitute for measuring on your own hardware.

With a second machine

On 26 September 2026 we added a worker on a second server of the same size and measured with TPC-H, the standard benchmark for analytics: 60 million line items, eight standard queries, deliberately without a cache. The worker brings its own cores and memory and fetches the data over an encrypted network.

Under peak load the second machine delivers 77 per cent more throughput and halves the waiting time. It pays off as soon as several large analyses run at once – at month-end close, for example.

The console shows every compute node with its load and running tasks, and reports when one drops out. The full measurements and the order in which to scale are in the sizing documentation.

The Kubernetes path

For Kubernetes there is a chart that rolls out the platform with its dependencies: three separate PostgreSQL instances for Nessie, Keycloak and platform state, SeaweedFS for storage, Keycloak, Nessie, Trino, an nginx ingress as the single public door, and optionally cert-manager for certificates.

That Keycloak comes from codecentric's chart rather than Bitnami's is not taste: the Bitnami images moved behind a paywall and no longer keep pullable versioned tags. Decisions like that sit in the chart as comments — whoever operates the stack has to know where the images come from.

Object storage and PostgreSQL are dependencies with a switch. If your data center already runs S3-compatible storage and a managed database, point at those instead of operating two more.

Operational building blocks to fit your needs

The security core is in place: delegated identity, policies in the engine, a WORM audit chain, an egress guard, encrypted secrets, parsing in a resource-limited worker. Additional operational layers can be enabled as needed. The Kubernetes HA profile still awaits cluster and failure acceptance.

• HA profile for Kubernetes; cluster and failure acceptance outstanding
• Health, alerts and logs in the console
• Secret files for Compose; Vault/External Secrets for Kubernetes
• Optional internal TLS layer for documented service connections
• Offline Compose deployment with local models
• Point-in-time recovery, with backups to a second location

The operations documentation describes setup, prerequisites and verification for each layer. Compose and Kubernetes differ in coverage.