0.44.0

Error handling

Starting from this version, we’ve introduced a new DrizzleQueryError that wraps all errors from database drivers and provides a set of useful information:

1. A proper stack trace to identify which exact Drizzle query failed
2. The generated SQL string and its parameters
3. The original stack trace from the driver that caused the DrizzleQueryError

Drizzle cache module

Drizzle sends every query straight to your database by default. There are no hidden actions, no automatic caching or invalidation - you’ll always see exactly what runs. If you want caching, you must opt in.

By default, Drizzle uses a explicit caching strategy (i.e. global: false), so nothing is ever cached unless you ask. This prevents surprises or hidden performance traps in your application. Alternatively, you can flip on all caching (global: true) so that every select will look in cache first.

Out first native integration was built together with Upstash team and let you natively use upstash as a cache for your drizzle queries

import { upstashCache } from "drizzle-orm/cache/upstash";
import { drizzle } from "drizzle-orm/...";

const db = drizzle(process.env.DB_URL!, {
  cache: upstashCache({
    // 👇 Redis credentials (optional — can also be pulled from env vars)
    url: '<UPSTASH_URL>',
    token: '<UPSTASH_TOKEN>',
    // 👇 Enable caching for all queries by default (optional)
    global: true,
    // 👇 Default cache behavior (optional)
    config: { ex: 60 }
  })
});

You can also implement your own cache, as Drizzle exposes all the necessary APIs, such as get, put, mutate, etc.
You can find full implementation details on the website

import Keyv from "keyv";
export class TestGlobalCache extends Cache {
  private globalTtl: number = 1000;
  // This object will be used to store which query keys were used
  // for a specific table, so we can later use it for invalidation.
  private usedTablesPerKey: Record<string, string[]> = {};
  constructor(private kv: Keyv = new Keyv()) {
    super();
  }
  // For the strategy, we have two options:
  // - 'explicit': The cache is used only when .$withCache() is added to a query.
  // - 'all': All queries are cached globally.
  // The default behavior is 'explicit'.
  override strategy(): "explicit" | "all" {
    return "all";
  }
  // This function accepts query and parameters that cached into key param,
  // allowing you to retrieve response values for this query from the cache.
  override async get(key: string): Promise<any[] | undefined> {
    ...
  }
  // This function accepts several options to define how cached data will be stored:
  // - 'key': A hashed query and parameters.
  // - 'response': An array of values returned by Drizzle from the database.
  // - 'tables': An array of tables involved in the select queries. This information is needed for cache invalidation.
  //
  // For example, if a query uses the "users" and "posts" tables, you can store this information. Later, when the app executes
  // any mutation statements on these tables, you can remove the corresponding key from the cache.
  // If you're okay with eventual consistency for your queries, you can skip this option.
  override async put(
    key: string,
    response: any,
    tables: string[],
    config?: CacheConfig,
  ): Promise<void> {
    ...
  }
  // This function is called when insert, update, or delete statements are executed.
  // You can either skip this step or invalidate queries that used the affected tables.
  //
  // The function receives an object with two keys:
  // - 'tags': Used for queries labeled with a specific tag, allowing you to invalidate by that tag.
  // - 'tables': The actual tables affected by the insert, update, or delete statements,
  //   helping you track which tables have changed since the last cache update.
  override async onMutate(params: {
    tags: string | string[];
    tables: string | string[] | Table<any> | Table<any>[];
  }): Promise<void> {
    ...
  }
}

For more usage example you can check our docs

drizzle-kit@0.31.1

Fixed drizzle-kit pull bugs when using Gel extensions.

Because Gel extensions create schema names containing :: (for example, ext::auth), Drizzle previously handled these names incorrectly. Starting with this release, you can use Gel extensions without any problems. Here’s what you should do:

1. Enable extensions schemas in drizzle.config.ts

import  { defineConfig } from "drizzle-kit";

export default defineConfig({
  dialect: 'gel',
  schemaFilter: ['ext::auth', 'public']
});

2. Run drizzle-kit pull

3. Done!

0.43.1

Fixes

• Fixed incorrect types of schema enums in PostgreSQL

0.43.0

Features

• Added cross join (#1414)
• Added lateral left, inner, cross joins to PostgreSQL, MySQL, Gel, SingleStore
• Added drizzle connection attributes to SingleStore's driver instances

Fixes

• Removed unsupported by dialect full join from MySQL select api
• Forced Gel columns to always have explicit schema & table prefixes due to potential errors caused by lack of such prefix in subquery's selection when there's already a column bearing same name in context
• Added missing export for PgTextBuilderInitial type
• Removed outdated IfNotImported type check from SingleStore driver initializer
• Fixed incorrect type inferrence for insert and update models with non-strict tsconfigs (#2654)
• Fixed invalid spelling of nowait flag (#3554)
• Add join lateral support
• Remove .fullJoin() from MySQL API

0.42.0

Features

Duplicate imports removal

When importing from drizzle-orm using custom loaders, you may encounter issues such as: SyntaxError: The requested module 'drizzle-orm' does not provide an export named 'eq'

This issue arose because there were duplicated exports in drizzle-orm. To address this, we added a set of tests that checks every file in drizzle-orm to ensure all exports are valid. These tests will fail if any new duplicated exports appear.

In this release, we’ve removed all duplicated exports, so you should no longer encounter this issue.

pgEnum and mysqlEnum now can accept both strings and TS enums

If you provide a TypeScript enum, all your types will be inferred as that enum - so you can insert and retrieve enum values directly. If you provide a string union, it will work as before.

enum Test {
  a = 'a',
  b = 'b',
  c = 'c',
}

const tableWithTsEnums = mysqlTable('enums_test_case', {
  id: serial().primaryKey(),
  enum1: mysqlEnum(Test).notNull(),
  enum2: mysqlEnum(Test).default(Test.a),
});

await db.insert(tableWithTsEnums).values([
  { id: 1, enum1: Test.a, enum2: Test.b, enum3: Test.c },
  { id: 2, enum1: Test.a, enum3: Test.c },
  { id: 3, enum1: Test.a },
]);

const res = await db.select().from(tableWithTsEnums);

expect(res).toEqual([
  { id: 1, enum1: 'a', enum2: 'b', enum3: 'c' },
  { id: 2, enum1: 'a', enum2: 'a', enum3: 'c' },
  { id: 3, enum1: 'a', enum2: 'a', enum3: 'b' },
]);

Improvements

• Make inArray accept ReadonlyArray as a value - thanks @Zamiell
• Pass row type parameter to @planetscale/database's execute - thanks @ayrton
• New InferEnum type - thanks @totigm

Issues closed

• Add first-class support for TS native enums
• [FEATURE]: support const enums
• [BUG]: SyntaxError: The requested module 'drizzle-orm' does not provide an export named 'lte'

drizzle-kit@0.31.0

Features and improvements

Enum DDL improvements

For situations where you drop an enum value or reorder values in an enum, there is no native way to do this in PostgreSQL. To handle these cases, drizzle-kit used to:

• Change the column data types from the enum to text
• Drop the old enum
• Add the new enum
• Change the column data types back to the new enum

However, there were a few scenarios that weren’t covered: PostgreSQL wasn’t updating default expressions for columns when their data types changed

Therefore, for cases where you either change a column’s data type from an enum to some other type, drop an enum value, or reorder enum values, we now do the following:

• Change the column data types from the enum to text
• Set the default using the ::text expression
• Drop the old enum
• Add the new enum
• Change the column data types back to the new enum
• Set the default using the ::<new_enum> expression

esbuild version upgrade

For drizzle-kit we upgraded the version to latest (0.25.2), thanks @paulmarsicloud

Bug fixes

• [BUG]: Error on Malformed Array Literal - thanks @Kratious
• [BUG]: Postgres drizzle-kit: Error while pulling indexes from a table with json/jsonb deep field index - thanks @Kratious
• goog-vulnz flags CVE-2024-24790 in esbuild 0.19.7

drizzle-kit@0.30.6

Bug fixes

• [BUG]: d1 push locally is not working - thanks @mabels and @RomanNabukhotnyi
• [BUG] Cloudflare D1: drizzle-kit push is not working (error 7500 SQLITE_AUTH) - thanks @mabels and @RomanNabukhotnyi

0.41.0

• bigint, number modes for SQLite, MySQL, PostgreSQL, SingleStore decimal & numeric column types
• Changed behavior of sql-js query preparation to query prebuild instead of db-side prepare due to need to manually free prepared queries, removed .free() method
• Fixed MySQL, SingleStore varchar allowing not specifying length in config
• Fixed MySQL, SingleStore binary, varbinary data\type mismatches
• Fixed numeric\decimal data\type mismatches: #1290, #1453
• Fixed drizzle-studio + AWS Data Api connection issue: #3224
• Fixed isConfig utility function checking types of wrong fields
• Enabled supportBigNumbers in auto-created mysql2 driver instances
• Fixed custom schema tables querying in RQBv1: #4060
• Removed in-driver mapping for postgres types 1231 (numeric[]), 1115 (timestamp[]), 1185 (timestamp_with_timezone[]), 1187 (interval[]), 1182 (date[]), preventing precision loss and data\type mismatches
• Fixed SQLite buffer-mode blob sometimes returning number[]

0.40.1

Updates to neon-http for @neondatabase/serverless@1.0.0 - thanks @jawj

Starting from this version, drizzle-orm will be compatible with both @neondatabase/serverless <1.0 and >1.0

0.40.0

New Features

Added Gel dialect support and gel-js client support

Drizzle is getting a new Gel dialect with its own types and Gel-specific logic. In this first iteration, almost all query-building features have been copied from the PostgreSQL dialect since Gel is fully PostgreSQL-compatible. The only change in this iteration is the data types. The Gel dialect has a different set of available data types, and all mappings for these types have been designed to avoid any extra conversions on Drizzle's side. This means you will insert and select exactly the same data as supported by the Gel protocol.

Drizzle + Gel integration will work only through drizzle-kit pull. Drizzle won't support generate, migrate, or push features in this case. Instead, drizzle-kit is used solely to pull the Drizzle schema from the Gel database, which can then be used in your drizzle-orm queries.

The Gel + Drizzle workflow:

1. Use the gel CLI to manage your schema.
2. Use the gel CLI to generate and apply migrations to the database.
3. Use drizzle-kit to pull the Gel database schema into a Drizzle schema.
4. Use drizzle-orm with gel-js to query the Gel database.

Here is a small example of how to connect to Gel using Drizzle:

// Make sure to install the 'gel' package 
import { drizzle } from "drizzle-orm/gel";
import { createClient } from "gel";

const gelClient = createClient();
const db = drizzle({ client: gelClient });

const result = await db.execute('select 1');

and drizzle-gel schema definition

import { gelTable, uniqueIndex, uuid, smallint, text } from "drizzle-orm/gel-core"
import { sql } from "drizzle-orm"

export const users = gelTable("users", {
    id: uuid().default(sql`uuid_generate_v4()`).primaryKey(),
    age: smallint(),
    email: text().notNull(),
    name: text(),
});

On the drizzle-kit side you can now use dialect: "gel"

// drizzle.config.ts
import { defineConfig } from 'drizzle-kit';

export default defineConfig({
  dialect: 'gel',
});

For a complete Get Started tutorial you can use our new guides:

• Get Started with Drizzle and Gel in a new project
• Get Started with Drizzle and Gel in a existing project