Loam is pre-alpha: the engine core runs today; Live and Durable are in progress. See the roadmap

GitHubLog inSign up
Roadmap

What runs today, and what comes next.

Loam is pre-alpha. The engine core runs today; Loam Live and Loam Durable are being built in parallel tracks; functions and jobs are proposals, and Postgres on your bucket is under evaluation. Checked against the design documents and the engine repository on 2026-09-29.

AvailableNow: on the engine's main branch, with its gates passing.

In progressNext: partly merged, or built and landing.

PlannedLater: designed or proposed. Nothing to run yet.

Engine

Hybrid retrieval on object storage. v1.0 is retrieval plus production hardening; graph, analytics and streams at scale follow.

  1. Now

    Foundation

    Raft metastore, object-store I/O with fault injection, the log, workers, links, primary-key index, GC. All three exit gates pass.

    Available
  2. Now

    Collection storage

    Lance and Tantivy under one manifest, upserts, deletes, sparse vectors.

    Available
  3. Now

    Query engine

    DataFusion operators, vector, BM25 and sparse retrieval, fusion, the tail merge, native REST, Flight SQL with DoPut ingest, the pluggable metastore trait.

    Available
  4. Now

    Hot tier and routing

    NVMe cache, an HNSW hot tier, pinned splits, affinity routing, write backpressure.

    Available
  5. Now

    Qdrant API

    Qdrant REST and gRPC; the official Python client suite passes in CI.

    Available
  6. Next

    Elasticsearch subset

    Document APIs, _bulk, _search with the core Query DSL, knn and hybrid with RRF. Most of it is on main; docs are landing.

    In progress
  7. Next

    SDKs and MCP

    Python and TypeScript SDKs and an MCP server for agents, built and landing.

    In progress
  8. Later

    Conformance gates and the Loam rename

    LangChain, LlamaIndex, BEIR and ADBC suites pass unmodified. Then the rename from Operon to Loam.

    Planned
  9. Later

    v1.0: production hardening

    Auth and quotas, the native stream API with idempotent producers, OTLP logs, more metastore backends, a Kubernetes operator.

    Planned
  10. Later

    v1.1: cloud and BYOC

    The hosted control plane, OpenFGA authorization, SSO, sharding, billing.

    Planned
  11. Later

    Graph

    Native graph expansion for GraphRAG over collections and tables.

    Planned
  12. Later

    Analytics

    Iceberg tables any engine can read: DuckDB, Trino, Spark.

    Planned
  13. Later

    Streams and scale

    Stream replay and changelog streams, then the quorum WAL and a sharded metastore.

    Planned
Loam Live

A reactive database on TiKV in the style of Convex, and TiKV as the metastore and control-plane store.

  1. Next

    TiKV metastore and the reactive core

    The TiKV metastore, transactions, the commit journal and read-set subscriptions are on main. Server functions, the connect-rust sync API and the TypeScript client are built and landing.

    In progress
  2. Later

    Router and point-in-time restore

    Keyspaces behind the namespace router; restore to any point in time.

    Planned
  3. Later

    Collections bridge

    The change feed from Live into Loam collections, so rows become searchable.

    Planned
  4. Later

    Helm and BYOC

    Live packaged for your cluster and your cloud account.

    Planned
Loam Durable

A Resonate server embedded in the Loam binary: durable promises, schedules, fan-out, sagas, human-in-the-loop and idempotency.

  1. Next

    Embedded Resonate

    The Resonate server linked into the binary with SQLite and TiDB backends, an in-process runtime and a linearizability run are on main. The operations API and bulk import are landing.

    In progress
  2. Later

    TiKV backend and tenancy

    Durable state on TiKV, one instance per namespace.

    Planned
  3. Later

    Durable agents

    Agent runs that survive crashes and long waits, with memory in the same bucket.

    Planned
  4. Later

    connect-rust transport

    The Resonate protocol over the same transport as the Live sync API.

    Planned
Proposed, in design

Directions the owner has set, written up as design proposals. None of this is built yet.

  1. Later

    Postgres wire

    Read Loam over the Postgres protocol with psql and any Postgres driver.

    Planned
  2. Later

    Loam Functions: serverless on CPU time

    Waiting costs nothing: awaits become Resonate promises. workerd (JS, Hono, framework presets) and wasmtime as the cheap tiers, gVisor for containers, Firecracker later. Billed on CPU time plus a small memory charge, with a Dapr API in Rust. Tenant secrets from AWS, Azure, GCP, Vault or Kubernetes through Dapr’s secrets building block.

    Planned
  3. Later

    Jobs on Loam

    Celery through a kombu transport and a Loam result backend, with beat entries as server-side schedules. BullMQ v6 through @loam/bullmq, a Loam backend behind BullMQ’s own unmodified classes. PySpark through a per-namespace Sail server behind sc://. Flink SQL on RisingWave; DataStream jobs run unmodified as managed jobs. Durable mode is opt-in through Resonate decorators. One operon-jobs Rust API with generated Python and TypeScript clients; self-hosted clusters need TiKV.

    Planned
  4. Later

    Postgres on your bucket (under evaluation)

    Evaluating Postgres with its storage on RustFS, with logical replication feeding collections. No MySQL is planned. A branch per agent workspace is an exploration, not a planned feature.

    Planned
  5. Later

    Self-hosted, with GitOps

    RustFS as the default object store, TiKV through its operator, an umbrella Helm chart with sync waves, and a Loam Kubernetes operator forked from an MIT operator.

    Planned
  6. Later

    Loam Commons

    Open-source apps deployed unmodified on Loam to prove it: Plane, Forgejo, Zulip, GlitchTip, OpenPanel and Matomo, with OIDC single sign-on and one OpenFGA model.

    Planned

Milestones close on conformance suites and exit gates, not feature lists. Read the gates and the risk register in §12 Roadmap, testing and risks, and why the scope is shaped this way in the decision log.