v0.22.0-beta

New Features

🎉 Full support for indexes in PostgreSQL

The previous Drizzle+PostgreSQL indexes API was incorrect and was not aligned with the PostgreSQL documentation. The good thing is that it was not used in queries, and drizzle-kit didn't support all properties for indexes. This means we can now change the API to the correct one and provide full support for it in drizzle-kit

Previous API

• No way to define SQL expressions inside .on.
• .using and .on in our case are the same thing, so the API is incorrect here.
• .asc(), .desc(), .nullsFirst(), and .nullsLast() should be specified for each column or expression on indexes, but not on an index itself.

// Index declaration reference
index('name')
  .on(table.column1, table.column2, ...) or .onOnly(table.column1, table.column2, ...)
  .concurrently()
  .using(sql``) // sql expression
  .asc() or .desc()
  .nullsFirst() or .nullsLast()
  .where(sql``) // sql expression

Current API

// First example, with `.on()`
index('name')
  .on(table.column1.asc(), table.column2.nullsFirst(), ...) or .onOnly(table.column1.desc().nullsLast(), table.column2, ...)
  .concurrently()
  .where(sql``)
  .with({ fillfactor: '70' })

// Second Example, with `.using()`
index('name')
  .using('btree', table.column1.asc(), sql`lower(${table.column2})`, table.column1.op('text_ops'))
  .where(sql``) // sql expression
  .with({ fillfactor: '70' })

How push and generate works for indexes

Limitations

You should specify a name for your index manually if you have an index on at least one expression

Example

index().on(table.id, table.email) // will work well and name will be autogeneretaed
index('my_name').on(table.id, table.email) // will work well

// but

index().on(sql`lower(${table.email})`) // error
index('my_name').on(sql`lower(${table.email})`) // will work well

Push won't generate statements if these fields(list below) were changed in an existing index:

• expressions inside .on() and .using()
• .where() statements
• operator classes .op() on columns

If you are using push workflows and want to change these fields in the index, you would need to:

• Comment out the index
• Push
• Uncomment the index and change those fields
• Push again

For the generate command, drizzle-kit will be triggered by any changes in the index for any property in the new drizzle indexes API, so there are no limitations here.

v0.21.4

bug fixes

• fix node-pg pool connection halting, regression introduced in previous release while migrating from client to pool with max 1 connection

v0.21.3

Cloudflare D1 HTTP API support 🎉
Drizzle Chrome Extension now has support for Cloudflare D1!

Drizzle Kit now lets you run migrate, push, introspect and studio commands using Cloudflare D1 HTTP API, you just need to update connection params in drizzle.config.ts:

dialect: "sqlite",
+ driver: "d1-http",
dbCredentials: {
+  accountId: "...",
+  databaseId: "...",
+  token: "...",
}

You can find accountId, databaseId and token in Cloudflare dashboard
To get accountId go to Workers & Pages -> Overview -> copy Account ID from the right sidebar
To get databaseId open D1 database you want to connect to and copy Database ID
To get token go to My profile -> API Tokens and create token with D1 edit permissions

Bug fixes

• fix broken check command #2284
• fix sqlite push error #395
• fix rename column in composite pk #2344
• process.exit(1) on error #2354
• fix non-detected changes #2345 #2336
• fix constraint changes #2327
• fix push bug #2324
• d1 driver support #2292
• column renames alongside table renames in postgres dialect #2346
• generate error #420
• remove schemas from mysql migration statements #2310

v0.21.2

Bug fixes

A list of regressions after 0.21.0 that were fixed (there are more, and those should be fixed in the next patch releases):

• SQLite generate and push were not detecting new columns added.
• Timestamps with precision in Postgres were always detected as a change on push
• Unique constraints for PostgreSQL were not generated and pushed
• When adding columns to SQLite, table name was not escaped

Tickets that were closed

• 🐛 [BUG]:"drizzle-kit generate" doesn't generate a migration file when a column is added - 2307
• 🐛 [BUG]: Unique constraint is not added to the change - 2302
• 🐛 [bug]: drizzle-kit push is not detecting changes correctly (Turso) - #397

v0.21.1

Drizzle Studio support for per-database preferences

When connecting to different databases with Drizzle Local Studio, we will store all preferences such as selected tabs, hidden columns, pagination, etc., separately for each database

Drizzle Studio support for advanced bug report context

Now you can assist us in debugging Drizzle Studio errors. No more need to say, "Please share your schema with us"; just click a button, download the bug report, and send it to us!

v0.21.0

Breaking changes

❗ Snapshots Upgrade

All PostgreSQL and SQLite-generated snapshots will be upgraded to version 6. You will be prompted to upgrade them by running drizzle-kit up

❗ Removing :dialect from drizzle-kit cli commands

You can now just use commands, like:

• drizzle-kit generate
• drizzle-kit push
• etc.

without specifying dialect. This param is moved to drizzle.config.ts

❗ drizzle.config update

• dialect is now mandatory; specify which database dialect you are connecting to. Options include mysql, postgresql, or sqlite.
• driver has become optional and will have a specific driver, each with a different configuration of dbCredentials. Available drivers are:
  • aws-data-api
  • turso
  • d1-http - currently WIP
  • expo
• url - a unified parameter for the previously existing connectionString and uri.
• migrations - a new object parameter to specify a custom table and schema for the migrate command:
  • table - the custom table where drizzle will store migrations.
  • schema - the custom schema where drizzle will store migrations (Postgres only).

Usage examples for all new and updated commands

import { defineConfig } from "drizzle-kit"

export default defineConfig({
    dialect: "sqlite", // "postgresql" | "mysql"
    driver: "turso"
    dbCredentials: {
        url: ""
    },
    migration: {
        table: "migrations",
        schema: "public"
    }
})

Drizzle driver selection follows the current strategy:

If a driver is specified, use this driver for querying.

If no driver is specified:

• For postgresql dialect, Drizzle will:

  • Check if the pg driver is installed and use it.
  • If not, try to find the postgres driver and use it.
  • If still not found, try to find @vercel/postgres.
  • Then try @neondatabase/serverless.
  • If nothing is found, an error will be thrown.

• For mysql dialect, Drizzle will:

  • Check if the mysql2 driver is installed and use it.
  • If not, try to find @planetscale/database and use it.
  • If nothing is found, an error will be thrown.

• For sqlite dialect, Drizzle will:

  • Check if the @libsql/client driver is installed and use it.
  • If not, try to find better-sqlite3 and use it.
  • If nothing is found, an error will be thrown

❗ MySQL schemas/database are no longer supported by drizzle-kit

Drizzle Kit won't handle any schema changes for additional schemas/databases in your drizzle schema file

New Features

🎉 Pull relations

Drizzle will now pull relations from the database by extracting foreign key information and translating it into a relations object. You can view the relations.ts file in the out folder after introspection is complete

For more info about relations, please check the docs

🎉 Custom name for generated migrations

To specify a name for your migration you should use --name <name>

Usage

drizzle-kit generate --name init_db

🎉 New command migrate

You can now apply generated migrations to your database directly from drizzle-kit

Usage

drizzle-kit migrate

By default, drizzle-kit will store migration data entries in the __drizzle_migrations table and, in the case of PostgreSQL, in a drizzle schema. If you want to change this, you will need to specify the modifications in drizzle.config.ts.

import { defineConfig } from "drizzle-kit"

export default defineConfig({
    migrations: {
        table: "migrations",
        schema: "public"
    }
})

How to migrate from 0.20.18 to 0.21.0

1. Remove all :dialect prefixes from your Drizzle-Kit commands.

Example: Change drizzle-kit push:mysql to drizzle-kit push.

2. Update your drizzle.config.ts file:

• Add dialect to drizzle.config.ts. It is now mandatory and can be 'postgresql', 'mysql', or 'sqlite'.
• Add driver to drizzle.config.ts ONLY if you are using aws-data-api, turso, d1-http(WIP), or expo. Otherwise, you can remove the driver from drizzle.config.ts.
• If you were using connectionString or uri in dbCredentials, you should now use url.

import { defineConfig } from "drizzle-kit"

export default defineConfig({
    dialect: "sqlite", // "postgresql" | "mysql"
    driver: "turso" // optional and used only if `aws-data-api`, `turso`, `d1-http`(WIP) or `expo` are used
    dbCredentials: {
        url: ""
    }
})

3. If you are using PostgreSQL and had migrations generated in your project, please run drizzle-kit up so Drizzle can upgrade all the snapshots to version 6.

0.21.0-beta

This pre-release is available under drizzle-kit@beta

Breaking changes

❗ Snapshots Upgrade

All PostgreSQL-generated snapshots will be upgraded to version 6. You will be prompted to upgrade them by running drizzle-kit up

❗ Removing :dialect from drizzle-kit cli commands

You can now just use commands, like:

• drizzle-kit generate
• drizzle-kit push
• etc.

without specifing dialect. This param is moved to drizzle.config.ts

❗ drizzle.config update

• dialect is now mandatory; specify which database dialect you are connecting to. Options include mysql, postgresql, or sqlite.
• driver has become optional and will have a specific driver, each with a different configuration of dbCredentials. Available drivers are:
  • aws-data-api - currently, Studio is a work in progress before the latest. All other commands work as expected.
  • turso
  • d1-http - currently WIP
  • expo
• url - a unified parameter for the previously existing connectionString and uri.
• migrations - a new object parameter to specify a custom table and schema for the migrate command:
  • table - the custom table where drizzle will store migrations.
  • schema - the custom schema where drizzle will store migrations (Postgres only).

Usage examples for all new and updated commands

import { defineConfig } from "drizzle-kit"

export default defineConfig({
    dialect: "sqlite", // "postgresql" | "mysql"
    driver: "turso"
    dbCredentials: {
        url: ""
    },
    migration: {
        table: "migrations",
        schema: "public"
    }
})

Drizzle driver selection follows the current strategy:

If a driver is specified, use this driver for querying.

If no driver is specified:

• For postgresql dialect, Drizzle will:

  • Check if the pg driver is installed and use it.
  • If not, try to find the postgres driver and use it.
  • If still not found, try to find @vercel/postgres.
  • Then try @neondatabase/serverless.
  • If nothing is found, an error will be thrown.

• For mysql dialect, Drizzle will:

  • Check if the mysql2 driver is installed and use it.
  • If not, try to find @planetscale/database and use it.
  • If nothing is found, an error will be thrown.

• For sqlite dialect, Drizzle will:

  • Check if the @libsql/client driver is installed and use it.
  • If not, try to find better-sqlite3 and use it.
  • If nothing is found, an error will be thrown

❗ MySQL schemas/database are no longer supported by drizzle-kit

Drizzle Kit won't handle any schema changes for additional schemas/databases in your drizzle schema file

New Features

🎉 Pull relations

Drizzle will now pull relations from the database by extracting foreign key information and translating it into a relations object. You can view the relations.ts file in the out folder after introspection is complete

For more info about relations, please check the docs

🎉 Custom name for generated migrations

To specify a name for your migration you should use --name <name>

Usage

drizzle-kit generate --name init_db

🎉 New command migrate

You can now apply generated migrations to your database directly from drizzle-kit

Usage

drizzle-kit migrate

By default, drizzle-kit will store migration data entries in the __drizzle_migrations table and, in the case of PostgreSQL, in a drizzle schema. If you want to change this, you will need to specify the modifications in drizzle.config.ts.

import { defineConfig } from "drizzle-kit"

export default defineConfig({
    migration: {
        table: "migrations",
        schema: "public"
    }
})

0.20.18

• Fixed the recurring issue with FK recreations on PlanetScale by using the push:mysql command

0.20.17

• Fixed $default values to work with new local drizzle studio. You will be forced to upgrade drizzle-kit

v0.20.16

• Fixed 0.20.15 bugs and force to upgrade from studio UI