[BUG]: drizzle-kit push attempts to drop policies in excluded schemas (e.g. cron) despite schemaFilter: ["public"]

[SennaSanzo]

Report hasn't been filed before.

• I have verified that the bug I'm about to report hasn't been filed before.

What version of drizzle-orm are you using?

1.0.0-beta.13-f728631

What version of drizzle-kit are you using?

1.0.0-beta.13-f728631

Other packages

No response

Describe the Bug

What is the undesired behavior?

When running drizzle-kit push, the tool attempts to drop or modify database objects (specifically policies on cron.job) that reside in schemas explicitly excluded by the schemaFilter configuration.

Even with schemaFilter: ["public"] configured in [drizzle.config.ts], drizzle-kit introspects the cron schema (created by the pg_cron extension) and generates SQL to drop its policies. This results in a permission error because the user does not own the extension-managed objects.

Note 1: Although the documentation states that the default schemaFilter is ["public"], I observed different results when explicitly setting it versus omitting it, suggesting the default might not be applied as expected in this version.
Note 2: The execution halts immediately at the drop policy error on the cron schema. Therefore, I cannot confirm whether other schemas present in the database would also be incorrectly targeted, but it is possible that the issue extends to them as well.

Additionally, attempting to use extensionsFilters as a workaround fails because:

1. It seems to be ignored or insufficient to prevent this introspection.
2. The TypeScript types for extensionsFilters are overly restrictive (only allowing "postgis" in our version), creating type errors.

What are the steps to reproduce it?

1. Use a PostgreSQL database (e.g., Supabase) with the pg_cron extension enabled (which creates a cron schema and default policies).
2. Configure [drizzle.config.ts] to only manage the public schema:

  export default defineConfig({
    schemaFilter: ["public"],
    // ... other config
  });

3. Run drizzle-kit push.
4. Observe that drizzle-kit generates SQL statements targeting the cron schema, such as:

DROP POLICY "cron_job_policy" ON "cron"."job";

5. The command fails with: query error: must be owner of relation job.

What is the desired result?

drizzle-kit should strictly respect the schemaFilter configuration. If schemaFilter is set to ["public"], no other schemas (like cron, auth, storage, etc.) should be introspected, and no SQL should be generated for them, regardless of whether they contain extensions or not.

Environment & Configuration

What database engine are you using? Are you using a specific cloud provider? Which one?
PostgreSQL via Supabase.

Do you think this bug pertains to a specific database driver? Which one?
Likely specific to drizzle-kit's introspection logic on PostgreSQL when extensions are present. We are using postgres (postgres.js) or pg driver, but this occurs at the drizzle-kit push level.

Are you working in a monorepo?
Yes, referencing a shared config in a packages/db workspace.

If this is a bug related to types: What Typescript version are you using?
TypeScript 5.x.

Configuration (drizzle.config.ts):

import { defineConfig } from "drizzle-kit";
export default defineConfig({
  out: "./src/drizzle/migrations",
  schema: "./src/drizzle/schema.ts",
  schemaFilter: ["public"],
  // Attempted workaround (failed primarily due to types and lack of effect):
  // extensionsFilters: ["postgis", "pg_cron"], 
  strict: true,
  verbose: true,
  dialect: "postgresql",
  // ... credentials
});

Error Log:

DROP POLICY "cron_job_policy" ON "cron"."job";
--> query error: must be owner of relation job

[ignaciogiri]

Same error here:

pnpm run db:push

> cute@1.0.0 db:push /Users/me/Apps/myapp
> cd packages/db && npx drizzle-kit push

No config path provided, using default 'drizzle.config.ts'
Reading config file '/Users/me/Apps/myapp/packages/db/drizzle.config.ts'
Using 'postgres' driver for database querying
[✓] Pulling schema from database...

┌─── public.users.public_id column changed:
│ identity: name: users_public_id_seq1 -> name: users_public_id_seq
├───
└───

┌─── public.items.public_id column changed:
│ identity: name: items_public_id_seq1 -> name: items_public_id_seq
├───
└───

DROP POLICY "cron_job_policy" ON "cron"."job";

┌── query error: must be owner of relation job

DROP POLICY "cron_job_policy" ON "cron"."job";
└──
 ELIFECYCLE  Command failed with exit code 1.

[curiosbasant]

Is there any alternative? Any quick fix/hacks? This is a real bummer! :(

[SennaSanzo]

On my side for now this is not a real issue since I can swipe my entire DB (early dev phase) and kit generate and kit migrate. But if you wanna push incremental changes with push, I think the only solution is to wait the fix from the team.

[ignaciogiri]

Claude masked the problem with a scripts/push.db

#!/bin/bash
# Custom db:push wrapper that works around drizzle-kit beta policy introspection bug.
# drizzle-kit beta reads pg_policies from ALL schemas (not just public), then tries
# to DROP policies on cron/storage tables we don't own. This script:
# 1. Runs --explain to get planned SQL
# 2. Filters out DROP POLICY on non-public schemas
# 3. If real changes remain, runs them via psql
# 4. If no real changes, reports success

set -euo pipefail

cd "$(dirname "$0")/.."

echo "Running drizzle-kit push --explain..."
EXPLAIN_OUTPUT=$(npx drizzle-kit push --explain 2>&1) || true

# Extract only the SQL statements (lines that look like SQL, between the --- markers)
SQL_STATEMENTS=$(echo "$EXPLAIN_OUTPUT" | sed -n '/^--- Generated migration statements ---$/,/^$/p' | grep -E '^(ALTER|CREATE|DROP|INSERT|UPDATE|DELETE|COMMENT|GRANT|REVOKE|SET)' || true)

# Filter out DROP POLICY on non-public schemas
FILTERED=$(echo "$SQL_STATEMENTS" | grep -v 'DROP POLICY.*ON "cron"\.' | grep -v 'DROP POLICY.*ON "storage"\.' | grep -v 'DROP POLICY.*ON "supabase_' | grep -v '^$' || true)

if [ -z "$FILTERED" ]; then
  echo ""
  echo "Schema is in sync. No changes to apply."
  echo "(Filtered out $(echo "$SQL_STATEMENTS" | grep -c 'DROP POLICY' || echo 0) policy statements from non-public schemas)"
  exit 0
fi

echo ""
echo "Changes to apply:"
echo "$FILTERED"
echo ""
read -p "Apply these changes? [y/N] " -n 1 -r
echo ""

if [[ $REPLY =~ ^[Yy]$ ]]; then
  # Load database URL from .env
  if [ -f .env ]; then
    export $(grep -v '^#' .env | xargs)
  fi
  DB_URL="${POSTGRES_DIRECT_URL:-${POSTGRES_URL:-}}"
  if [ -z "$DB_URL" ]; then
    echo "Error: POSTGRES_URL or POSTGRES_DIRECT_URL not set"
    exit 1
  fi

  echo "$FILTERED" | psql "$DB_URL" -v ON_ERROR_STOP=1
  echo ""
  echo "Changes applied successfully."
else
  echo "Aborted."
  exit 1
fi

I hate this solution. But I gotta live with it for now.

[curiosbasant]

I'm running this command to spit out the generated sql instructions.
drizzle-kit push --explain --verbose

Then manually filtering the commands I want, to directly run the queries on the db.

[SennaSanzo]

@OleksiiKH0240 Were you able to reproduce the issue on your end? Do you have any idea when a fix might be pushed to the beta?

[dldri]

Adding to this, I'm facing similar issues with policies on storage buckets getting overwritten when doing a drizzle-kit push.

I'm using Supabase and when I create a policy on a storage bucket, followed by a drizzle-kit push. The CLI will return "No changes detected" and the applied policy will be deleted.

[ignaciogiri]

@AndriiSherman Can you take a look a this?