drizzle-orm

Verifications (template's checkbox group) [x] I have verified that the bug I'm about to report hasn't been filed before. What version of are you using? What version of are you using? Other packages Describe the Bug Undesired behavior exits with code when a migration fails, but the error message is not visible in any non-TTY capture (CI logs, , redirected stdout, log aggregators). The CLI's progress spinner uses ANSI escape sequences to erase the previous line and rewrite it, so the real error message ends up on a line that the next spinner redraw replaces. The evidence captured by looks like this: No line. No stack trace. Container exits 1, but the operator has no way to know why. Steps to reproduce 1. Set up a postgres instance with a schema that already has tables (or any state that will conflict with your first migration). 2. Configure with a custom / (this is a common pattern to isolate the migrations journal from ). 3. Run inside a Docker container (or any context that strips the TTY — CI runners, redirected stdout, journald captures). 4. Observe that the container exits 1 but the error message is not readable in . Real-world triggering examples (observed in our environment): 1. — Postgres 42P07. Thrown by line ~62 in , caught by the migrator wrapper, then re-thrown after the spinner overwrites the line. 2. — Postgres 42704. Same class: the migrator wraps the original error but the CLI spinner hides it. Desired result The CLI should either: Print the error to stderr (not stdout, so it doesn't get overwritten by the spinner), OR Honor a / flag that bypasses the spinner entirely and prints plain text per migration, OR Make the spinner write to stderr instead of stdout so captured logs preserve at least the spinner frame. The minimum viable fix is one of those three. The first option is the smallest change and the highest-value for non-TTY capture. Are you working in a monorepo? Yes — monorepo. If this is a bug related to types: What Typescript version are you using? n/a — runtime bug, not a typescript issue. If you're using a runtime that isn't Node.js: Which one? n/a — Node.js 24.x. Suggested reproduction (minimal) , is empty, has no error message. The bug. Proposed fix (one-line concept) In near line 92050 (the command handler), the call: becomes: This guarantees the error is written to stderr (which the spinner doesn't touch) and gives operators a reliable signal in CI logs. Optionally, add a flag that bypasses and prints plain text — useful for CI pipelines that prefer deterministic line counts. Environment drizzle-kit 0.31.10 drizzle-orm 0.45.2 postgres 16 (also reproducible on postgres 18) Node.js 24.19.0 Docker Desktop 4.x on Windows (where the spinner escape codes are captured but the line-rendering is lost) Workaround (for users who hit this) The three-step bypass: 1. Direct drizzle-orm migrator call via to bypass the CLI spinner entirely: 2. Apply migrations manually via psql with . 3. Volume-mount + redirect to files inside the container (this still suffers from the spinner overwrite but preserves the notice log). The first workaround (direct migrator API) is the only reliable way to see the error without the upstream fix.

Fixes #860 Problem wraps all pending migrations in a single transaction. PostgreSQL forbids (and / ) inside a transaction block, so any migration generated from an index with failed with: drizzle-kit already generates the SQL; it just could not be applied by (or by , which delegates to the same code). Solution The Postgres migrator now detects statements that start with or (after leading whitespace/comments) and executes them outside of the migration transaction: No concurrent statements pending (the common case): behavior is byte-for-byte identical to before. All pending migrations and their journal entries run in one transaction, all-or-nothing. A pending migration contains a concurrent statement: statements batched so far are committed first (required: waits for open transactions to finish, so keeping our own transaction open would self-deadlock), the concurrent statement runs on the session directly, and the remaining statements resume in a new transaction. Each migration is applied and recorded in individually, so a failure never rolls back a migration that was already recorded as applied. Since concurrent index builds are inherently non-transactional, a migration containing one cannot be fully atomic. If such a statement fails mid-build, PostgreSQL can leave an index behind, which has to be dropped before retrying - the same caveat as running manually. Notes: Only statement detection, no SQL rewriting: exactly the statements in the migration files are executed. Drivers without transaction support (, ) already ran statements individually and are unaffected. All drivers that use (node-postgres, postgres-js, pglite, neon-serverless, vercel-postgres, aws-data-api, bun-sql, netlify) inherit the fix. Migrations generated with (all statements in one string) remain unsupported for , as before. Tests (new, 24 unit tests): single-transaction behavior preserved (including rollback of all pending migrations on failure), transaction boundaries and journal placement around concurrent statements, per-migration recording, custom /, failure ordering, and positive/negative statement classification (case-insensitivity, , , leading comments, quoted identifiers named , etc.). + fixture (new): applies a migration with two indexes plus a follow-up migration against real PostgreSQL, verifies both indexes exist and are , both migrations are journaled, a second call is a no-op, and the unique index enforces uniqueness. Without the fix this test fails with the exact error from #860 (verified). Full unit suite (590 tests), type tests, tsc, existing migrator integration tests for node-postgres, postgres-js and pglite, and dprint all pass. Made with Cursor

Report hasn't been filed before. [x] I have verified that the bug I'm about to report hasn't been filed before. What version of are you using? 1.0.0-rc.4 What version of are you using? 1.0.0-rc.4 Other packages pg@8.23.0, pg-pool@3.14.0 Describe the Bug [BUG]: node-postgres Pool works directly but fails when used with drizzle-orm@1.0.0-rc.4 Description I found an issue when using with the () driver and a PostgreSQL 16 database. The PostgreSQL connection works successfully using the same Pool directly, but when the same Pool is passed to Drizzle, the query fails with: I initially suspected a PostgreSQL password or Docker configuration issue, but I was able to isolate the problem to the Drizzle layer. Environment : : : PostgreSQL: Node.js: 22.x OS: Windows PostgreSQL running in Docker PostgreSQL / Docker setup I have two PostgreSQL containers: The application connects to the write database on port . The PostgreSQL user is: Drizzle setup Direct connection works Using the exact same Pool: Result: So the Pool can successfully authenticate with PostgreSQL. Drizzle query fails Using the same Pool: I get: The stack trace points into : Additional verification I also verified: Output: And: So the password is definitely a string and the Pool itself can establish a connection. Workaround I changed: to: without changing the PostgreSQL configuration or the Pool configuration. After changing the Drizzle version, the same Drizzle query works successfully. Expected behavior Since the Pool successfully connects and can execute queries directly, I would expect the same Pool to work when passed to: Actual behavior With , the query fails with: even though: the password is a string; the Pool connects successfully; direct queries work; PostgreSQL authentication works; changing only the Drizzle version makes the query work. Could you please confirm whether this is a known issue with and /, or whether there is a different recommended configuration for this combination? Thank you!