Docs / Operations Operate
Storage
Sizing, layout and scaling the ledger in production.
An index lives under .ekos/ (or a named container path). Rough guidance from real runs:
| Workspace | Objects | Ledger entries |
|---|---|---|
| EKOS's own repository (multi-language) | ~16,700 | ~204,000 |
Ledger size grows with history because it is append-only; identical objects are skipped on re-commit.
Choosing a layout
- New workspaces: the fact engine (default).
- Existing SQLite workspaces: keep them; migrate deliberately with
ekos ledger migrate --v3. - Very large or long-lived ledgers: partition by dimension and time bucket (
[storage.partition]). - Multiple machines: distributed mode — a coordinator, compile workers (lease/heartbeat protocol), query workers, and a gateway that merges per-shard statistics and fuses rankings. The object-store read path was verified against MinIO and a 95-partition workspace.
Disk
Keep .ekos/ on local SSD storage: the fact engine memory-maps segments. Clear .ekos/artifacts/ with ekos clean if only the artifact cache is large.