On this page
Evaluation This post reports a design proposal and a spike. Nothing here is a product yet, and we are not promising either engine as one.
Loam's retrieval engine is deliberately not an OLTP database. It keeps object storage as its only source of truth, which makes every commit an S3 PUT plus a metastore commit. That is fine for ingest and search and wrong for an application's UPDATE … WHERE id = $1 in a tight loop. Loam Live covers application data with its own reactive API on TiKV (part 3).
But many applications, including the open-source ones we want to run on Loam ourselves, need Postgres or MySQL as such: interactive multi-statement transactions, SELECT … FOR UPDATE, sequences, JSONB, arrays, ORMs that inspect the catalog. Writing a Postgres-compatible OLTP engine over TiKV would be years of work. So we asked a narrower question: can Postgres and MySQL engines that already keep their storage in object storage run beside Loam, on the same bucket, with Loam around them? This post covers three things: what Loam itself will serve over the Postgres wire, what we found with Neon, and what we found with WeSQL.
What Loam serves itself: Postgres wire over collections
The first piece is Loam's own. A planned Postgres listener, built on datafusion-postgres, lets psql, psycopg, node-postgres and BI tools query collections: the database name is the namespace, and the search table functions work from SQL. It starts read-only, then accepts single-statement autocommit writes (INSERT … ON CONFLICT, UPDATE and DELETE through Loam's filter writes, COPY FROM STDIN through the bulk path) behind a flag. It is analytical and ingest access, not OLTP. Planned
The idea: engines beside Loam, on one bucket
The rules, whichever engine it is: neither engine is linked into the Loam binary; each runs unmodified as a separate service; Loam talks to it only over its admin API and its wire protocol. That matters most for WeSQL, which is GPL-2.0-only, but it keeps the boundary clean for both.
Neon: under evaluation
Neon (Apache-2.0) separates Postgres into a stateless compute, a Paxos-replicated WAL service (safekeepers), and a pageserver that stores page versions as layers in object storage and serves them to computes. Because storage is versioned, a branch is a new timeline whose ancestor is an existing one at some point in its WAL: copy-on-write, no data copied. The deep dive goes further into the architecture.
What the spike showed
We ran Neon's storage services (one pageserver, one safekeeper, the storage broker) on a RustFS bucket, drove them through the pageserver API by hand the way Loam would as the control plane, and started computes against explicit tenants and timelines.
| Check | Result |
|---|---|
| Neon's compose stack with RustFS in place of MinIO | Worked, after three small changes (a SigV4 header RustFS requires, a named volume, a replacement compute entrypoint) |
| Compute up, psql connected | About 3 s; PostgreSQL 16.9 with wal_level = logical |
| Create a branch through the pageserver API | 36 ms; a second compute attached in seconds |
| Branch isolation | Confirmed both ways, across inserts, deletes, updates and DDL on each side |
| pgoutput logical replication | Insert, update and delete messages decoded; the replication slot survived replacing the compute with a fresh container |
| OpenFGA's migrations and a permission check | Passed |
| GlitchTip's migrations | All 169 passed, 219 tables |
| Wipe the pageserver's local disk and re-attach | Both timelines came back from the bucket with every row intact |
Technically, Neon did what we hoped. Its disks behaved as caches, the bucket held the truth (apart from the safekeepers' recent WAL window, which production runs as three replicas), and branching was fast and isolated.
Why it is not a product decision yet
The risk is maintenance, not function:
- The public repository has been nearly inactive since August 2025, after the Databricks acquisition. Commits went from over a hundred a month to about one. The last public releases and images are from July and August 2025.
- Its Postgres is 16.9 and 17.5, both from May 2025, carried as patched forks. Security releases since then are not in it. Rebasing Neon's patches onto newer Postgres minors is specialist work that Loam would own.
- The control plane is closed. Projects, endpoints and the proxy's authentication API were never open source. Loam would be the control plane: it would create tenants and timelines, write compute specs and start computes itself. The storage controller (needed for pageserver failover) and the proxy (needed for scale-to-zero) were not exercised in the spike.
So the proposal pins Neon by image digest, forks only when a fix is needed, and keeps plain Postgres as a working exit: every Loam code path addresses "a Postgres backend", so vanilla Postgres can replace Neon without changing anything except branching. The current direction is to run the open-source apps we host on plain Postgres 17 first, and to design a Loam-maintained Neon fork, with Loam as its control plane, as a separate track. That design is not published yet, and nothing about it is a commitment.
What Loam would add around it
- Routing by database name. A Postgres client sends its startup message, with the database name, before the server speaks (a TLS client sends
SSLRequestfirst and the startup message inside TLS). Loam's listener would read it, terminating TLS if the client asked for it: a mapped name is relayed to the right branch's compute over a separate backend connection (itself TLS), with SCRAM running end-to-end; any other name goes to Loam's own analytics. - A branch per agent workspace. Agent workspaces already get Git branches and copy-on-write environments in Loam's design. A Neon branch per workspace would give each agent its own writable copy of the database in milliseconds, created and removed as a Resonate saga with deterministic ids and compensation. Branches are never merged: Neon and Postgres cannot merge data, so a workspace's result reaches
mainas migrations, not as data. - Change bridges into search. pgoutput logical replication from each database into a collection's stream, with an idempotent producer keyed by the commit LSN, and the LSN confirmed back only after Loam acknowledges the append. Exactly once, the same contract as the Live bridge.
WeSQL: evaluated, not adopted
WeSQL is a MySQL 8.0 distribution that stores its data, binlog and WAL in object storage. It is GPL-2.0-only, inherited from MySQL, and it has no releases; its README recommends it for development and testing. We ran it on RustFS too.
| Check | Result |
|---|---|
| Start on RustFS | Worked once RustFS was configured for virtual-hosted-style bucket URLs, which WeSQL's S3 client always uses |
| Basic SQL | DDL, DML, JSON, SELECT … FOR UPDATE, commit and rollback worked; ENGINE=InnoDB is silently rewritten to its own engine |
| Forgejo's migrations | Failed at the first table with a foreign key: its storage engine does not support foreign-key constraints |
| Crash without the local volume | Committed rows written after the last object-store snapshot were lost, although their binlog slices had been archived to the bucket. Recovery restored the snapshot and did not replay the binlog. It may be a configuration issue; with the image's defaults, recent commits live only on the local disk |
The project also removed its multi-replica Raft mode in August 2026, after more than a year without commits. We are not adopting WeSQL. It stays a development compose file, and it would only be reconsidered if archive recovery is shown to replay the bucket's binlog and a real application's schema runs on it.
MySQL, then. An earlier approved path ran MySQL through unmodified TiDB in its own TiKV keyspace; a spike showed a keyspace-mode TiDB and a Rust client sharing one cluster without seeing each other's data, and the dev playground can run it. The owner has since steered transactional storage toward TiKV only, so the MySQL story is open again. We will write about it when it is decided.
Where this stands
| Part | Status |
|---|---|
| Postgres wire over collections: read-only, then autocommit writes | Planned |
| Neon beside Loam: control client, metastore records, routing, logical-replication bridge, branch-per-workspace saga | Under evaluation |
| WeSQL | Not adopted |
| MySQL access | Open |
The spike's compose files for Neon and WeSQL on RustFS are part of the design pull request in the engine repository, for anyone who wants to reproduce it. The last post in this series covers how the whole stack deploys, and where open source ends and the managed cloud begins.