Neosync Is No Longer Maintained. Here's Where Your Postgres Data Tooling Goes Next

If you're searching for a Neosync alternative, you're not the only one. Neosync was acquired by Grow Therapy in September 2025 and the GitHub repo was archived on August 30, 2025. The cloud product is offline, the issue tracker is read-only, and the Hacker News thread noting the archival is where most of the public discussion lives now. If your team is still running Neosync — self-hosted or what's left of the cloud — you're on a dependency that has no maintainer. This guide walks through the two paths out, because Neosync did two different jobs and there isn't one tool that replaces both.

Key Takeaways#

• Neosync was acquired by Grow Therapy (a mental health platform) in September 2025; the open-source repo at nucleuscloud/neosync was archived on August 30, 2025, and the hosted cloud service is offline
• Neosync is the second major OSS test-data tool to shut down in twelve months — Snaplet went dark in August 2024 — so if you're migrating for the second time in a year, this is a category shift, not one unlucky tool
• Neosync did two different jobs — synthetic data generation (schema-aware, from scratch) and production-data anonymization (copy prod, mask PII, ship to dev/staging). A complete migration has to cover both or admit you're only replacing one side
• For the generation side, Seedfast is the closest functional match: PostgreSQL-native CLI, schema-aware, FK-valid output, plain-English scope, actively maintained
• For the anonymization side, Greenmask is the actively-maintained OSS option that does pg_dump-compatible masking of production data. Seedfast does not anonymize — generating from schema is a different workflow
• The migration is not one command because the product you're leaving wasn't one product. The rest of this guide walks through the generation path in detail and points at anonymization tooling for the other half

What actually happened to Neosync#

Neosync was a YC-backed open-source data privacy platform founded in 2023. It shipped two capabilities in one tool: anonymize-and-subset production data into safe dev/staging copies, and generate synthetic data from scratch against a schema. Both capabilities shared the same orchestration layer (a Temporal-based workflow engine) and the same connection / sync abstractions. That unification was the reason teams picked Neosync over picking two separate tools.

In September 2025, Grow Therapy — a $1B mental health platform — announced the acquisition. Grow wanted the data-privacy expertise for its internal HIPAA-scoped engineering rather than continuing Neosync as a product. The GitHub repo was archived on August 30, 2025 — ahead of the formal announcement — and the hosted cloud service was wound down. The repo is read-only; the README carries the disclaimer "Neosync has been acquired by Grow Therapy. As a result, this repository is no longer actively maintained."

That is the short version of the Neosync shut-down story. The longer version is that this is the second major developer-facing test-data tool to exit in twelve months — Snaplet shut its doors in August 2024 and its open-source continuation has barely moved since. Teams searching for a Neosync replacement today are often the same teams that picked Neosync as a Snaplet replacement last year. That pattern is the backdrop for the migration choices below.

That's where it sits as of April 2026. The code still compiles. Self-hosted instances still run. But there is no maintainer, no release cadence, no cloud fallback, and no roadmap. Pull requests sit. Issues accumulate. PostgreSQL 18 ships new features, Prisma 7 changes defaults, the Temporal SDK moves — and nothing on the Neosync side moves with them.

If you adopted Neosync between 2023 and 2025 because it was open source, YC-backed, and actively shipped, the tool you're running today is not the tool you chose. This article is the migration guide that wasn't published.

Two use cases, two migration paths#

Neosync's dual nature is the first thing to be honest about. The way out depends on which half you actually used.

Path A — you used Neosync for synthetic data generation. You were running Neosync jobs against a schema (often an empty Postgres, a Supabase project, or a Neon branch), describing the dataset you wanted, and getting realistic, FK-valid rows out. You never connected Neosync to a production database, or you did so only as a schema reference.

Path B — you used Neosync for anonymization / subsetting. You were running Neosync jobs that connected to a real production database, masked PII using transformers, subsetted the data (only the last 30 days, only customer X's rows), and shipped the masked copy to dev or staging. Compliance was part of the reason you picked the tool.

Path C — you used both. A subset of teams wired Neosync in for both jobs in different workflows. The migration is Path A plus Path B, not one unified move.

The rest of this article is primarily Path A, because Seedfast fits Path A exactly. For Path B, skip ahead to the anonymization section. For Path C, do Path A first with Seedfast — the generation side usually has tighter schedule pressure from CI pipelines — then plan Path B on its own timeline.

What a Neosync generation replacement has to cover#

Before swapping tools, it helps to be precise about what Neosync's generation side actually did. Seedfast needs to cover this same surface to be a functional drop-in.

Schema introspection. Neosync connected to your database, read the tables, columns, data types, and foreign key graph, and kept that schema in its workflow state.

Transformer library. Per-column value generators — around forty of them — covering email, full name, phone, address, postal code, UUID, custom JavaScript, plus an AI transformer for columns where semantic context (product descriptions, free-text notes) mattered. You picked a transformer per column and Neosync produced values matching that shape.

Foreign-key resolution. When a job produced orders, Neosync created the users and products that satisfied the FK constraints first, in topological order.

A jobs interface (UI + API). You configured sources, destinations, transformers, and subsetting rules in a web UI. The API underneath was a gRPC/Connect surface. Jobs ran as Temporal workflows — durable, retryable, observable.

A CI story. Teams running Neosync in CI typically triggered a job run via the API after the migration step, then waited on completion.

Seedfast covers schema introspection, FK resolution, per-column value generation, and a scriptable interface through a single CLI command. It does not cover Temporal workflows or production-database sync — those are anonymization concerns and belong on the other side of the split.

Seedfast: the generation side, in a different shape#

Seedfast is an AI-powered CLI for PostgreSQL that reads your live schema on every run and generates FK-valid data from a plain-English scope. The functional overlap with Neosync's generation side is direct; the interface is different.

# Install (Homebrew or npm)
brew install argon-it/tap/seedfast
# or: npm install -g seedfast

# Authenticate and point it at your database
seedfast login
seedfast connect

# Generate data
seedfast seed --scope "5 workspaces, 20 users across them, 200 documents with realistic revision history"

There's no web UI to configure. No per-column transformer selection. No Temporal workflow to wait on. The scope is a plain-English sentence. Seedfast reads the schema, infers semantic intent (workspaces, users, documents — each column's meaning follows from the schema), and generates rows that fit the constraints and the domain.

The mechanism is different from Neosync's. Neosync relied on a large library of named transformers plus optional custom-JS transformers to generate each column's values independently. Seedfast uses AI as the primary planner: one model plans the dataset from the scope, generates values that cohere across columns (an e-commerce electronics store produces electronics product names, electronics-appropriate prices, electronics reviewers), then writes in topological FK order. The trade-off is determinism: Neosync with seeded transformers could produce the same dataset on the same input; Seedfast generates fresh on each run. Teams that need repeatable datasets for e2e baselines typically run once and pg_dump the result, then restore in CI.

The other trade-off is that Seedfast is a CLI with a scope-string interface. Teams that liked Neosync's web UI for configuring transformers per column give something up on control granularity. What they get in return is zero configuration files, zero codegen, zero workflow-engine dependency. One command against a live schema. Seedfast has a free tier that covers a full migration spike — install, connect, run one seed.

If you used Neosync for anonymization#

Before swapping one anonymizer for another, it's worth asking whether the anonymization pipeline itself is still the right shape. Most teams picked Neosync's anonymization side for one reason: PII rows cannot land in dev. Seedfast's generate-from-schema approach removes the need for a masking step on the dev-refresh path — no production database connection in the seeding path, no masking pipeline to maintain, no "is this dump safe to ship" review before every environment refresh. If your real requirement is "dev and staging data that looks and behaves like production without the PII exposure," generation-only retires the anonymization workflow for that use case — one less production credential to rotate, one less PII catalog to keep in sync with schema changes.

If your requirement is stricter — specific production rows for a bug repro, real distributions for a performance test, regulated-industry auditors asking for masked prod-derived data — you need an active anonymizer. The realistic migration paths:

Greenmask (greenmask.io). The most active OSS PostgreSQL anonymizer as of early 2026 — the 0.2.x line has been shipping on a regular cadence and the project maintains a visible presence in the PostgreSQL ecosystem. Check its GitHub releases for the latest version. Replaces pg_dump with a masked version: connect to prod, specify transformers per column, output a sanitized dump that loads into dev/staging. The workflow is different from Neosync's Temporal-driven sync — it's dump-based rather than continuous — but the job it does is the closest OSS equivalent. Covers most Neosync anonymization use cases without an enterprise contract.

Tonic Structural. Tonic's enterprise anonymization product. Copies production data, masks PII using generators, subsets, and provisions sanitized environments. The April 2026 Structural Agent launch made this faster to configure — Claude-powered, scans for PII, proposes masking generators in one click. Different pricing model than Neosync (enterprise contract, not open source). Appropriate for teams already operating under enterprise procurement and regulatory scope.

PostgreSQL Anonymizer (pg_anonymizer) 2.0. A Postgres extension, not a standalone tool. Masks data in-database via view rewriting or column-level rules. Good for teams that want masking without an external job orchestrator. Limited to Postgres and requires database superuser access to install.

Basecut (basecut.dev). Subsetting plus anonymization, CLI-first, PostgreSQL-only. Positioned as a Snaplet successor on the anonymization side. Small team, freemium, active.

Pick based on deployment shape. Fully OSS with an active maintainer and no cloud dependency: Greenmask. Already in an enterprise procurement lane: Tonic Structural. Want the masking in the database itself: pg_anonymizer. Want a hosted CLI with a free tier: Basecut.

None of those tools also generate synthetic data from scratch at the quality level Neosync did. If you need both, you are running two tools now — that's the honest picture. For the generation side of that pair, Seedfast fills the slot and pairs cleanly with any of the anonymization tools above through the same Postgres connection.

Neosync alternative compared: Seedfast side-by-side#

The rows that matter depend on what you originally liked about Neosync. If it was the web UI and per-column transformer library, Seedfast's scope-string interface is a real change — less granular control, less point-and-click. If it was the "tool reads my schema and produces FK-valid data" property, Seedfast is a direct match with a lighter surface area.

How to migrate off Neosync (generation side)#

A typical Neosync-to-Seedfast generation migration takes an afternoon. Here are the concrete steps.

Step 1. Catalog what your Neosync jobs generated#

Open the Neosync UI (if your self-host still runs) or the job definitions you have in version control. For each generation job, write down the scenarios in plain English:

• 3 workspaces, each with 5-10 members mixing admin / editor / viewer roles
• 50 products across 5 categories with realistic prices and inventory counts
• 200 orders, average 2 line items each, spread over the last 6 months
• One test admin user with a known email for Playwright login

This list becomes your Seedfast scopes. The flatter the list, the closer your Neosync job is to something a single --scope string can express. If you had deeply nested job compositions in Neosync, you will end up with multiple scope calls in Seedfast, one per logical dataset.

Step 2. Handle table state separately#

Neosync's jobs typically included a truncate-target step. Seedfast does not truncate automatically — it writes into whatever state the database is in. Decide where that step lives:

# Simple truncate before seeding
psql "$DATABASE_URL" -c "TRUNCATE workspaces, users, products, orders RESTART IDENTITY CASCADE;"

# Or recreate schema (CI / ephemeral databases)
npx prisma migrate reset --force
# (Seed script behaviour is controlled by the `prisma.seed` entry in package.json —
#  remove that entry in the CI environment if you want `migrate reset` to skip seeding)

This is one line in a Makefile or a CI step. It isn't a Seedfast limitation; it's a separation of concerns — the seeder generates, the migration tool handles schema state.

Step 3. Take down Neosync#

Self-hosted Kubernetes deployment:

# Stop the Neosync stack
kubectl delete -f neosync/
helm uninstall neosync -n neosync
kubectl delete namespace neosync

# Remove Temporal if it was dedicated to Neosync
helm uninstall temporal -n temporal

Docker Compose deployment:

cd neosync/
docker compose down --volumes
cd ..
rm -rf neosync/

If you configured Neosync jobs via API calls in CI, note them — Step 5 replaces them.

Step 4. Install and connect Seedfast#

# Homebrew (macOS/Linux)
brew install argon-it/tap/seedfast

# Or npm (all platforms)
npm install -g seedfast

seedfast login      # authenticate once per machine
seedfast connect    # paste your Postgres connection string

Seedfast reads the schema from whatever database you connect to. Credentials live in the OS keychain; no per-project config file. The getting started guide covers the first-run walkthrough.

Step 5. Replace the Neosync job with a Seedfast scope#

Where your Neosync job definition (via UI or API) produced:

Workspaces: 3
Users: 20 (distributed across workspaces, 2 admins per workspace)
Products: 50 (5 categories, price range 10-500)
Orders: 200 (2-5 line items each, past 6 months)

The Seedfast equivalent is one command:

seedfast seed --scope "3 workspaces. 20 users distributed across them, 2 admins per workspace and the rest mixed editor/viewer. 50 products in 5 categories with prices between 10 and 500. 200 orders, each with 2-5 line items, spread over the last 6 months."

For CI runs, exporting SEEDFAST_API_KEY puts the CLI into non-interactive mode — the command runs against the provided scope and exits. For interactive runs on a local machine, Seedfast prints a plan summary and waits for confirmation before writing; step through that the first time to sanity-check the dataset shape.

For prescriptive fixtures — the one known admin user with a literal email that your Playwright login step references — keep those in a short fixtures.sql and run it after Seedfast:

# One command in your CI step, after migrations
seedfast seed --scope "..." --output json
psql "$DATABASE_URL" -f fixtures.sql

Seedfast fills the bulk relational data; the fixture file pins the specific rows your tests expect by literal value. The two layers don't conflict because Seedfast writes through the same Postgres connection.

Step 6. Rewire CI#

Where your Neosync pipeline looked something like:

- name: Trigger Neosync job
  run: |
    neosync jobs trigger "$NEOSYNC_JOB_ID"
    # Poll the Connect API until the run completes — no built-in wait subcommand
    until curl -s -H "Authorization: Bearer $NEOSYNC_API_TOKEN" \
      "$NEOSYNC_API_URL/mgmt.v1alpha1.JobService/GetJobRun" \
      -d "{\"jobId\":\"$NEOSYNC_JOB_ID\"}" | grep -q '"status":"COMPLETE"'; do
      sleep 5
    done
  env:
    NEOSYNC_API_TOKEN: ${{ secrets.NEOSYNC_API_TOKEN }}
    NEOSYNC_API_URL: ${{ secrets.NEOSYNC_API_URL }}

The Seedfast equivalent:

- name: Seed database
  run: npx seedfast seed --scope "e2e baseline: 3 workspaces, 20 users, 200 orders" --output json
  env:
    SEEDFAST_API_KEY: ${{ secrets.SEEDFAST_API_KEY }}
    SEEDFAST_DSN: ${{ secrets.DATABASE_URL }}

The SEEDFAST_API_KEY environment variable puts the CLI into non-interactive mode, so there is no confirmation prompt to suppress and no completion polling to script — the command exits zero on success and non-zero on failure. --output json gives machine-readable output for pipeline validation. The full CI/CD database seeding docs cover GitHub Actions, GitLab CI, and preview-branch workflows.

Step 7. Verify#

Run your integration tests against the new dataset. The shape of data Seedfast produces is similar in intent to what Neosync produced (valid, connected, schema-respecting) but exact values differ. Tests that hard-coded specific literals — a Neosync-generated email like alice.martin@example.com that happened to be deterministic — need to be updated to query whatever the seed produced rather than assume specific literals. This is usually a one-time fix that surfaces brittle tests worth cleaning up.

What you gain and what you trade#

Being honest about trade-offs makes the migration predictable. The gains come first because they're the reason the switch is worth doing.

You gain low-maintenance schema awareness. No config file to keep in sync, no per-column transformer to update when a migration lands, no workflow to redeploy. Seedfast reads the live schema on each run — the next migration picks itself up automatically.

You gain domain-aware value generation. Where Neosync transformers generated each column independently, Seedfast plans the dataset as a whole — electronics schemas get electronics product names and electronics-appropriate reviewer personas. For demos and staging, the difference shows up on the first run.

You gain an actively maintained dependency. When Postgres 18 ships new features, when Prisma 7 changes defaults, when Supabase moves schemas — those fixes land. This was the implicit contract you had with 2023-era Neosync, and it's the contract that disappeared when the repo was archived in August 2025.

You gain MCP integration. If your team uses Claude Code, Claude Desktop, or any other MCP-aware AI assistant, Seedfast ships an MCP server that lets the assistant seed databases inside the conversation. The MCP setup guide covers the config. Neosync never shipped this.

You trade the Neosync web UI. Per-column transformer selection, live job status dashboards, the jobs page — none of that survives the move. If your team used the UI as the primary configuration surface, Seedfast's CLI-only approach is a real change in shape.

You trade Temporal-backed durability. Neosync jobs were retryable, observable, and survived worker restarts. Seedfast is a CLI process — it runs, completes, and exits. For most generation workflows this is fine (the scope is small enough to complete in one shot), but teams that relied on long-running workflow semantics give that up.

You trade default determinism for fresh generation on each run. Teams that need repeatable CI datasets run Seedfast once, pg_dump the result, and restore from that dump in CI — the same pattern used with every schema-aware generator. It's an extra step, not a blocker.

You trade MongoDB reach. Neosync's MongoDB support targeted document-store anonymization and sync; Seedfast is PostgreSQL-first and does not seed MongoDB. Most Path A (generation) teams ran Neosync against Postgres schemas and will not notice, but if MongoDB was in scope for your workflow, that use case is not covered today.

You don't gain anonymization. This is the honest limit — if you're only reading this for the generation half, Seedfast handles it. If you need anonymization too, pair Seedfast with Greenmask, Tonic Structural, or pg_anonymizer per the section above.

Frequently asked questions#

Is Neosync actually dead, or could it come back?#

The GitHub repo is marked "no longer under active development" and the hosted cloud is offline. Grow Therapy acquired the team for internal use, not as a product company. A community fork could theoretically form, as happened with Snaplet's handover to the Supabase community, but as of April 2026 there is no such announcement. Treating Neosync as a dormant dependency is the safe read.

Can I keep running self-hosted Neosync and just not migrate?#

Yes, for now. The code still compiles, self-hosted instances still run. The risk is a moving target: PostgreSQL 18, Temporal SDK changes, Supabase platform updates, new Prisma versions. When a bug appears that needs a real fix, "wait for a maintainer" is the answer and there is no maintainer. Teams with SLAs, frequent schema changes, or upstream version sensitivity usually find this ceiling low.

Does Seedfast work for my stack (Prisma / Drizzle / Supabase / Neon / RDS)?#

Yes. Seedfast talks to PostgreSQL directly over the wire, so any Postgres-compatible database works — Neon (including branch-per-PR workflows), Supabase (including the hosted auth.users table), AWS RDS, Google Cloud SQL, Azure Postgres, self-hosted Postgres, Railway, Render, and the rest. It is ORM-agnostic — it doesn't care whether Prisma, Drizzle, Kysely, or raw pg manages the schema.

I used Neosync for synthetic data AND anonymization. What's the full migration picture?#

You are running two tools now. Seedfast handles the generation half. For the anonymization half, the closest active OSS replacement is Greenmask (pg_dump-compatible masking); the enterprise path is Tonic Structural; the in-database path is pg_anonymizer. The anonymization section walks through the choices. This is structurally honest — no single tool in the current market covers both halves as cleanly as Neosync did.

Is Seedfast open source like Neosync was?#

Not in the same way. The Seedfast CLI is distributed as a binary (Homebrew / npm). The planning step — where AI generates the data plan from your scope — runs server-side. Teams with strict air-gap requirements should evaluate this carefully; teams on normal internet connections will not notice the difference. The data handling and privacy docs cover exactly what crosses the wire.

Does Seedfast work with my existing fixtures.sql for known test users?#

Yes, and most teams keep them. Seedfast fills the bulk relational data your tests browse through; your fixture file pins the specific records your tests reference by literal value (the admin@example.com Playwright uses, feature flags keyed by key, country-code lookup rows). Run Seedfast first for volume, then the fixture file for specifics — they share the same Postgres connection and do not conflict.

How long does the migration actually take?#

For a team that used Neosync only for generation, with under 500 lines of job configuration, the migration is typically an afternoon. Cataloguing scenarios (Step 1) is usually the longest part — writing down in plain English what the Neosync jobs were doing. The swap itself (Steps 3-6) is maybe two hours. For teams that also used anonymization, add a separate track for evaluating Greenmask or Tonic Structural.

Migrate in one command (the generation half)#

If your Neosync jobs were only generating synthetic data, the move to Seedfast is the kind of migration that finishes in an afternoon: uninstall Neosync, install Seedfast, rewrite the job as a scope string, update one CI step. There's no workflow engine to redeploy, no UI to reconfigure, no config file to keep in sync. Get started with Seedfast on any Neon, Supabase, RDS, or self-hosted Postgres connection. Free tier covers the full migration spike.

If you also used Neosync for anonymization, that's a separate evaluation — Greenmask is the closest active OSS match and the section above covers the alternatives.

Related guides#

• Snaplet Seed alternative — the migration guide for the other shut-down-in-the-same-era tool; same pattern, different product scope
• Data seeding tools: the full comparison — category-level breakdown of DIY scripts, web generators, enterprise anonymization, and schema-aware generators
• Seed file maintenance — why hand-written seed.ts and seed.sql drift from the schema, and what that drift costs
• Database seeding in CI/CD — the operational patterns for idempotent, FK-valid seeding in pipelines
• Get started with Seedfast — install, connect to Postgres, run your first schema-aware seed