After Snaplet Seed: replacing seed.ts without writing another seed script

This is a practical answer to that. Not a feature pitch, just what seed.ts actually did, what is safe to keep, and how to replace the parts that are now frozen.

What actually happened to Snaplet Seed

Snaplet wound down its products in August 2024. The team joined Supabase, the tooling was open-sourced, and @snaplet/seed was handed to the community. The last release with real feature work was v0.98.0 on 30 July 2024. The fork still installs, but it has barely moved since, and "barely moved" is a problem for a tool that sits between your Prisma schema and your database on every CI run.

So the package is not gone. It is frozen. That distinction matters, because a frozen seed tool keeps working right up until a Prisma version bump, a Node upgrade, or a new column type quietly breaks it, usually on a Friday.

What seed.ts was doing for you

Snaplet Seed's value was createSeedClient. You described your data in TypeScript and it walked your Prisma schema to keep foreign keys valid:

import { createSeedClient } from "@snaplet/seed"

const seed = await createSeedClient()
await seed.users((x) => x(10, {
  posts: (x) => x(3),
}))

Ten users, three posts each, every post.authorId pointing at a real user.id. The schema awareness is the part worth protecting. The TypeScript seed script is the part worth reconsidering, because that file is also what rots: every schema change means editing seed.ts, and a 200-line seed script is its own little codebase to maintain.

Option 1, keep the fork

Defensible if your seed.ts is small, your stack is pinned, and you can absorb the maintenance yourself. You are betting that nothing in your toolchain moves faster than the community fork can follow. For a lot of teams that bet is fine for another six months and then quietly stops being fine.

Option 2, drop the seed script and generate from the schema

The alternative is to stop hand-writing the seed logic at all. Instead of a TypeScript file that describes rows, point a generator at the schema itself and let it produce foreign-key-consistent data directly. With SeedBase that is the schema plus a row count, no seed.ts:

• Import the Prisma schema (or SQL, or Django models).
• It reads the foreign-key graph and generates parents before children, so every reference resolves.
• Export SQL, CSV or JSON, or push straight to Postgres or MySQL.

The thing you keep from Snaplet, FK-correct data, you keep. The thing you were maintaining, seed.ts, you delete. That is the actual trade, and for most teams leaving an unmaintained tool, deleting code is the point.

If you were not on Prisma anyway

Snaplet Seed was Prisma and TypeScript first. A fair number of teams adopted it, then grew a service in Django or a schema they only have as raw SQL, and ended up maintaining a Prisma-shaped seed tool for a non-Prisma codebase. Migrating off Snaplet is a good moment to fix that: the same schema-driven approach works from a Django models.py or a plain CREATE TABLE dump, not just schema.prisma.

Keeping CI deterministic after the move

The one Snaplet behavior you do not want to lose is reproducibility. Seeded generation should be deterministic: the same seed value produces the same rows, so a failing CI run is debuggable instead of "works on the third retry." Pin the seed in your pipeline and the dataset is stable across runs and across machines.

FAQ

Is @snaplet/seed still usable in 2026?

It still installs, but the last feature release was v0.98.0 in July 2024 and it is community-maintained with little movement. It works until a dependency or schema change breaks it, with no maintainer on the hook to fix it quickly.

Do I have to rewrite my seed.ts to migrate?

No. The point of a schema-driven generator is that you do not port the seed script at all. You import the schema and generate from it, then delete seed.ts.

Can I replace Snaplet Seed without Prisma?

Yes. Schema-driven generation works from SQL dumps and Django models too, not only schema.prisma, which is useful if your stack outgrew Prisma.

Will the generated data keep foreign keys valid?

Yes. The generator orders inserts by the foreign-key graph, parents before children, so every reference resolves, the same guarantee createSeedClient gave you.