Trust
Reliability
Lux is a new database, so reliability needs to be explicit. This page documents the current durability model, the test gates we run before release, and the limits we do not want users to infer from marketing copy.
Durability model
Lux core uses write-ahead logging and snapshots. Startup is expected to initialize storage, load snapshots, and replay WAL before the runtime reports ready.
Lux Cloud layers managed restarts, snapshot storage, metrics, logs, and project-level controls on top of the core runtime.
Release gates
- • Core unit and integration tests for commands, tables, WAL replay, snapshots, vectors, queues, time series, auth, HTTP, and realtime.
- • SDK tests for browser, server, SSR, auth sessions, table builder results, and direct client behavior.
- • Container smoke tests for boot, auth, HTTP, websocket, persistence, and direct protocol access.
- • Cloud smoke tests for project creation, migration application, seed files, project keys, OAuth, and SDK gateway queries.
Benchmark methodology
Benchmarks are only meaningful when they name the hardware, command mix, value sizes, concurrency, pipeline depth, network path, persistence settings, and comparison target. Lux is designed to perform well under pipelined workloads, realtime fanout, and mixed primitives, but benchmark numbers should always be tied to a reproducible script.
For public claims, prefer conservative language: “measured on this workload” instead of blanket statements about every Redis-compatible or realtime workload.
Known limits
- • Formal public uptime SLOs are not yet published.
- • SOC 2 and third-party compliance reports are not yet available.
- • Benchmark claims should be treated as environment-specific unless the hardware, workload, and command mix are stated.
- • Direct protocol access is intended for trusted server-side environments. Browser apps should use project keys through the Cloud gateway.