Search for "Firestore to Postgres migration tool" and you'll find the same pattern over and over: a repo with good intentions, some initial traction, then silence. This isn't bad luck. It's a structural pattern, and it's worth understanding why before anyone tries to fix it.
The graveyard
Let's start with the facts. Here are the real attempts that exist, or existed, to tackle this problem:
| Tool | Peak traction | Status today |
|---|---|---|
fireway |
282 ⭐ / 47 forks | Archived by its own maintainer |
mad-migration |
~30 ⭐ | Frozen since 2020 |
pydantic-firestore |
0 ⭐ | Confirmed inactive |
FireSync |
brand new | v0.1.x, too early to tell |
fireway is the most illustrative case. A Firestore schema migration CLI, inspired by Flyway, with real traction — 282 stars and 47 forks don't happen by accident. Throughout 2022 and 2023, real users actively asked whether the project was still alive. Eventually, the maintainer himself answered honestly:
"This repo is unmaintained. I'll archive it for clarity."
The community didn't fully give up — at least two forks emerged to keep it going — but the original project, the one with the most traction, was abandoned by its own creator.
mad-migration tried to solve migrations between different database types. Its last documented activity dates to 2020: issues asking for column indexing support when migrating to MongoDB, extra-table support via YAML, async drivers. None resolved since.
pydantic-firestore showed up more recently and is already confirmed as inactively maintained, with zero stars on GitHub.
FireSync is the newest and most ambitious attempt — it brings a Terraform-style workflow (pull → plan → apply) for managing indexes and TTL policies with version control. But it's still at version 0.1.x. Too early to know if it'll meet the same fate as its predecessors.
None of these projects failed for lack of technical skill. fireway solved the problem reasonably well for a lot of people. The underlying pattern is something else entirely.
Why the pattern repeats
🔁 It's a one-time event, not a recurring one. A company migrates from Firestore to Postgres once in the life of its project. It doesn't need to do it again. That breaks the recurring-revenue model that sustains most software — and it breaks the maintainer's own motivation too: they wrote the tool because they were migrating, solved their own problem, and never had a second case to keep polishing it for.
🔒 Nobody trusts production data to a black box. One real company (Traba, an industrial staffing platform) publicly documented its own migration:
A full year of work. A team of roughly 12 engineers. Built entirely from scratch — trigger-based replication, per-collection reconciliation scripts, retry logic for referential integrity, a complete rollback plan.
They didn't use any external tool. The risk of getting production data wrong was too high to trust to some unknown GitHub project.
🧠 The hardest step resists automation. Deciding whether a nested field belongs in a separate table or stays as jsonb isn't a purely technical call — it depends on how that data will be queried down the line, something only someone with business context can judge well. Supabase's own community discussion on this exact kind of migration explicitly recommends against over-normalizing upfront. That's a judgment call, not an algorithm.
🧩 The market is fragmented by technology. Firestore→Postgres, MongoDB→Postgres, DynamoDB→Postgres are, in practice, distinct problems with different SDKs and data models. None is big enough on its own to sustain a robust tool, while a generic "any NoSQL to any SQL" migrator is a far more ambitious project than any solo maintainer can sustain in their spare time.
🏢 The platforms that own the data have no incentive to solve it. Neither Firebase nor Supabase builds a complete migration tool — and that's not negligence, it's design. Firebase/Google is stable enough that most users never need to leave. Supabase invests in securing whoever already arrived (RLS enabled by default on new tables, for instance) but not in translating what someone brings over from Firestore — that only benefits someone leaving the competitor.
💸 And the consultancies that solve it well have no incentive to automate themselves. Certified AWS consultancies offer Firebase-to-Supabase migrations as a packaged service. Agencies specializing in MongoDB→Postgres report 30+ projects delivered, priced in the thousands of dollars each. They all sell engineer-hours doing the work by hand. Automating that process would cannibalize their own high-margin business.
The pattern repeats beyond Firestore
This isn't exclusive to Firestore. One engineer described helping 34 different companies migrate from MongoDB to PostgreSQL over 8 years, always describing the same sequence: initial excitement about being "web scale," then slow queries, then an unsustainable bill, then finally the migration. Documented cases include companies that spent $60,000 with full senior engineering teams. On the DynamoDB side, some companies migrated there to save money and ended up spending $200,000 learning architecture lessons before finding the right access pattern.
The root cause is always the same: NoSQL databases are designed around the initial use case's queries, but the business changes over time, and the way you interact with the database becomes unmanageable. It's what happens when development speed is chosen over relational structure early on, and the business matures faster than the schema.
What actually changed recently
There's one piece that didn't exist just a couple of years ago, and it might explain why this problem could finally get a sustainable solution: reasonably good, cheap LLMs. The most serious attempts at solving schema inference with AI help (instead of fixed rules or training a model from scratch) only started appearing in 2025-2026 — the first tools capable of reasoning with something resembling judgment about ambiguous field names, types, and implicit relationships, without needing a training dataset or years of hand-written rules.
That alone doesn't solve the incentive problem — but it does solve the technical piece that was missing before.
The uncomfortable conclusion
This isn't a market gap nobody noticed. Talented people noticed it, more than once. The gap stays open because the combination of factors surrounding it — one-time event, no platform incentive, need for trust, need for human judgment, fragmented market — makes it genuinely hard to turn into a sustainable product, not just a script that works once.
That doesn't mean it isn't worth trying. It means whoever tries should start knowing exactly why the previous attempts didn't survive, instead of finding out the hard way, a year in, with an archived repo and an "I don't have time to maintain this anymore" message.
Have you had to migrate from Firestore (or any NoSQL database) into a relational world? I'd genuinely like to hear how you handled it — by hand, with one of these tools, or by paying someone else to do it.
Built in one afternoon, still holding the morning coffee ☕
Top comments (0)