drizzle-seed reset() fails on drizzle-orm beta/rc: fix

TL;DR#

drizzle-seed 0.3.1, the package's latest release, was built against drizzle-orm 0.x. Its first lines import names that the drizzle-orm 1.0 prereleases moved or renamed, so on a project with drizzle-orm@beta or drizzle-orm@rc the module cannot even load, and reset(db, schema) never runs. npm refuses the pair at install time; once forced, Node fails on the import. The fix is not a patch to 0.3.1: install drizzle-seed from the same prerelease line as your drizzle-orm (drizzle-seed@beta or drizzle-seed@rc).

The report is drizzle-orm issue #5826, opened on 29 May 2026 and still open. It was filed with drizzle-orm and drizzle-kit ^1.0.0-beta.22, "drizzle-seed": "^0.3.1" and PostgreSQL, and it quotes this error:

SyntaxError: Export named 'createTableRelationsHelpers' not found in module '.../node_modules/drizzle-orm/index.js'.

Another user hit the same thing with drizzle-orm ^1.0.0-rc.4. Node does not word the error that way, and it does not always name the same export. Reproduced on 30 October 2026 (Node 24.22.2, npm 11.19.1, PostgreSQL 17, all in Docker), Node printed this on drizzle-orm 1.0.0-beta.22 with drizzle-seed 0.3.1:

SyntaxError: The requested module 'drizzle-orm/pg-core' does not provide an export named 'PgDatabase'

and this on drizzle-orm 1.0.0-rc.5, the current rc tag on the npm registry:

SyntaxError: The requested module 'drizzle-orm/sqlite-core' does not provide an export named 'BaseSQLiteDatabase'

All three messages are the same failure. If you see any of them while importing drizzle-seed, read on.

Why it happens#

drizzle-seed is released in step with drizzle-orm. The registry entry for drizzle-seed shows three tags that matter here: latest is 0.3.1, published on 29 January 2025; beta is 1.0.0-beta.22; rc is 1.0.0-rc.5, published on 21 October 2026. A 0.4.0 also exists, published on 3 November 2025 with no tag pointing at it; it is covered below because it fails too. Drizzle's own v1 changes page lists drizzle-orm, drizzle-kit and drizzle-seed side by side, each going from its 0.x line to its 1.0 line. The three packages move together.

The upgrade guide installs only drizzle-orm@rc and drizzle-kit@rc, and the seeding overview page installs plain drizzle-seed, which resolves to the latest tag. Follow both pages on the same project and you get drizzle-orm 1.0 next to drizzle-seed 0.3.1.

The published index.mjs of drizzle-seed 0.3.1 starts with four static imports from drizzle-orm:

import { is, entityKind, eq, sql, Relations, getTableName, extractTablesRelationalConfig, createTableRelationsHelpers, One } from 'drizzle-orm';
import { MySqlDatabase, MySqlTable, getTableConfig as getTableConfig$1 } from 'drizzle-orm/mysql-core';
import { PgDatabase, getTableConfig, PgTable } from 'drizzle-orm/pg-core';
import { BaseSQLiteDatabase, SQLiteTable, getTableConfig as getTableConfig$2 } from 'drizzle-orm/sqlite-core';

In drizzle-orm 1.0 the old relations API left the package root. The v1 changes page states: "RQBv1 has been removed". Its helpers now sit under drizzle-orm/_relations, which is also where the relations v1 to v2 guide imports the old relations() from. drizzle-seed 1.0.0-rc.5 imports createTableRelationsHelpers from drizzle-orm/_relations and PgAsyncDatabase from drizzle-orm/pg-core/async. 0.3.1 still asks the old paths. A short script in the reproduction checked every name in those four lines against each drizzle-orm build:

$ node missing.mjs   # drizzle-orm@1.0.0-beta.22 + drizzle-seed@0.3.1
drizzle-orm: missing Relations, extractTablesRelationalConfig, createTableRelationsHelpers
drizzle-orm/mysql-core: all present
drizzle-orm/pg-core: missing PgDatabase
drizzle-orm/sqlite-core: all present
$ node missing.mjs   # drizzle-orm@1.0.0-rc.5 + drizzle-seed@0.3.1
drizzle-orm: missing Relations, extractTablesRelationalConfig, createTableRelationsHelpers
drizzle-orm/mysql-core: missing MySqlDatabase
drizzle-orm/pg-core: missing PgDatabase
drizzle-orm/sqlite-core: missing BaseSQLiteDatabase

An ES module's imports are linked before any of its code runs, and a missing named export stops the link. The runtime reports one missing name, not the full list, which is why the issue quotes createTableRelationsHelpers while Node names PgDatabase or BaseSQLiteDatabase. A file that contains only import 'drizzle-seed' fails with the same error, so seed() is broken too, not only reset(). drizzle-kit plays no part: it was not installed in any run of the reproduction.

The npm side: ERESOLVE before the import error#

With npm you usually meet the problem one step earlier. drizzle-seed 0.3.1 declares an optional peer dependency on drizzle-orm with the range >=0.36.4. Under semver a prerelease such as 1.0.0-rc.5 does not satisfy a range written without a prerelease tag, so npm 11 rejects the install:

npm error code ERESOLVE
npm error ERESOLVE could not resolve
npm error
npm error While resolving: drizzle-seed@0.3.1
npm error Found: drizzle-orm@1.0.0-rc.5
npm error node_modules/drizzle-orm
npm error   drizzle-orm@"^1.0.0-rc.5" from the root project
npm error
npm error Could not resolve dependency:
npm error peerOptional drizzle-orm@">=0.36.4" from drizzle-seed@0.3.1

That came from npm install drizzle-seed run after npm install drizzle-orm@1.0.0-rc.5 pg in the reproduction. The same broad-peer-range trap with a release candidate is covered for Firebase in this ERESOLVE walkthrough. Here npm is right: --legacy-peer-deps gets the install through, and npm ls then marks the pair invalid: ">=0.36.4" from node_modules/drizzle-seed. The next node run fails with the import error above.

Check your own ERESOLVE output#

If npm stopped you before Node did, paste the full npm error block here to see which package asked for which range. It runs in your browser and nothing is sent.

Fix#

1. See which versions the project actually resolves:

   bash

   npm ls drizzle-orm drizzle-seed

   If drizzle-orm starts with 1.0.0- and drizzle-seed is 0.3.1, this page is your case.

2. Install drizzle-seed from the same line as drizzle-orm. On a project that follows the upgrade guide's rc tag:

   bash

   npm install drizzle-orm@rc drizzle-seed@rc

   On a project that stays on the issue's beta:

   bash

   npm install drizzle-orm@1.0.0-beta.22 drizzle-seed@beta

   The peer ranges decide which pairing is valid. Per the drizzle-seed registry entry, 1.0.0-beta.22 requires drizzle-orm >=1.0.0-beta.2, and 1.0.0-rc.5 requires drizzle-orm >=1.0.0-rc.5. drizzle-seed@rc on a drizzle-orm beta is therefore another mismatch. Either upgrade both to rc together or keep both on beta.

3. If you added --legacy-peer-deps, or legacy-peer-deps=true in .npmrc, to get past ERESOLVE, remove it. With the matching pair npm resolves without it: in the reproduction, installing drizzle-seed 1.0.0-rc.5 over a tree forced with the flag reported changed 1 package and a clean npm ls. Keeping the flag would hide the next mismatch:

   bash

   npm install
   npm ls drizzle-orm drizzle-seed

4. Pin exact versions while Drizzle v1 is in prerelease. A dist-tag moves when a new prerelease ships, and the two packages must move at the same time. In package.json, write both as the same exact version, for example "drizzle-orm": "1.0.0-rc.5" and "drizzle-seed": "1.0.0-rc.5".

Verify the fix#

The reproduction used a two-table schema (users, and posts with a foreign key to users), inserted rows, then called reset(db, schema) through drizzle-orm/node-postgres. With a clean npm install drizzle-orm@rc drizzle-seed@rc pg:

seed-reset-repro@ /app
+-- drizzle-orm@1.0.0-rc.5
`-- drizzle-seed@1.0.0-rc.5
  `-- drizzle-orm@1.0.0-rc.5 deduped

$ node reset.js
inserted user ids: [ 5, 6 ]
before reset: { users: '2', posts: '1' }
after reset: { users: '0', posts: '0' }
exit: 0

The beta pairing, drizzle-orm 1.0.0-beta.22 with drizzle-seed 1.0.0-beta.22, gave the same result. As a negative control, a clean project on the stable pair, drizzle-orm 0.45.4 (latest on the registry) with drizzle-seed 0.3.1, also reset both tables. 0.3.1 is not broken on its own; it only breaks against drizzle-orm 1.0. In your own project, npm ls drizzle-orm drizzle-seed should list one drizzle-orm, deduped, with no invalid marker.

CommonJS gives a different error#

A seed script loaded with require() (a .cjs file, or a project without "type": "module") gets past the import, because a missing property on a CommonJS module is just undefined. The failure moves to the call. Reproduced with drizzle-orm 1.0.0-rc.5 and drizzle-seed 0.3.1:

$ node reset.cjs
TypeError: Cannot read properties of undefined (reading 'Symbol(drizzle:entityKind)')
    at Module.is (/app/node_modules/drizzle-orm/entity.cjs:18:70)
    at reset (/app/node_modules/drizzle-seed/index.cjs:135510:20)

That line of drizzle-seed's CommonJS build is the first check in reset(), drizzleOrm.is(db, (pgCore.PgDatabase)). PgDatabase no longer exists in drizzle-orm 1.0's pg-core, so is() receives undefined. The cause and the fix are the same as for the ES module error.

What reset() sends, and the ids it leaves behind#

The seeding docs say that for PostgreSQL "the drizzle-seed package will generate TRUNCATE statements with the CASCADE option". With statement logging turned on, PostgreSQL 17 logged this for every working pairing in the reproduction:

db-1  | 2026-10-30 21:11:46.550 UTC [2198] LOG:  statement: truncate "public"."posts","public"."users" cascade;

There is no restart identity, so serial and identity sequences keep counting. Running the script twice against the same database printed inserted user ids: [ 1, 2 ] and then [ 3, 4 ]. A test fixture that hard-codes author_id = 1 after a reset therefore fails with a foreign-key error (SQLSTATE 23503); the reproduction's own first script hit one. Use the ids your inserts return, or, if the error has already appeared, the 23503 guide explains the missing-parent form of it.

If your tests need ids back at 1, truncate yourself. This version builds the table list from the same schema object and was reproduced on drizzle-orm 1.0.0-beta.22:

import { drizzle } from 'drizzle-orm/node-postgres';
import { sql, is, getTableName } from 'drizzle-orm';
import { PgTable } from 'drizzle-orm/pg-core';
import * as schema from './schema';
 
const db = drizzle(process.env.DATABASE_URL!);
 
const tables = Object.values(schema)
  .filter((t) => is(t, PgTable))
  .map((t) => `"${getTableName(t)}"`);
 
await db.execute(sql.raw(`truncate ${tables.join(', ')} restart identity cascade;`));

PostgreSQL logged truncate "posts", "users" restart identity cascade;, and the next insert returned id 1. It quotes bare table names, so tables in a pgSchema need the schema prefix added. The workaround posted in the issue thread does the same job for MySQL with SET FOREIGN_KEY_CHECKS = 0 and one truncate per table. On PostgreSQL you do not need it once drizzle-seed matches drizzle-orm.

Do not reach for drizzle-seed 0.4.0#

The registry lists one stable-looking version after 0.3.1: 0.4.0, published on 3 November 2025 and not on any dist-tag. Its peer range is >=1.0.0-beta.1, so npm installs it next to a drizzle-orm 1.0 prerelease without complaint, and it already imports the old relations helpers from drizzle-orm/_relations. It still imports PgDatabase from drizzle-orm/pg-core, though. Reproduced with drizzle-orm 1.0.0-beta.22:

SyntaxError: The requested module 'drizzle-orm/pg-core' does not provide an export named 'PgDatabase'

With drizzle-orm 1.0.0-rc.5 it failed on BaseSQLiteDatabase instead, the same two messages as 0.3.1. A clean install that still fails at import is harder to diagnose than ERESOLVE, so pin drizzle-seed to the same prerelease version as drizzle-orm, not to the highest number that installs.

Status of the issue#

On 30 October 2026, issue #5826 is open, and its timeline links no pull request or commit. There is no 0.x release that fixes it, and latest still points at 0.3.1, so a plain npm install drizzle-seed gives the build that fails. The working drizzle-seed is the 1.0 prerelease line, published under the same tags as drizzle-orm. Keep the two packages on one exact version.

Drizzle's ES module builds have tripped over packaging changes before. If a drizzle-kit import fails at load time instead, see the Dynamic require of "fs" fix or drizzle-kit's Cannot use import statement outside a module. If your tests undo writes with a transaction instead of truncating, note that Drizzle's tx.rollback() throws, and a catch that swallows it can let PostgreSQL commit.