When Snaplet shut down, u/snaplet/seed was handed to the community, and the fork hasn't had a real release since mid-2024 (open issues include an unpatched high-severity npm advisory and no Postgres 18 tracking). If you were relying on it to seed a Supabase project, the maintained options left are paid or enterprise.
I am building a free, open-source alternative that covers the core workflow. Point it at your connection string:
pip install "misata[db]"
misata seed postgresql://localhost/postgres
It reads your schema straight from the database (tables, columns, foreign keys), generates realistic connected data, inserts parents before children, then queries the database back to confirm every foreign key resolves and prints the result:
✓ orders.customer_id → customers.id — 0 orphan(s)
✓ Seeded 2,250 rows in 0.5s. Every foreign key resolves in the database.
Safe by default: it refuses to touch tables that already have rows unless you pass --truncate, --dry-run prints the full plan without writing, and --skip leaves app-managed tables (migrations, auth) alone. No codegen client to keep in sync with your schema.
One honest limitation: seeding child rows against rows that ALREADY exist in a table (append mode) isn't built yet, it seeds fresh. That's the next thing I'm working on. Also, if you use identity/serial PKs, it doesn't advance the sequence yet, so it's for dev databases, not something your app then writes to in place.
Would love feedback from anyone who was left stranded by the Snaplet shutdown.
Guide: https://misata.studio/docs/guides/seed-a-live-database
Repo: https://github.com/rasinmuhammed/misata
The user discusses the unmaintained state of Snaplet's seed tool and introduces a new, free CLI tool called Misata. This tool seeds Supabase/Postgres databases by reading the schema and verifying foreign keys without using production data. The user seeks feedback from those affected by Snaplet's shutdown.
Snaplet still works, and works well, though I'm not discouraging your efforts. You don't mention data anonymization. How do you prevent production PII from landing on a local dev machine?
Thank you for correcting me. I should have said "unmaintained" rather than implied it stopped working. The seed package still runs, you're right.
What made me write to worry about is narrower: no real release since mid-2024, and the community fork is currently carrying an open highseverity npm advisory with no one on the hook to patch it.
On anonymization, the reason I don't mention it is that Misata is a different category from Snaplet, and your question is the cleanest way to see the line.
Snaplet, Tonic, and Greenmask solve "I want a realistic copy of production without the PII". They pull your production data and transform it: mask, subset, format-preserving encryption. The PII risk you're asking about is real for that whole class of tool, because production data is genuinely in the pipeline and the entire job is scrubbing it safely on the way to the dev machine.
Misata never reads production at all. It generates data from scratch to fit your schema and constraints. So the direct answer to "how do you prevent production PII from landing on a dev machine" is: production is never in the loop. There is no prod row to leak, because none is ever read. The customer names, emails, and amounts are invented to satisfy the column types and the foreign keys, not derived from anything real.
That is a real advantage for some use cases and a real limitation for others, so I'll be straight about the tradeoff. Because it doesn't derive from prod, it will not reproduce your actual distributions, cardinalities, or the weird edge cases that only exist in real data. If your test genuinely needs production shape, a masked copy is the right tool and Misata is not. Where generation wins is when you want data with guaranteed referential integrity and, for testing specifically, a known correct answer: you declare "this month's revenue is exactly X" or "2% of these are fraud" and now you can assert your pipeline computed the right number, which a masked prod copy can't give you because you don't know prod's exact aggregates either.
There is an opt-in middle ground (misata mimic) that learns the distribution shape from a sample you hand it and emits new synthetic rows rather than copying them, but that's something you deliberately point at a file, not an automatic prod pull, so the clean-hands default stands: no production data unless you choose to involve it.