SeedBase, a maintained Snaplet Seed alternative

What Snaplet Seed got right

• Schema-aware seeding: it inferred values from your tables instead of making you define every field.
• Foreign-key-aware, so related rows lined up across tables.
• Code-first in the Prisma/TypeScript workflow: a seed script that lived in your repo, type-safe and deterministic.

If you used it, you already understand the value of generating data from a schema. The problem is no longer the idea, it is that the tool is no longer maintained.

How @snaplet/seed and createSeedClient worked

Snaplet Seed shipped as the @snaplet/seed npm package. You ran npx @snaplet/seed init, it introspected your Prisma or PostgreSQL schema, and you wrote a seed script around createSeedClient():

// seed.ts, the @snaplet/seed pattern
import { createSeedClient } from "@snaplet/seed";

const seed = await createSeedClient();
await seed.$resetDatabase();

// 10 users, each with 3 posts, foreign keys wired
await seed.users((x) => x(10, {
  posts: (x) => x(3),
}));

The appeal was real: data shaped by your schema, relations wired automatically, deterministic when you passed a seed. The catch in 2026 is the dependency itself. The createSeedClient introspection has not tracked new Prisma or Postgres features since the project stopped moving, and there is nobody to file a bug with. SeedBase keeps the schema-first idea and puts a maintained tool behind it.

Is Snaplet Seed still maintained?

No, not in any practical sense. Snaplet the company shut down its hosted services on 31 August 2024 and open-sourced its tooling. The Snaplet Seed fork has had no meaningful release since v0.98.0 (July 2024). It still works for some teams (Supabase references it in places), but you are building on an abandoned dependency: no fixes for new database features, no support, and a workflow that stays narrow to Prisma and TypeScript.

Snaplet Seed vs SeedBase: where they differ

Snaplet Seed migration guide: replace @snaplet/seed step by step

You keep the part that mattered, schema-driven and foreign-key-correct data, and drop the unmaintained dependency. This Snaplet Seed migration guide is short because SeedBase reads the schema you already have, so you replace @snaplet/seed without touching your tables.

1. Remove the dead dependency. Run npm remove @snaplet/seed and delete the generated seed client. Your schema.prisma stays exactly as it is and remains the source of truth.
2. Create a project from your schema. Import schema.prisma (or a SQL dump, Django models.py, or a live database URL) at seedbase.dev. SeedBase reads the tables, columns and relations and builds the generation blueprint.
3. Grab an API key. One free key under Settings, API keys (it looks like dr_sk_...). Put it in the SEEDBASE_TOKEN environment variable.
4. Wire the seed step. Replace the old createSeedClient script with the SeedBase Prisma seed below, or generate a SQL file and load it. The prisma db seed entry point stays the same.
5. Pin a seed for reproducibility. Pass seed: 42 so every run, local or CI, produces the same rows. SeedBase is deterministic by seed, the same guarantee Snaplet Seed gave you.

Seeding a Prisma database after Snaplet: the createSeedClient replacement

This is the closest one-to-one replacement for the old workflow and the direct createSeedClient replacement: a code-first seed script in your repository, run through prisma db seed. Your migrations still own the schema, SeedBase only fills it.

// prisma/seed.ts
import { PrismaClient } from "@prisma/client";
import { SeedbaseClient } from "@seedbase/client";
import { seedPrisma } from "@seedbase/client/prisma";

const prisma = new PrismaClient();
const client = new SeedbaseClient({ token: process.env.SEEDBASE_TOKEN });

// FK-consistent rows, inserted in dependency order
await seedPrisma(prisma, client, {
  project: process.env.SEEDBASE_PROJECT,
  seed: 42,
});

Want the rows in memory for a test fixture or factory instead of a direct insert? seededRows returns them keyed by table, already in foreign-key-safe order:

const rows = await client.seededRows(projectId, { seed: 42, rows: 100 });
// { users: [...], posts: [...], comments: [...] }

The full Prisma path, including the runnable offline demo, is on the Prisma test data page.

Beyond Prisma: Django models and raw SQL

Snaplet Seed stayed inside the Prisma and TypeScript world. SeedBase reads the same kind of schema from three more starting points, so a mixed-stack team shares one tool:

• Django: point it at models.py or a live database and pull rows into a pytest fixture. See Django test data.
• Raw SQL: feed a CREATE TABLE dump from PostgreSQL or MySQL and export INSERT statements. See SQL test data.
• A live database: connect a read-only URL and SeedBase introspects it the way createSeedClient used to, then generates against the real shape.

Deterministic seed data in CI

The reason teams pinned a seed in Snaplet Seed was repeatable CI: same input, same database, every run. SeedBase keeps that contract. Generate a SQL file in a pipeline step and load it before the test suite:

// seed-sql.mjs, run in CI
import { SeedbaseClient } from "@seedbase/client";
import { writeFile } from "node:fs/promises";

const client = new SeedbaseClient({ token: process.env.SEEDBASE_TOKEN });
const gen = await client.generate(process.env.SEEDBASE_PROJECT, { seed: 42, wait: true });
await writeFile("seed.sql", await client.download(gen.id, { format: "sql" }));

# .github/workflows/test.yml
- run: node seed-sql.mjs
- run: psql "$DATABASE_URL" -f seed.sql

Because the data is keyed off the seed, a failing test reproduces locally with the same seed: 42, so snapshot tests stay stable across runs.

Snaplet Seed vs SeedBase for Prisma teams

Prisma teams were Snaplet Seed's core audience, so here is the practical picture if that is you. What stays the same: your schema.prisma is still the single source of truth, your prisma migrate still owns the database, and you still seed through prisma db seed with a pinned seed for reproducibility. What changes: the generated createSeedClient in your repo is replaced by seedPrisma from @seedbase/client/prisma, and the introspection runs against a maintained engine instead of a frozen one.

• Relations from @relation stay foreign-key-consistent, across as many tables as your schema has.
• Need rows in a test rather than in the database? seededRows hands them back per table in dependency order, ready for a factory or fixture.
• Mixed stack? The same project also seeds a Django or raw-SQL service, so a Prisma API and a Python worker share one source of test data.

For a Prisma-focused walkthrough with code, see Prisma test data.

When to pick which

Stay on the Snaplet Seed fork if you are all-in on Prisma/TypeScript, want the seed script in your repository, and are fine maintaining an archived tool yourself.

Pick SeedBase when you want a maintained, supported alternative: schema from SQL, Django or Prisma, FK-consistency at scale, realistic distributions, repeatable seeds for CI, masked production data for staging, and generation straight from your IDE or AI assistant.

Snaplet Seed alternative: FAQ

It does the same job, schema-aware foreign-key-consistent seed data, but the API is different. Instead of a generated createSeedClient in your repo, you import your schema once and call seedPrisma (or generate a SQL file). The migration takes a few steps, not a rewrite, and your schema.prisma does not change.

For the Prisma workflow, seedPrisma(prisma, client, { project, seed }) from @seedbase/client/prisma is the closest equivalent, run through prisma db seed. If you want the rows in memory rather than inserted, client.seededRows(project, { seed }) returns them keyed by table in foreign-key-safe order.

Snaplet the company wound down and shut its hosted services on 31 August 2024. It open-sourced its tooling, including Snaplet Seed, but the community fork has seen no meaningful release since v0.98.0 in July 2024, so it is effectively unmaintained.

Yes. SeedBase reads your existing schema.prisma (or a SQL dump, Django models.py, or a live database) as the blueprint. You remove @snaplet/seed, point SeedBase at the same schema, and wire the seed step. Your migrations stay the source of truth.

No. Snaplet Seed was Prisma and TypeScript first, while SeedBase also reads raw SQL (CREATE TABLE from PostgreSQL or MySQL), Django models.py, and live databases. Output goes to SQL, CSV, JSON, or a direct push into your database, so it fits mixed stacks.

Yes. Pass a seed (for example seed: 42) and the same schema produces the same rows on every run, which is what keeps CI and snapshot tests stable. A pinned reference date makes timestamps reproducible too.

Yes, a free tier without a credit card, including schema import and generation. Paid plans start at €19/month.