After Neosync: replacing synthetic data and anonymization in one place

This is a practical migration note, not a feature tour. If you ran Neosync in CI or in a staging refresh job, the useful question is which of its two jobs you actually relied on, because the answer changes what you replace it with.

What happened to Neosync

Neosync was acquired by Grow Therapy in September 2025. The open-source repository at nucleuscloud/neosync was archived on 30 August 2025, and the hosted cloud service is offline. Archived is more final than unmaintained: the repo is read-only, there are no further releases, and there is no maintainer to escalate a broken upgrade to. If it still runs in your pipeline today, it runs on borrowed time.

Neosync did two jobs, and that is the key

Most of the confusion around replacing Neosync comes from treating it as one thing. It was two:

• Synthetic data generation: schema-aware fake data from scratch, with foreign keys kept valid.
• Production-data anonymization: copy a real database, mask the PII, and ship the result to dev or staging.

A lot of the migration advice out there now hands you one tool for each, so you replace one dependency with two. Worth knowing before you start, because you can also cover both from a single schema.

Job 1, synthetic data generation

If you used Neosync to populate an empty database with realistic, relationship-correct rows, the replacement is schema-driven generation. Point a generator at your schema (SQL, Django models or a Prisma schema), and it walks the foreign-key graph to generate parents before children so every reference resolves. No prod access required, nothing sensitive in the dataset, deterministic per seed so a CI run is reproducible.

This is the same job Snaplet Seed did, if you were comparing the two. If you also used Snaplet, the Snaplet Seed migration note covers the generation side in more detail.

Job 2, anonymizing a real production database

The other half is the one people underestimate. When you need real-shaped data, you copy production and strip the PII. The replacement has to do two things at once: mask personally identifiable fields, and keep the database loadable, which means foreign keys and relationships have to survive the masking.

SeedBase handles this directly. It can mask PII in place and pull a referentially consistent subset of a real database, cut along the foreign-key graph, so the anonymized or smaller copy still loads and still behaves like the original. That is the production-anonymization half of what Neosync did. There is a fuller walkthrough in how to mask production data for staging and on the GDPR anonymization page.

One tool instead of two

The honest reason to mention both jobs is that the seeding-tool category fragmented in 2025: Snaplet wound down, Neosync was acquired and archived, and the common advice became "use one tool to generate and another to anonymize." SeedBase covers both sides from the same schema, so a Neosync migration does not have to mean adopting two replacements and wiring them together.

FAQ

Is Neosync still maintained?

No. Neosync was acquired by Grow Therapy in September 2025, the open-source repo at nucleuscloud/neosync was archived on 30 August 2025, and the hosted cloud is offline. An archived repo means no fixes, no releases and no maintainer to escalate to.

Do I need two tools to replace Neosync?

No. Neosync did two jobs, synthetic data generation and production-data anonymization, and a lot of migration advice now points you at one tool for each. SeedBase covers both from the same schema: generate foreign-key-consistent data from scratch, or mask and subset an existing database.

Can I anonymize a real production database, not just generate new data?

Yes. SeedBase can mask personally identifiable data in place and pull a referentially consistent subset of a real database, which is the production-anonymization half of what Neosync did, with foreign keys kept valid.

Will foreign keys stay valid after masking or subsetting?

Yes. Subsets are cut along the foreign-key graph so every reference still resolves, and masking preserves the relationships between rows. You get a smaller or anonymized database that still loads and behaves like the original.