Centauri Migrate: an open-source attempt at Firestore-to-Postgres migrations

A few weeks ago, I set out to build an open-source tool to help with Firebase-to-Postgres migrations — small, humble, with real limits. I'm sharing it here in case it's useful to someone.

Centauri Migrate

github.com/KeymelGaston/centauri-migrate

A CLI that does two things most migration guides treat as an afterthought:

1. Infers a relational schema from your schemaless Firestore documents — deciding what becomes a table, what stays jsonb, and what relationships exist, based on real fan-out measured in your actual data.
2. Translates your Firestore Security Rules into candidate RLS policies (both Supabase and generic-Postgres dialects) — so you don't silently go from "properly locked down" to "wide open" the moment your data lands in a new table nobody remembered to protect. ## Where it actually stands right now

I want to be upfront about this, the same way the README is:

Status: early, working end-to-end, not yet battle-tested. Every command runs and is covered by tests (84 passing at the time of writing), including real integration tests against the Firestore emulator — but this hasn't been run against a large, real-world production dataset yet.

The full pipeline works — init → extract → infer → rules → review → migrate — and nothing gets applied silently. Every inferred column, relation, and RLS policy carries a confidence level. Anything below high gets surfaced in a review report before you'd ever touch a real database. Anything centauri rules can't confidently translate becomes an explicit deny, never a guessed permissive policy.

migrate defaults to dry-run. You have to explicitly pass --apply to touch anything real.

What it doesn't do yet

Also being upfront about this, because I'd rather you know before you try it than after:

• Not validated against a real, large Firestore project — only the emulator and hand-built test data so far.
• centauri rules has zero validation against real-world firestore.rules files — only against rules I wrote myself to cover patterns I could think of.
• No cutover/dual-write support — this covers initial extraction, inference, and import, not a live production migration with zero downtime. Full list is in the README.

What would actually help

If you have a Firestore project — even a side project, even a messy one — the single most useful thing you could do is run centauri extract + centauri infer against it (read-only, nothing gets written back) and tell me where the inferred schema looks wrong.

And if you're willing to share a real firestore.rules file (redacted however you need), that's the thing I can't get from writing my own test fixtures no matter how hard I try. That's the gap most likely to bite someone.

Issues are open. Feedback — especially the "this doesn't work for my case" kind — is exactly what I'm here for.

---

Built at 3am, still holding the morning coffee ☕