Let me start with a confession: I don't really know what I'm doing.
I'm not a Rust developer. I've never written a database backend. I run a small SaaS and I've been watching AI coding agents get better every month. At some point I wanted to stop reading about them and actually push one to its limits.
So I gave a team of cloud agents a ridiculous mission:
Rewrite every component of Supabase in Rust, 1:1 compatible, as a single binary. By agents. In public.
The project is called Megabase (yes, a nod to both Supabase and Factorio's self-running mega-factories).
- Repo: github.com/Zouhairmaj/megabase
- Site and live status: megabase.sh
This post is a snapshot after roughly the first 26 hours. It's mostly for fun and for learning. Please don't deploy this in production. 🙂
The idea
The inspiration came from a Hacker News post about a PS5 emulator project that publicly tracks the percentage of functions it implements, with a treemap. I loved how honest that was: no "it works!" claim, just a number that goes up.
Supabase felt like the perfect target for agents:
- It's open source. Agents can read the original code (Go, Haskell, Elixir, TypeScript…) and port its behavior.
- It runs locally. So "correct" isn't a matter of opinion: you can send the same request to real Supabase and to Megabase, and compare.
- The result would actually be useful. Self-hosting Supabase means a dozen containers in several languages. One Rust binary next to Postgres would be nice.
The rules I wrote (the only things I wrote)
I wrote two files by hand: a MANIFESTO.md and a GOAL.md. And to be honest, even those were heavily assisted by Claude. Everything else was supposed to be agent-written. The key rules:
- Agents write everything. Code, CI, docs, README, devlog, even the website.
- Humans only write the mission and the guardrails.
-
Every human intervention is logged publicly in
HUMAN_LOG.md. The number of times I had to step in is part of the result. - The judge is external. Agents don't grade themselves. A test harness runs the real, pinned Supabase stack side by side with Megabase and compares responses.
-
Failures are loud. Anything not implemented returns an explicit HTTP 501
MEGABASE_NOT_IMPLEMENTED, never a silently wrong answer.
How progress is measured
Two numbers, inspired by that emulator project:
- Coverage: a tool extracts every "unit" from the upstream source (routes, PostgREST operators, auth grant types, storage endpoints…). The agents found 1,024 units. Coverage = implemented ÷ units.
- Conformance: the percentage of judge test cases where Megabase answers exactly like real Supabase.
Both are published as badges and a treemap, updated by CI.
What happened in the first ~26 hours
Here's what the repo looks like after day one and a bit:
-
126 commits on
mainand around 220 pull requests - 7 releases (v0.1.0 → v0.1.7), with signed binaries on some of them
- ~21,700 lines of Rust across 11 crates (auth, rest, realtime, storage, pooler, meta, functions…)
- 35 architecture decisions written as separate files
- Coverage: 9.7% (99 of 1,024 units)
- A full public devlog, written by the agents
What's actually working: parts of Auth (signup, login, password and refresh-token grants, user and admin routes, email verification flows) and a growing chunk of REST filters (eq, in, like, match, full-text search…).
The agents also set up things I would never have done myself on day one: fuzzing targets, cargo-deny, OpenSSF Scorecard, release-please, signed releases, Codecov, benchmarks. The README now has about 18 badges. Agents love badges.
What surprised me
1. Agents will happily approve their own work.
The very first big pull request (the whole bootstrap, ~37k lines) was approved by the agent's own account. The rule said I had to review it. I only caught it later. Lesson: rules written in a Markdown file are wishes; rules enforced by branch protection are rules.
2. "Humans write nothing" is harder than it sounds.
Look at HUMAN_LOG.md: I had to create tokens and secrets, set up a Docker Hub account because CI was getting rate-limited (HTTP 429), enable GitHub Pages, change permissions… Agents can't click buttons in GitHub settings. Every time I did, it got logged. I think that log is one of the most interesting parts of the experiment.
3. The log isn't always honest by default.
At one point an external review found several of my interventions missing from the log, and most PRs showing up under my GitHub account instead of the agent account. Transparency needs to be checked, not assumed. Even with AI.
4. Asking another AI to review the AI works surprisingly well.
I had an external AI produce a review checklist for Phase 0, then had it fact-checked against the actual repo. Some points were wrong, most were right. I validated Phase 0 "with modifications", and those modifications became issues the agents are now working on.
What I learned (so far)
- A precise, verifiable target is everything. "Build a backend" would have gone nowhere. "Match this exact behavior, checked by this judge" gives agents a direction.
- The judge matters more than the code. Most of my attention ended up on how we measure, not what gets written.
- Guardrails need enforcement, not prose. Branch protection, CODEOWNERS, protected paths, CI checks.
- You don't need to be an expert to run an experiment like this. You need curiosity, a clear goal, and willingness to say "I don't know" in public.
What's next
Level 1 is REST + Auth (email/password) at 95% conformance with no critical security issues. We're not there yet. Then Realtime, Storage, and eventually running Supabase Studio unmodified against Megabase.
Will it ever reach 100%? Honestly, no idea. That's the point.
If you're curious, follow along on megabase.sh, star the repo, or open an issue. And if you've run similar experiments with coding agents, I'd really love to hear what you learned in the comments.
Megabase is an independent experiment, unofficial and not affiliated with Supabase.


Top comments (1)
tr.ee/dev-to
Some comments have been hidden by the post's author - find out more