[BUG]: The Drizzle-kit push command consistently crashes on execution (Supabase | NeonDB | SST)
Closed this issue · 12 comments
What version of drizzle-orm are you using?
0.35.2
What version of drizzle-kit are you using?
0.26.2
Describe the Bug
I'm not really sure why I keep getting an error whenever I try to run drizzle:push": "sst shell drizzle-kit push". I've been able to reproduce this in both new and existing projects since March. I've always make sure my Drizzle deps are up to date.
Reading config file '/home/moncy/projects/kyros-labs/artemis/packages/core/drizzle.config.ts'
Using 'postgres' driver for database querying
[⣟] Pulling schema from database...
/home/moncy/projects/kyros-labs/artemis/node_modules/drizzle-kit/bin.cjs:19716
checkValue = checkValue.replace(/^CHECK\s*\(\(/, "").replace(/\)\)\s*$/, "");
^
TypeError: Cannot read properties of undefined (reading 'replace')
at /home/moncy/projects/kyros-labs/artemis/node_modules/drizzle-kit/bin.cjs:19716:39
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
Node.js v20.18.0
Expected behavior
The command should work as expected in a project using Drizzle ORM with either Supabase or NeonDB as the DB service.
Environment & setup
NeonDB
import { defineConfig } from 'drizzle-kit'
import { Resource } from 'sst'
export default defineConfig({
dialect: 'postgresql',
schema: './src/schema/*',
out: './migrations',
dbCredentials: {
url: Resource.DatabaseUrl.value,
database: 'postgres',
port: 5432,
},
verbose: true,
strict: true,
schemaFilter: ['public'],
})
import { neonConfig, Pool as NeonPool } from '@neondatabase/serverless'
import { drizzle as drizzleNeon } from 'drizzle-orm/neon-serverless'
import { Resource } from 'sst'
import ws from 'ws'
import * as schema from './schema'
neonConfig.webSocketConstructor = ws
export const neonDatabaseUrl = Resource.DatabaseUrl.value
export const db = drizzleNeon<typeof schema>(
new NeonPool({ connectionString: neonDatabaseUrl }),
{
schema,
// logger: Resource.App.stage !== 'production',
},
)
export type DB = typeof db "@neondatabase/serverless": "^0.9.5",
"drizzle-kit": "^0.26.2",
"drizzle-orm": "^0.35.2",
"drizzle-zod": "^0.5.1",
"ws": "^8.18.0",
"sst": "3.1.54"Supabase
import { defineConfig } from 'drizzle-kit'
import { Resource } from 'sst'
export default defineConfig({
dialect: 'postgresql',
schema: './src/schema/*',
out: './migrations',
dbCredentials: {
url: Resource.SupabaseDatabaseUrl.value,
ssl: {
rejectUnauthorized: false,
},
},
verbose: true,
strict: true,
schemaFilter: ['public'],
})
import { drizzle } from 'drizzle-orm/postgres-js'
import postgres from 'postgres'
import { Resource } from 'sst'
import * as schema from './schema'
export const sql = postgres(Resource.SupabaseDatabaseUrl.value, {
prepare: false,
debug: true,
})
export const db = drizzle(sql, {
schema,
})
export type DB = typeof db
"drizzle-kit": "^0.26.2",
"drizzle-orm": "^0.35.2",
"drizzle-zod": "^0.5.1",
"postgres": "^3.4.4",
"sst": "3.1.54"Linux (Fedora)
Linux moncy-lambda-pc 6.11.3-200.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Oct 10 22:31:19 UTC 2024 x86_64 GNU/LinuxI have the same issue but with supabase + I use also fedora 🤔
I'm having the same issue with drizzle-kit pull. very similar setup.
Same issue here with drizzle-kit pull
Same issue, experiencing it when trying to run drizzle-kit pull connecting to Supabase DB.
Running CLI on WSL2:
Linux DESKTOP-L45D8DJ 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
Looks like maybe missing expected fields (ex: checks.constraint_definition) to have been created by Supabase definition?
I am also facing this same issue. Any updates?
fixed this this dbCredentials in drizzle.config.ts
import 'dotenv/config';
import { defineConfig } from 'drizzle-kit';
export default defineConfig({
out: './drizzle',
schema: './src/db/schema.ts',
dialect: 'postgresql',
dbCredentials: {
database: "postgres",
port: 5432,
host: "aws-0-eu-central-1.pooler.supabase.com",
user: env.DB_USER,
password: env.DB_PASSWORD,
},
schemaFilter: ["public"],
});
Yeah, I confirm that passing detailed dbCredentials works for me too.
Thanks @arahman-yusra 🙏
I also confirm that passing detailed as @arahman-yusra defined is correct, but everyone needs to keep in mind to
set the pooling mode to session
in this case. I have been facing the same error, but after switching the pooling mode to session, it works for me. After reading this, I understand why the pooling mode is crucial for resolving the issue.
Transaction mode:
This mode is recommended for connections from serverless environments. A connection is assigned to the client for the duration of a transaction. Two consecutive transactions from the same client could be executed over two different connections. However, some session-based Postgres features, such as prepared statements, are not available with this option.
Session mode:
This mode is similar to connecting to your database directly. It provides full support for prepared statements. When a new client connects, a connection is assigned to that client until they disconnect. Be aware that you might run into pooler connection limits since the connection is held until the client disconnects.
I just use session connection string only for drizzle.config.ts and it works
I also confirm that passing detailed as @arahman-yusra defined is correct, but everyone needs to keep in mind to
set the pooling mode to session
in this case. I have been facing the same error, but after switching the pooling mode to session, it works for me. After reading this, I understand why the pooling mode is crucial for resolving the issue.
Transaction mode: This mode is recommended for connections from serverless environments. A connection is assigned to the client for the duration of a transaction. Two consecutive transactions from the same client could be executed over two different connections. However, some session-based Postgres features, such as prepared statements, are not available with this option.
Session mode: This mode is similar to connecting to your database directly. It provides full support for prepared statements. When a new client connects, a connection is assigned to that client until they disconnect. Be aware that you might run into pooler connection limits since the connection is held until the client disconnects.
Thanks so much for this insightful post. Unfortunately, I can't use the session mode because my Remix server runs on AWS Lambda :( So basically it runs in a serverless environment. This is something only I can fix. I guess I can close this issue for now.
I also confirm that passing detailed as @arahman-yusra defined is correct, but everyone needs to keep in mind to
set the pooling mode to session
in this case. I have been facing the same error, but after switching the pooling mode to session, it works for me. After reading this, I understand why the pooling mode is crucial for resolving the issue.
Transaction mode: This mode is recommended for connections from serverless environments. A connection is assigned to the client for the duration of a transaction. Two consecutive transactions from the same client could be executed over two different connections. However, some session-based Postgres features, such as prepared statements, are not available with this option.
Session mode: This mode is similar to connecting to your database directly. It provides full support for prepared statements. When a new client connects, a connection is assigned to that client until they disconnect. Be aware that you might run into pooler connection limits since the connection is held until the client disconnects.
Using session connection resolved issue for me Thanks @Bidhanhansda
Switching to Connection Pooler Mode to Session also fixed mine! Thanks for help!
Using Supabase
