Introduction
What Loam is, how the engine stores data, and what works today.
Loam is the AI-native cloud on object storage: open-source (Apache-2.0) services that keep an AI application's data in your S3, RustFS, GCS or Azure bucket, in open formats. It has three parts today:
- The engine, a unified hybrid retrieval engine: vector, full-text (BM25) and sparse-vector search fused in one planned query, with graph expansion, Iceberg analytics and a native stream API on the roadmap. Compute nodes are stateless; a RAM + NVMe hot tier makes hot data fast and can be lost at any time without losing data. This guide covers the engine.
- Loam Live, a reactive database on TiKV in the style of Convex, with server functions and a sync API. TiKV is also the engine's metastore. See §20.
- Loam Durable, a Resonate server embedded in the binary, for durable agent runs, schedules, sagas and human-in-the-loop steps. See §21.
Serverless functions billed on CPU time, jobs on Loam (Celery, BullMQ, PySpark, Flink) are proposals, and Postgres on your bucket is under evaluation. The roadmap has the status of each.
The engine's code repository is still named Operon, and the binary is operon. It will be renamed to Loam (package loamdb) in one mechanical change once milestone M1 is complete.
Loam has no release yet
The M0 foundation, collection storage, the query engine with Flight SQL, the hot tier and the Qdrant API are built and pass their gates. The Elasticsearch subset, the SDKs and the MCP server are landing to finish M1; Loam Live (track R) and Loam Durable (track D) are in progress. Expect breaking changes everywhere. See the roadmap.
The design in four points
- Object storage is the only source of truth. Compute nodes hold only caches. Storage costs object-storage prices, with no 3× block-storage replication, and idle namespaces cost nothing but storage.
- The log is the spine. Every write lands in a log on object storage and returns a consistency token. A link worker folds the log into the collection's durable formats; a query that carries the token merges the part of the log not yet indexed, so it reads its own writes.
- Two open formats, one manifest. Documents and vectors live in a Lance dataset; full text, typed fields and sparse postings live in Tantivy splits. One collection manifest binds a Lance version to a split set, and a compare-and-swap on it is the only commit point.
- Standard APIs. A native REST API and Arrow Flight SQL (M1.2), the Qdrant REST and gRPC API (M1.4) and a targeted Elasticsearch subset (M1.5), with Python and TypeScript SDKs and an MCP server (M1.6).
What it replaces
| You run today | Loam object | Stored as | Clients keep speaking |
|---|---|---|---|
| Qdrant, Pinecone | Collection (vectors) | Lance | Qdrant REST and gRPC (M1.4) |
| Elasticsearch for search | Collection (text) | Tantivy splits | Elasticsearch REST subset (M1.5) |
| Glue code fusing both | Hybrid search | One planned query | Native REST, Flight SQL (M1.2) |
Graph expansion for GraphRAG (M3), Iceberg analytics tables (M4) and native streams (M5) come after v1.0. See the decision log for why the scope narrowed from five systems to retrieval.