On this page
Updated 2026-10-18 for Loams 0.1.0
Changed: Loams Postgres (our hard fork of Neon, D231, D820) and Loams SQL (a patched TiDB on TiKV, D721, replacing the earlier MySQL-on-the-bucket direction of D301) are available in 0.1.0; engine auth ships; the status table follows 0.1.0; linked the Learn pages.
Loams has two SQL directions: query collections through familiar SQL clients, and run bucket-backed transactional engines beside the retrieval platform. Both have implementation work in the repo. They have different contracts and should be evaluated separately.
Implementation inventory refreshed on 2026-10-07 against 16987e7d3f, and statuses again on 2026-10-18 for Loams 0.1.0. The original evaluation has been overtaken by read-only listeners, a Neon-compatible WAL service, router verification and integration harnesses, and now by two shipped databases: Loams Postgres and Loams SQL.
SQL over collections
The optional pgwire listener implements read-only PostgreSQL access to the collection SQL surface, including session and prepared-query handling. The optional mysql-wire listener implements text-protocol SELECT over the same engine; it rejects writes and prepared statements. These are real protocol implementations, not just planned API contracts.
They are analytical access to Loams collections. A client needing multi-statement OLTP transactions must use a transactional backend. When this was written both listeners stayed loopback-only because engine authentication and TLS were unfinished; engine auth (Tailscale identity, OIDC, API keys) ships in 0.1.0, and the release image is built with both listeners.
Neon-compatible WAL
The loams-safekeeper crate implements the acceptor state machine, Neon wire messages, fenced TiKV storage, raw TiKV append paths and a local NVMe journal. Server features add the loams-wal listener, control API and an interim feeder into a stock safekeeper.
This is concrete infrastructure for Loams Postgres. In 0.1.0, Loams Postgres itself ships: the storage stack from our fork (storage broker, one pageserver, one stock safekeeper, computes), pinned to the fork's own release lp-2026.10.1, plus pg-control and pg-runner (--profile postgres-control) for projects, branches at an LSN or a time, endpoints and suspend when idle. The fork itself changed after this post: D231 made Loams Postgres a fork of Neon, and D820 made it a hard fork, ostrium-labs/loams-postgres, that no longer follows upstream, because upstream had all but stopped moving and we own its releases and security fixes. loams-wal in place of the stock safekeeper, the PgDog front door and TLS are still planned.
Loams SQL and deployment harnesses
MySQL on Loams is Loams SQL: MySQL-compatible SQL on an adapted TiDB, with each database in its own TiKV keyspace, the same transactional store that already backs Loams Live. The repository contains its integration layout as well as Neon and Postgres benchmark tooling. In 0.1.0 Loams SQL is available as one keyspace-mode TiDB (ghcr.io/ostrium-labs/tidb:v8.5.8-loams.1) on the stack's TiKV; its gate (TLS, auth, wake on connect), scale to zero and branches are built or planned but not shipped. (Updated 2026-10-17: an earlier MySQL direction (D301), a GPL MySQL distribution behind a router, with its storage engine on the bucket, was superseded by D721: InnoDB semantics on TiKV is what TiDB already is, and TiDB keeps GPL off the path.)
Scoped harnesses help validate storage and compatibility assumptions. They should not be presented as supported production distributions. Component-specific licenses and deployment prerequisites remain beside each imported or separately operated component.
Router verification
loams-sqlrouter contains a sans-I/O kernel for shard maps, ranges and compatible hashing. Supporting work includes TLA+ models, Lean partition proofs, a differential oracle, compatibility capture/replay and a browser viewer for spec and test runs.
That gives the routing track executable models and tested components. It does not establish end-to-end correctness of a complete multi-tenant SQL service.
Current implementation scope
| Component | Status | Scope |
|---|---|---|
| Postgres and MySQL collection reads | Available | Optional read-only wire listeners over collections |
| Loams Postgres | Available | Storage stack from our Neon fork, pg-control and pg-runner, branches and suspend when idle |
| Loams SQL | Available | One keyspace-mode TiDB on TiKV, reachable inside the compose network |
Neon-compatible WAL (loams-wal) | In progress | Acceptor, wire protocol and TiKV/NVMe stores built; not in the 0.1.0 stack |
| Router verification kernel | Available | Models, proofs, hashing/ranges, oracle and replay tools |
| PgDog front door, the Loams SQL gate, scale to zero for MySQL, change bridges | Planned | Remaining integration and retrieval bridges |
The platform inventory covers these components alongside retrieval, Live, Durable and the agent platform. The roadmap names the remaining integration work.