Loams: the AI-native cloud in your bucket

A production AI application usually runs a small zoo of stateful systems. Each has its own cluster, replicas, upgrade cadence, security model and on-call rotation:

Three problems follow from that table. The same entity lives in four stores glued together by connectors, so when they drift, an agent retrieves stale or contradictory context. The retrieval glue lives in application code: one "hybrid GraphRAG" lookup is BM25 in one service, nearest neighbours in another, a graph hop in a third and a fusion step in Python, and nothing can plan it as a whole. And each store replicates two or three times on block storage and runs around the clock, sized for its peak.

Loams is our answer: one platform for the data side of an AI application, built on object storage and open formats, with compute that holds nothing it cannot rebuild. This post is the first in a series that walks through each part. It says what the platform is, why object storage is the foundation, where we deliberately step off it, and exactly what exists today.

What Loams isCopy Anchor Link

Loams started as a retrieval engine and grew into what we call an AI-native cloud. Its core brings retrieval, reactive state and durable execution together; around it, Loams 0.1.0 ships graphs, MySQL and Postgres, experimental ClickHouse-compatible analytics, SDKs, a console, a desktop app and a CLI. The complete tenancy layer (roles, quotas, a namespace router) is still planned. The Learn overview maps the pieces.

Clients

Qdrant clientsElasticsearch clientsFlight SQL / ADBCResonate SDKsgenerated Connect clientsMySQL and Postgres driversClickHouse clients (experimental)

Loams

Retrieval engineLoams Live (reactive DB)Loams GraphLoams SQL and PostgresDurable executionHouse (experimental)Functions (planned)Jobs (planned)

Stateless roles: gateway, log, query, worker. Any node can be killed.

Metadata and app state

openraft + redb (single node, default)TiKV + PD (clusters, Loams Live)

Durable storage

Your bucket: S3, GCS, Azure Blob, RustFSLanceTantivy splitsIceberg (planned)WAL objects

1. The retrieval engine. Collections of documents with dense and sparse vectors, full text and filters, searched with one planned hybrid query. It speaks the Qdrant API, a subset of the Elasticsearch API, Arrow Flight SQL and its own REST API. Every write lands in a log on object storage first. Part 2 covers it.
2. Loams Live, a reactive application database in the style of Convex, on TiKV: documents, indexes, transactions, queries that stay live and push new results, and a change feed into search. Available in 0.1.0. Part 3.
3. Durable execution (Loams Durable, available). The Resonate server, linked into the Loams binary, so the official Resonate SDKs get durable promises, retries, sleeps, schedules and human-in-the-loop gates from the same system that holds the agent's memory. Part 4.
4. Functions billed on CPU time, still planned after 0.1.0: agent and backend functions that run next to the data and cost nothing while they wait on a model. Part 5.
5. Jobs, still planned after 0.1.0: Celery, BullMQ, PySpark and Flink SQL workloads on Loams with a configuration change, behind one Rust API. Part 6.
6. Postgres and MySQL, a proposal when this was written and available in 0.1.0: Loams Postgres (our hard fork of Neon, loams-postgres) and Loams SQL (MySQL-compatible, on a patched TiDB over TiKV) run beside the engine on the same storage. A branch per agent workspace is still to come. Part 7.
7. Self-hosting with GitOps, still planned (0.1.0 self-hosts with Docker Compose over your own tailnet), and how the line between open source and the managed cloud went away. Part 8.

Why object storageCopy Anchor Link

The retrieval engine's first design rule is that object storage is the only durable source of truth, and compute is stateless. We wrote about the cost side in Why a retrieval engine should live on object storage. The short version:

• Cost. Replicated block storage costs roughly $0.16 to $0.24 per effective GB-month (EBS gp3 at about $0.08, times two or three replicas). S3 Standard is about $0.023, with durability handled by the provider.
• Idle data is the common case. AI applications create an index per user, per workspace, per repository or per agent. Most are idle most of the time. In Loams, a cold namespace is a set of immutable objects. It costs its storage and nothing else until someone queries it.
• Open formats. Documents and vectors are a Lance dataset, full text is Tantivy split files, and analytics tables will be Apache Iceberg (planned; see open formats). Other engines can read them without Loams. If you leave, your data is still readable where it sits.
• Nodes you can lose. Each node holds caches and derived structures only. Killing one loses cache warmth, not data. Scaling is adding or removing stateless processes.

What made this practical is recent. S3 added conditional writes (If-None-Match and If-Match on PUT) in 2024, and GCS and Azure have equivalents, so a single object can be a compare-and-swap commit point. The Rust data stack (DataFusion, Arrow, Lance, Tantivy, object_store, foyer) matured enough to build a serving layer on. And the architecture is proven in production by closed products: turbopuffer for search, WarpStream for streams, ClickHouse Cloud and StarRocks for analytics. Loams applies this approach to vector, sparse and full-text retrieval in one engine, with graph expansion in the retrieval plan experimental in 0.1.0.

The price you payCopy Anchor Link

Object storage is slow to write to compared with a local disk. A write in Loams is acknowledged only after it is durable in the bucket: one PUT of a batched WAL object plus one metastore commit. That is tens of milliseconds, not microseconds. In exchange, an acknowledged write survives the loss of any node, and a query can read it immediately: every write returns a consistency token, and a read that carries it merges the not-yet-indexed tail of the log, so read-your-writes never waits for indexing.

Reads from a cold bucket pay object-storage round trips too. The hot tier (RAM and NVMe caches, and prebuilt HNSW graphs for hot collections) exists to make the warm path fast. Correctness never depends on it: results are identical with the hot tier on or off, and the test suite checks that.

Where Loams steps off the bucketCopy Anchor Link

Not everything belongs on object storage, and we would rather say so than hide it.

• Metadata. Offsets, leases and manifest pointers change hundreds of times a second. S3 conditional PUTs cannot sustain that, so metadata lives in a metastore: embedded Raft (openraft with a redb log) by default, or TiKV in clusters. Manifest bodies stay immutable objects in the bucket; only pointers live in the metastore.
• Application data in Loams Live. An application database needs millisecond transactions over mutable rows. That is what TiKV does, with Raft replication on local disks. So Live's source of truth is TiKV, not the bucket. The Live role itself is stateless, and the design makes continuous log backup of every Live keyspace to object storage mandatory before a cluster serves traffic. When this was written that backup was designed, not built; 0.1.0's loams upgrade snapshots TiKV (with BR or a cold copy) before every upgrade, and continuous log backup is still to come.
• Durable execution and jobs state. Workflow promises and job leases are small, hot, transactional records. They live in SQLite on a single node, and in TiKV in clusters (D261 replaced the earlier TiDB path; the TiKV durable store is in progress in 0.1.0). Large payloads and results go to the bucket.

The rule we hold: the retrieval engine keeps the bucket as its only source of truth, and anything that needs OLTP transactions runs on TiKV beside it, never inside it (D130). A distributed KV is all you need argues for that split.

One tenancy model, one binaryCopy Anchor Link

Everything is organised by namespace. Quotas, encryption keys, cache affinity, routing and usage are per namespace (namespaces and tenancy). A namespace can hold collections and streams, one Live app and its durable workflows. The loams dev command runs every role in one process on a laptop; a cluster runs the same binary with roles split across pools.

The platform is open source under Apache-2.0. Its dependencies are held to the same bar: no AGPL, BSL, SSPL or ELv2 code is linked into the engine. Services with other licenses are only ever run unmodified as separate processes, and we say so where it matters. Since 2026-10-19 nothing is held back: there is no open core, and metering, billing and the hosted control plane are moving into the open repo now (D1119). Ostrium Labs sells services, not a paid edition.

Where this standsCopy Anchor Link

Loams is being built in the open, and much of this series describes design work. Every post ends with a table like this one. Available describes implemented scope with source and test evidence. In progress identifies unfinished component or integration work. Planned means designed or proposed, with no code yet.

Statuses refreshed on 2026-10-18 for Loams 0.1.0; the full table is in Running Loams 0.1.0. Platform capabilities and the roadmap explain the scope behind each status. The next post starts with the part that exists most completely: the engine.