What Loams is bad at today

The other posts in this series argue for the decisions behind Loams. This one lists what those decisions have not delivered yet, and what we have not built at all. If you are deciding whether to try Loams, this is the post to read first.

We think a project that publishes its gaps earns more trust than one that lets you find them. Everything below comes from our own release notes, README and design documents, which say the same things in more detail. For each item: what it is, what it means for you, and what we will do.

1. It is 0.1.0, and 0.x means itCopy Anchor Link

Loams 0.1.0 is the first release, after two previews in the week before it. "Available" in our status table means the feature ships in the images and packages and is built and tested in CI. It does not mean production ready.

What it means for you. APIs, on-disk formats and flags may change between minor versions. Upgrades do keep data now: loams upgrade snapshots every store, runs the release's migrations, restarts in order, verifies, and rolls back on failure (design 54). But it moves one release at a time, and it starts at preview.2. Data from preview.1 was never carried forward; a preview.1 stack starts fresh. The snapshots stay on the host and hold your data and your secrets. Other backups are still yours to make.

Several pieces are marked Experimental: Loams House, Git push and fetch to the bucket, and Studio mode in the console. They work and are tested, but they may change more, or be reworked, before they settle.

What we will do. Every release from here keeps data, and the upgrade from the previous release to the candidate runs in CI with fixtures in every product, including the rollback. We would rather slip a release than break that.

2. There is one way to run itCopy Anchor Link

Loams 0.1.0 runs one way. You run the whole stack yourself with Docker Compose, on your laptop or on your own VMs over SSH, and you reach it only over your own Tailscale tailnet, through the console we host at console.loams.dev. The engine never has a public address.

What it means for you.

• You need a Tailscale account, MagicDNS and HTTPS certificates turned on, and the Tailscale client on whatever device you use.
• Headscale is not supported. The compose file has a profile for it, but Headscale issues no *.ts.net certificates, so the hosted console (an HTTPS page) cannot call the engine through it: the browser blocks it as mixed content.
• You cannot yet host the console on your own Vercel or Cloudflare project, register your own OIDC clients, or deploy with one-click OAuth. All three are listed as coming soon.
• There is no managed Loams cloud. We host the console's static files and, for the oidc mode only, the auth service. Neither connects to your stack.
• No Helm chart, Kubernetes operator or GitOps layout ships yet. Compose is the only supported deployment.
• Your browser (Chrome, Edge or Firefox) may ask permission the first time a page on a public origin calls an address on your tailnet. Allow it for the console's origin; if requests still fail, set Local network access to Allow in the site settings and reload.

We made this choice on purpose (design 43): a stack that is reachable only over a private network you control is a much smaller target than one with a public endpoint, at a stage where the security model is not finished. The cost is a setup step that many people will not want.

What we will do. Headscale, the console on your own hosting and self-service OIDC clients are next on the "coming soon" list. Kubernetes (a Helm chart, an operator and Argo CD layouts) is planned.

3. The security model is solid at the edge and trusting insideCopy Anchor Link

The edge of a 0.1.0 stack is in good shape. Only the Tailscale sidecar is reachable from outside the compose network, only for tailnet members your policy allows, and nothing binds 0.0.0.0 on the host. Every request to the engine's main port is authenticated, by your Tailscale identity, an OIDC token, or a hashed API key. In oidc mode tokens are kept in memory, never in browser storage.

Inside that edge, Loams trusts more than it should:

• Authorization is all or nothing. A valid token or key can do anything the engine can do. There are no per-namespace roles and no tenant quotas.
• The other listeners are not reviewed. The Qdrant, Elasticsearch, Flight SQL, Postgres-wire, MySQL-wire and Resonate listeners stay inside the compose network. The auth modes are specified for the main port, and those listeners are not all reviewed against them. Do not publish them.
• Traffic inside the compose network is plain text, between the engine, TiDB, TiKV, PD and the Postgres stack. The tailnet encrypts the hop from your device to the stack, not the hops after it. The link from pg-control to its compute runner is plain text too, on its own internal network.
• The Postgres development stack uses default credentials and runs its compute with fsync = off. It is a development stack, and it is the one the release includes.
• No external security review has been done.

What it means for you. Run 0.1.0 on machines and tailnets you control, give credentials only to people you would give the whole stack to, and do not put data in it that you could not afford to lose or leak.

What we will do. Roles, per-namespace authorization, tenant quotas and a namespace router are planned (the M2 hardening milestone, which is what v1.0 means in our roadmap). Report anything you find through SECURITY.md, not in a public issue.

4. One region, and no failoverCopy Anchor Link

A Loams stack lives in one region. The bucket is the source of truth for most of the data, and object storage is highly durable within a region, but if the region's object store is down, so is Loams (design 01 §7). Region failover is in Phase C of the roadmap, the "research and deferred" bucket. Today, disaster recovery means turning on your provider's cross-region replication and versioning for the bucket (design 10), and that covers the bucket, not TiKV.

The parts on TiKV are a second caveat. TiKV keeps its data on local disks with Raft, not in the bucket, so the metastore, Live and Loams SQL depend on TiKV's own replication and backups. We explain that trade in the KV post.

What we will do. Continuous log backup of TiKV keyspaces to the bucket is a stated requirement for Live (D131). Region failover stays in Phase C, after the hardening milestones.

5. Half of the original pitch is still plannedCopy Anchor Link

Loams started as one claim (the pitch): vectors, full text and GraphRAG expansion in one planned query, over open formats including Iceberg tables any engine can read. Hybrid retrieval over collections ships. The other two do not:

• Graph expansion, the 1 to 2 hop GraphRAG step planned together with the retrieval query, is planned. Loams Graph ships as a separate GQL graph database, but its expansion is not yet a stage of the hybrid query.
• Iceberg analytics, tables in a REST catalog readable by DuckDB, Spark, Trino and ClickHouse, is planned. The House writes lake tables, experimentally, but the engine's Iceberg tables are not built.

The rest of the planned list: the Kafka wire protocol and OpenTelemetry logs ingest, MCP agent tools and analytics helpers such as to_arrow(), Loams Functions, and Loams Jobs. First-party connectors are built and tested but no image hosts their runtime yet. Durable state on TiKV is in progress: Loams Durable keeps its state in SQLite, and the design is explicit that a multi-node loams cluster does not accept SQLite for it (D261). Some console pages (Jobs, Connectors, SQL, Git) still show demonstration data, not your stack.

What it means for you. If you need GraphRAG expansion or Iceberg tables from the engine, Loams does not do it yet. The five clusters post says where specialised systems still win.

What we will do. Graph expansion is milestone M3, Iceberg analytics M4 and the Kafka gateway M5 (roadmap). We would rather ship them later and right than ship a demo.

6. Loams Postgres is ahead of its WAL serviceCopy Anchor Link

Loams Postgres runs on our hard fork of Neon (the forks post). Two things about it are not where we want them.

Its images are Neon's last public build until our own builds land (NF1). Those images carry Postgres 17.5. Upstream Postgres is at 17.11. Our first release that is not a rebuild of Neon's revisions, lp-2026.11.0, has to be out before Postgres 17.12 on 2026-11-12.

loams-wal misses its launch targets. loams-wal is the WAL service meant to replace Neon's safekeepers (D714). We set absolute targets before measuring, among them a commit-1 p99 of 10 ms or less and bulk of at least 100 MB/s per timeline (design 46 §9.3). Today every gate file in our bench results is a FAIL. The best store passes the multi-client commit and TPC-B gates against the safekeeper reference, but its bulk throughput is 3 to 10 times short. Two stores are in a bake-off, and its result decides which one ships (Q652). Our risk register says it plainly: launch slips rather than shipping safekeepers. The development stack in the release still runs a safekeeper, which is why the 0.1.0 upgrade has to drain it before recreating it.

What it means for you. Loams Postgres in 0.1.0 is for trying branches, scale to zero and the control plane. It is not a database to put production writes on.

What we will do. Diagnose the bulk bottleneck before changing code (design 46 §9.4), run the bake-off, and publish the numbers when it is decided.

7. It is heavy, and some of it is amd64 onlyCopy Anchor Link

The full stack needs several GB of free memory. TiKV, TiDB and the Postgres stack are the large ones: one PD, one TiKV and one TiDB alone peaked at about 3.2 GB in our playground, mostly TiKV sizing its block cache from host RAM. A laptop can run it, but you will notice.

The patched TiDB image is amd64 only, so on Apple silicon it runs emulated. The server stack is Linux containers everywhere; on macOS and Windows that means Docker Desktop. The House's default sandbox needs Landlock with TCP rules, which means Linux 6.7 or later; on an older kernel its workers refuse to boot rather than run unsealed.

Every TiKV commit also pays a timestamp fetch plus prewrite and commit round trips, and the faster commit modes (async commit and one-phase commit) are off until our linearizability checks pass with them.

What we will do. Turn the faster commit modes back on component by component, each once its linearizability histories pass with them.

8. The desktop builds are not signed for macOS and WindowsCopy Anchor Link

Loams Desktop and the loams CLI ship for Linux, macOS and Windows. Only Linux is signed:

• Linux: .deb, .pacman, AppImage and SHA256SUMS are signed with the project GPG key, which was set up on 2026-10-16. The previews before that shipped without it; every preview.2 desktop file is named -unsigned. .rpm signing is planned through SignPath.
• macOS: ad-hoc signed and not notarized. You have to clear the quarantine attribute once with xattr -dr com.apple.quarantine.
• Windows: unsigned. SmartScreen warns, and you choose "More info", then "Run anyway".

The Windows signing steps through SignPath Foundation are built into the release workflows, but the application to SignPath has not been made, so nothing is signed that way yet.

What it means for you. Check every download against the published checksums, and on Linux verify the checksums' signature with the project key. Clicking through a SmartScreen warning is a habit we do not want to teach, and we know we are asking you to.

What we will do. Make the SignPath application once the project has traction, as our signing policy says. macOS stays unsigned and not notarized for now.

9. The SDKs are thinner than the list suggestsCopy Anchor Link

Seven SDKs are published at 0.1.0: TypeScript, Python, Rust, C#, Go, Swift and C++. Java, Kotlin, Ruby, PHP, Dart and Objective-C are in the repository and in progress, not published. The C++ stubs build against protobuf 36.1 exactly, so there are no vcpkg or Conan ports. Building loams-proto from crates.io needs protoc installed.

What we will do. Publish the remaining six as they pass the shared conformance fixtures, which every published SDK must pass in full.

10. Young dependencies, and the cost of owning themCopy Anchor Link

Loams Graph runs on Grafeo, a young engine with essentially one maintainer, through our fork with a patch queue. We designed for that risk (the graph's truth is our log in the bucket, not Grafeo's files), but our own release notes still say: keep a copy of graph data you cannot recreate. One known limit is that a graph read waits while a write batch commits, so heavy ingestion raises read latency; snapshot isolation in the fork is a design note, not code.

The forks also cost people. We estimate the Neon fork alone at 0.7 to 1.1 full-time engineers a year, staffed as one full-time maintainer plus a second at a quarter of their time (D824). That is time not spent on the planned list above. The forks post explains why we pay it.

What is nextCopy Anchor Link

In rough order, from the release notes, the roadmap and the design documents:

1. Releases that keep data, one step at a time, with the upgrade and rollback gated in CI.
2. Loams Postgres on our own builds, Postgres 17.11 and 16.15 first, then the loams-wal bake-off decision.
3. Coming soon on the deployment side: Headscale, the console on your own Vercel or Cloudflare, self-service OIDC clients, one-click OAuth deploy, and the Loams Git repository service and first-party connectors in the release images.
4. Hardening for v1.0 (M2): authorization and tenancy, quotas, telemetry, the Postgres metastore option and a Kubernetes operator.
5. The rest of the pitch: graph expansion in the hybrid query (M3), Iceberg analytics (M4), the Kafka wire protocol (M5).

If something on this list matters to you more than its position suggests, or if you hit a gap we did not list, open an issue on GitHub. An honest bug report is worth more to us at 0.1.0 than a star.