Mahdi BEN RHOUMA

Posted on Sep 16 Originally published at iloveblogs.blog

Fix Extremely Slow Drizzle IntelliSense on Large Schemas

#drizzleorm #typescript #intellisense #troubleshooting

What the slowdown looks like

Editors freeze because tsserver is still resolving the drizzle(sql, { schema }) type surface. The GitHub issue drizzle-team/drizzle-orm#800 reports the symptom exactly as “[BUG]: Extremely slow intellisense depending on schema size and amount”. On drizzle-orm 0.27.0 with 40 tables on an M2 Max, the delay approaches 8 seconds; on non-Macbook M-series machines with 32 tables, users logged 10–15 second waits and one measured 14 seconds with tsc. The fix that returns completions to interactive speed is upgrading from drizzle-orm 0.27.0 to drizzle-orm 0.28.0, which contains internal type optimizations that improved diagnostics by 430% on an 85-table, 666-column schema.

This is a TypeScript compiler delay, not a database runtime delay. If end-user queries are also slow, check Why Your Supabase Queries Are Slow.

Diagnosing the delay with --extendedDiagnostics

Measure before you change anything. The issue users used npx tsc --extendedDiagnostics --incremental false --noEmit to isolate type-generation cost from incremental build state.

# Measure TypeScript type expansion before and after the upgrade
npx tsc \
  --extendedDiagnostics \
  --incremental false \
  --noEmit

Look for the Types row in the output. In the issue, a 32-table schema generated over 500,000 types and took 14 seconds to fire IntelliSense. That figure is what the upgrade should reduce. Keep the terminal open so you have a before number.

If you need to recreate a clean test database while benchmarking different schema shapes, the safe reset sequence in How to Drop All Tables in PostgreSQL Safely avoids leaving stale objects.

Root cause: the full schema expands a huge TypeScript type graph

The trigger is the schema object passed to drizzle():

import { Pool } from "pg";
import { drizzle } from "drizzle-orm/node-postgres";
import * as schema from "./schema";

const pool = new Pool({ connectionString: process.env.DATABASE_URL });
const db = drizzle(pool, { schema });

When you pass schema, Drizzle builds a typed query API over every table, column, relation, and enum in that object. IDE autocomplete calls this type surface on demand, and tsserver expands the graph every time it recomputes. The larger the schema — the issue reporter says 40 tables is enough — the more intermediate union and keyof types are created; a comment reports over 500,000 types before the workaround. drizzle-orm 0.27.0 shipped those internal types in a form that made the expansion expensive. The maintainer comment confirms that drizzle-orm@0.28.0 introduced optimized internal types based on a schema with 85 tables, 666 columns, 26 enums, 172 indexes, and 133 foreign keys.

TypeScript itself also contributes to the cost. TypeScript itself shipped a fix for part of this: PR #55224, merged on 3 August 2023 and released in TypeScript 5.2, improves recursiveTypeRelatedTo performance. Its author states on the issue that it "mitigates at least half of the slowness". Make sure your project is on TypeScript 5.2 or newer so you get that improvement alongside the drizzle-orm upgrade.

It is not a hardware problem: the 8-second case was an M2 Max. Adding CPU cores will not fix a type graph that is simply too large.

The fix: upgrade to drizzle-orm 0.28.0

The release to install is drizzle-orm@0.28.0. In package.json, move the dependency forward.

Before:

{
  "dependencies": {
    "drizzle-orm": "0.27.0"
  }
}

After:

{
  "dependencies": {
    "drizzle-orm": "0.28.0"
  }
}

Then run npm install. The maintainer's announcement on the issue says the release has improvements for IntelliSense and the diagnostics produced a 430% speedup. The change is entirely in the TypeScript types, so there is no migration SQL to run. Only the drizzle-orm type package changes — drizzle-kit and your migrations are untouched.

Temporary workarounds for 0.27.0

If you cannot upgrade immediately, the issue contains two mitigations.

First, cast column names during table definition. Users in the issue reported that writing integer("id" as string) reduces generated types from over 500,000 to about 40,000 and cuts IntelliSense delay from 14 seconds to 5 seconds:

import { pgTable, integer, varchar } from "drizzle-orm/pg-core";

export const users = pgTable("users", {
  id: integer("id" as string).primaryKey(),
  name: varchar("name" as string, { length: 255 }),
});

This tells TypeScript to keep the column-name literal type as a plain string instead of preserving and mapping each literal in the query builder. The trick works for both drizzle-orm/pg-core and drizzle-orm/mysql-core imports, which are the typical sources of large schema types.

Second, pass only a subset of the schemas into the query builder instead of the entire generated schema module. The issue body notes that IntelliSense gets faster again when only a subset of the schemas is provided. That means create a second database instance with the tables a specific file needs, or split your schema module by domain and import only the domain needed by the current query file.

Two patterns that still trip you up

One common trap is keeping all 40-plus tables in a single monolithic schema file and importing that file everywhere. The file layout does not change the TypeScript type graph by itself, but importing every table into a single hot path makes the expansion happen constantly. Split schema files by domain so autocomplete only resolves the tables a query file actually uses. If you are seeding those split domains and run into duplicate-key errors, the relevant fix is Postgres INSERT If Not Exists.

Another trap is blaming the Mac processor. The M2 Max still hit 8 seconds in the issue, so upgrading the laptop is not a solution. If you are on an M1 and also see Can't reach database server at database:5432, that is a separate platform-specific connection issue documented in Prisma: Can't reach database server at database:5432 on M1.

Verify the fix

After the upgrade, restart the TypeScript server in your editor. In VS Code, open the command palette and run TypeScript: Restart TS Server; in WebStorm, invalidate caches or restart the IDE. Then re-run the same compiler measurement:

# 1. Confirm the resolved package version
npm ls drizzle-orm

# 2. Repeat the type measurement
npx tsc --extendedDiagnostics --incremental false --noEmit

The Types line should fall from the six-figure counts users reported on 0.27.0. IntelliSense should reappear in interactive time instead of 10–15 seconds. If the delay persists, make sure the editor is not picking up a cached node_modules copy of 0.27.0; npm ls drizzle-orm prints the resolved tree and confirms 0.28.0.

FAQ

Which drizzle-orm version fixes the large-schema IntelliSense problem?

drizzle-orm@0.28.0 is the fix release. The maintainer closed drizzle-team/drizzle-orm#800 with that version and reported a 430% IntelliSense speedup on a schema with 85 tables and 666 columns. Upgrade from 0.27.0 and restart the TypeScript server.

Does the column name cast still help after upgrading?

The cast trick is a temporary workaround for 0.27.0. After moving to 0.28.0, you should not need it. If you still see delays, profile with tsc --extendedDiagnostics before reintroducing casts, because the internal type optimizations in 0.28.0 already address the largest expansion.

Is this a database schema-design issue, not an editor issue?

The slowdown is in tsserver, driven by the number of types the schema object introduces. It is not caused by PostgreSQL query planning or table indexes. Database-side performance problems produce slow response times, not editor freezes. For query-latency issues, start with the runtime article linked earlier.

Originally published at https://www.iloveblogs.blog

DEV Community