On this page
Search and vector databases were designed for a world of a few large, always-busy indexes. They keep data on replicated block storage, size clusters for peak load, and run them around the clock.
AI applications don't look like that. They create an index per user, per workspace, per repository or per agent. A few are busy right now; most sit idle for hours or days. Paying replicated-disk and always-on-RAM prices for data nobody is querying is the wrong cost model.
Loam starts from the opposite assumption. Object storage is the only durable source of truth, and compute is stateless (the first decision in the decision log).
The cost gap is structural
Stateful search clusters replicate each shard two or three times on block storage. At roughly $0.08 per GB-month for EBS gp3, that is about $0.16 to $0.24 per GB-month of effective storage, before you count the instances that must stay up to serve it. S3 Standard is about $0.023 per GB-month, with durability handled by the provider.
When most namespaces are cold, the difference compounds. A cold namespace in Loam is a set of immutable objects in a bucket. It costs storage and nothing else until someone queries it.
Compute is a cache you can lose
Every Loam node holds only derived, rebuildable state, arranged in four layers (§04 Hot tier):
| Layer | Medium | Holds |
|---|---|---|
| H0 metadata | RAM | Manifests, split hotcaches, file footers |
| H1 object cache | RAM → NVMe | Byte ranges of durable objects, in a foyer hybrid cache |
| H2 hot structures | RAM / NVMe | Acceleration structures, such as an HNSW graph for vectors (built with the hot tier, now available) |
| H3 tail | RAM | Records already in the log but not yet in the durable index |
Durable objects are immutable and named by ULID or version, so H0 and H1 never need invalidation. Only pointers move: the current manifest of a collection, for example. Losing a node loses cache warmth, not data.
Open formats, in your bucket
Because the bucket is the database, the format of the bucket matters. Loam stores documents and vectors as a Lance dataset and full text as Tantivy split bundles (Quickwit's split format), bound together by one manifest. Iceberg tables for analytics come later (planned).
Lance is readable outside Loam: DuckDB's Lance extension, pylance and Polars can read the dataset, given the pinned version Loam hands out. You are not locked into a proprietary format that only one vendor's engine can read.
What it costs: the write path pays for durability
Nothing here is free. A write is not acknowledged until it is durable in object storage:
- The writer batches records into a WAL object and PUTs it to the bucket.
- The metastore commits the object and assigns dense offsets.
- The write returns a consistency token: the stream, partition and offset it landed at.
That is an S3 PUT plus a metastore commit on every acknowledgement, the same order of cost that other object-storage-native engines pay. In exchange, an acknowledged write survives the loss of any node.
A query that carries the token sees the write even before a background worker has folded it into Lance and Tantivy, because the query merges the log tail (applied offset, token offset] from the H3 layer. Read-your-writes does not have to wait for indexing. (The tail index shipped with the query engine and is available.)
Where this leaves latency
Cold queries pay object-storage round trips; warm queries are served from RAM and NVMe. The hot tier exists to make the warm path fast, and correctness never depends on it: results are identical with the hot tier on or off, which is one of the exit gates for the collections milestone.
The hot tier now exists; we will publish measured numbers once the collections milestone's exit benchmarks run, not before. Until then, the architecture is the claim: one copy of your data, in your bucket, in open formats, with compute you can scale to zero.