fix(deps): update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@libsql/client (source)	^0.4.0-pre.7 -> ^0.15.0
drizzle-kit (source)	^0.20.13 -> ^0.31.0
drizzle-orm (source)	^0.29.3 -> ^0.42.0

---

Release Notes

libsql/libsql-client-ts (@​libsql/client)

v0.15.4

Compare Source

• Bump to latest libsql package.

v0.15.3

Compare Source

• Bump to latest libsql package.

v0.15.2

Compare Source

• Bump to latest libsql package.

v0.15.1

Compare Source

• Bump to latest libsql package.

v0.15.0

Compare Source

• Bump to latest libsql package.

v0.14.0

Compare Source

v0.13.0

Compare Source

v0.12.0

Compare Source

• Upgrade hrana-client-ts to latest 0.7.0 version which has stable isomorphic-fetch implementation (see https://github.com/libsql/hrana-client-ts/pull/19)

v0.11.0

Compare Source

• Upgrade libsql-js to latest 0.4.4 version which brings full vector search support for embedded replicas (see vector search documentation here: https://docs.turso.tech/features/ai-and-embeddings)

v0.10.0

Compare Source

• Add a migrate() API that can be used to do migrations on both schema databases and regular databases. It is mostly dedicated to schema migration tools.

v0.9.0

Compare Source

v0.8.1

Compare Source

• Fix embedded replica sync WAL index path name , which caused "No such file or directory" for local sync in some cases (#​244).

v0.8.0

Compare Source

• No changes from 0.8.0-pre.1.

v0.7.0

Compare Source

• Add configurable concurrency limit for parallel query execution
  (defaults to 20) to address socket hangup errors.

v0.6.2

Compare Source

• Fix compatibility issue with libSQL server versions that don't have migrations endpoint.

v0.6.1

Compare Source

• Add an option to batch() to wait for schema changes to finish when using shared schema.

v0.6.0

Compare Source

• Bump hrana client to 0.6.0, which uses native Node fetch(). Note that
  @libsql/client now requires Node 18 or later.

v0.5.6

Compare Source

• Bump libsql package dependency to 0.3.10 that adds wasm32 as
  supported CPU, which is needed for StackBlitz compatibility.

v0.5.5

Compare Source

• Bump @libsql/libsql-wasm-experimental" dependency to 0.0.2, which
  fixes a broken sqlite3_get_autocommit() export.

v0.5.4

Compare Source

• Bump libsql dependency to 0.3.9, which fixes symbol not found errors on Alpine.

v0.5.3

Compare Source

• Add syncInterval config option to enable periodic sync.
• Bump libsql dependency to 0.3.7, which switches default encryption cipher to aes256cbs.

v0.5.2

Compare Source

• Disable SQL statemen tracing in Wasm.

v0.5.1

Compare Source

• Update libsql package to 0.3.2, add encryptionCipher option, and switch default cipher to SQLCipher.

v0.5.0

Compare Source

• Add a encryptionKey config option, which enables encryption at rest for local database files.

drizzle-team/drizzle-orm (drizzle-kit)

v0.31.0

Compare Source

Breaking changes

Note: [email protected] can be used with [email protected] or higher. The same applies to Drizzle Kit. If you run a Drizzle Kit command, it will check and prompt you for an upgrade (if needed). You can check for Drizzle Kit updates. below

PostgreSQL indexes API was changed

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' })

New Features

🎉 "pg_vector" extension support

There is no specific code to create an extension inside the Drizzle schema. We assume that if you are using vector types, indexes, and queries, you have a PostgreSQL database with the pg_vector extension installed.

You can now specify indexes for pg_vector and utilize pg_vector functions for querying, ordering, etc.

Let's take a few examples of pg_vector indexes from the pg_vector docs and translate them to Drizzle

L2 distance, Inner product and Cosine distance

// CREATE INDEX ON items USING hnsw (embedding vector_l2_ops);
// CREATE INDEX ON items USING hnsw (embedding vector_ip_ops);
// CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);

const table = pgTable('items', {
    embedding: vector('embedding', { dimensions: 3 })
}, (table) => ({
    l2: index('l2_index').using('hnsw', table.embedding.op('vector_l2_ops'))
    ip: index('ip_index').using('hnsw', table.embedding.op('vector_ip_ops'))
    cosine: index('cosine_index').using('hnsw', table.embedding.op('vector_cosine_ops'))
}))

L1 distance, Hamming distance and Jaccard distance - added in pg_vector 0.7.0 version

// CREATE INDEX ON items USING hnsw (embedding vector_l1_ops);
// CREATE INDEX ON items USING hnsw (embedding bit_hamming_ops);
// CREATE INDEX ON items USING hnsw (embedding bit_jaccard_ops);

const table = pgTable('table', {
    embedding: vector('embedding', { dimensions: 3 })
}, (table) => ({
    l1: index('l1_index').using('hnsw', table.embedding.op('vector_l1_ops'))
    hamming: index('hamming_index').using('hnsw', table.embedding.op('bit_hamming_ops'))
    bit: index('bit_jaccard_index').using('hnsw', table.embedding.op('bit_jaccard_ops'))
}))

For queries, you can use predefined functions for vectors or create custom ones using the SQL template operator.

You can also use the following helpers:

import { l2Distance, l1Distance, innerProduct, 
          cosineDistance, hammingDistance, jaccardDistance } from 'drizzle-orm'

l2Distance(table.column, [3, 1, 2]) // table.column <-> '[3, 1, 2]'
l1Distance(table.column, [3, 1, 2]) // table.column <+> '[3, 1, 2]'

innerProduct(table.column, [3, 1, 2]) // table.column <#> '[3, 1, 2]'
cosineDistance(table.column, [3, 1, 2]) // table.column <=> '[3, 1, 2]'

hammingDistance(table.column, '101') // table.column <~> '101'
jaccardDistance(table.column, '101') // table.column <%> '101'

If pg_vector has some other functions to use, you can replicate implimentation from existing one we have. Here is how it can be done

export function l2Distance(
  column: SQLWrapper | AnyColumn,
  value: number[] | string[] | TypedQueryBuilder<any> | string,
): SQL {
  if (is(value, TypedQueryBuilder<any>) || typeof value === 'string') {
    return sql`${column} <-> ${value}`;
  }
  return sql`${column} <-> ${JSON.stringify(value)}`;
}

Name it as you wish and change the operator. This example allows for a numbers array, strings array, string, or even a select query. Feel free to create any other type you want or even contribute and submit a PR

Examples

Let's take a few examples of pg_vector queries from the pg_vector docs and translate them to Drizzle

import { l2Distance } from 'drizzle-orm';

// SELECT * FROM items ORDER BY embedding <-> '[3,1,2]' LIMIT 5;
db.select().from(items).orderBy(l2Distance(items.embedding, [3,1,2]))

// SELECT embedding <-> '[3,1,2]' AS distance FROM items;
db.select({ distance: l2Distance(items.embedding, [3,1,2]) })

// SELECT * FROM items ORDER BY embedding <-> (SELECT embedding FROM items WHERE id = 1) LIMIT 5;
const subquery = db.select({ embedding: items.embedding }).from(items).where(eq(items.id, 1));
db.select().from(items).orderBy(l2Distance(items.embedding, subquery)).limit(5)

// SELECT (embedding <#> '[3,1,2]') * -1 AS inner_product FROM items;
db.select({ innerProduct: sql`(${maxInnerProduct(items.embedding, [3,1,2])}) * -1` }).from(items)

// and more!

🎉 New PostgreSQL types: point, line

You can now use point and line from PostgreSQL Geometric Types

Type point has 2 modes for mappings from the database: tuple and xy.

• tuple will be accepted for insert and mapped on select to a tuple. So, the database Point(1,2) will be typed as [1,2] with drizzle.

• xy will be accepted for insert and mapped on select to an object with x, y coordinates. So, the database Point(1,2) will be typed as { x: 1, y: 2 } with drizzle

const items = pgTable('items', {
 point: point('point'),
 pointObj: point('point_xy', { mode: 'xy' }),
});

Type line has 2 modes for mappings from the database: tuple and abc.

• tuple will be accepted for insert and mapped on select to a tuple. So, the database Line{1,2,3} will be typed as [1,2,3] with drizzle.

• abc will be accepted for insert and mapped on select to an object with a, b, and c constants from the equation Ax + By + C = 0. So, the database Line{1,2,3} will be typed as { a: 1, b: 2, c: 3 } with drizzle.

const items = pgTable('items', {
 line: line('line'),
 lineObj: point('line_abc', { mode: 'abc' }),
});

🎉 Basic "postgis" extension support

There is no specific code to create an extension inside the Drizzle schema. We assume that if you are using postgis types, indexes, and queries, you have a PostgreSQL database with the postgis extension installed.

geometry type from postgis extension:

const items = pgTable('items', {
  geo: geometry('geo', { type: 'point' }),
  geoObj: geometry('geo_obj', { type: 'point', mode: 'xy' }),
  geoSrid: geometry('geo_options', { type: 'point', mode: 'xy', srid: 4000 }),
});

mode
Type geometry has 2 modes for mappings from the database: tuple and xy.

• tuple will be accepted for insert and mapped on select to a tuple. So, the database geometry will be typed as [1,2] with drizzle.
• xy will be accepted for insert and mapped on select to an object with x, y coordinates. So, the database geometry will be typed as { x: 1, y: 2 } with drizzle

type

The current release has a predefined type: point, which is the geometry(Point) type in the PostgreSQL PostGIS extension. You can specify any string there if you want to use some other type

Drizzle Kit updates: [email protected]

Release notes here are partially duplicated from [email protected]

New Features

🎉 Support for new types

Drizzle Kit can now handle:

• point and line from PostgreSQL
• vector from the PostgreSQL pg_vector extension
• geometry from the PostgreSQL PostGIS extension

🎉 New param in drizzle.config - extensionsFilters

The PostGIS extension creates a few internal tables in the public schema. This means that if you have a database with the PostGIS extension and use push or introspect, all those tables will be included in diff operations. In this case, you would need to specify tablesFilter, find all tables created by the extension, and list them in this parameter.

We have addressed this issue so that you won't need to take all these steps. Simply specify extensionsFilters with the name of the extension used, and Drizzle will skip all the necessary tables.

Currently, we only support the postgis option, but we plan to add more extensions if they create tables in the public schema.

The postgis option will skip the geography_columns, geometry_columns, and spatial_ref_sys tables

import { defineConfig } from 'drizzle-kit'

export default defaultConfig({
  dialect: "postgresql",
  extensionsFilters: ["postgis"],
})

Improvements

Update zod schemas for database credentials and write tests to all the positive/negative cases

• support full set of SSL params in kit config, provide types from node:tls connection

import { defineConfig } from 'drizzle-kit'

export default defaultConfig({
  dialect: "postgresql",
  dbCredentials: {
    ssl: true, //"require" | "allow" | "prefer" | "verify-full" | options from node:tls
  }
})

import { defineConfig } from 'drizzle-kit'

export default defaultConfig({
  dialect: "mysql",
  dbCredentials: {
    ssl: "", // string | SslOptions (ssl options from mysql2 package)
  }
})

Normilized SQLite urls for libsql and better-sqlite3 drivers

Those drivers have different file path patterns, and Drizzle Kit will accept both and create a proper file path format for each

Updated MySQL and SQLite index-as-expression behavior

In this release MySQL and SQLite will properly map expressions into SQL query. Expressions won't be escaped in string but columns will be

export const users = sqliteTable(
  'users',
  {
    id: integer('id').primaryKey(),
    email: text('email').notNull(),
  },
  (table) => ({
    emailUniqueIndex: uniqueIndex('emailUniqueIndex').on(sql`lower(${table.email})`),
  }),
);

-- before
CREATE UNIQUE INDEX `emailUniqueIndex` ON `users` (`lower("users"."email")`);

-- now
CREATE UNIQUE INDEX `emailUniqueIndex` ON `users` (lower("email"));

Bug Fixes

• [BUG]: multiple constraints not added (only the first one is generated) - #​2341
• Drizzle Studio: Error: Connection terminated unexpectedly - #​435
• Unable to run sqlite migrations local - #​432
• error: unknown option '--config' - #​423

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.30.6

Compare Source

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

v0.30.5

Compare Source

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.

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

v0.30.4

Compare Source

• Fix bug that generates incorrect syntax when introspect in mysql
• Fix a bug that caused incorrect syntax output when introspect in unsigned columns

v0.30.3

Compare Source

SingleStore push and generate improvements

As SingleStore did not support certain DDL statements before this release, you might encounter an error indicating that some schema changes cannot be applied due to a database issue. Starting from this version, drizzle-kit will detect such cases and initiate table recreation with data transfer between the tables

Bug fixes

• [BUG] If the index name is the same as the generated name, it will be empty and a type error will occur

v0.30.2

Compare Source

• Fix certificates generation utility for Drizzle Studio; [BUG]: [drizzle-kit]: drizzle-kit dependency on drizzle-studio perms error

v0.30.1

Compare Source

New Features

drizzle-kit export

To make drizzle-kit integration with other migration tools, like Atlas much easier, we've prepared a new command called export. It will translate your drizzle schema in SQL representation(DDL) statements and outputs to the console

// schema.ts
import { pgTable, serial, text } from 'drizzle-orm/pg-core'

export const users = pgTable('users', {
	id: serial('id').primaryKey(),
	email: text('email').notNull(),
	name: text('name')
});

Running

npx drizzle-kit export

will output this string to console

CREATE TABLE "users" (
        "id" serial PRIMARY KEY NOT NULL,
        "email" text NOT NULL,
        "name" text
);

By default, the only option for now is --sql, so the output format will be SQL DDL statements. In the future, we will support additional output formats to accommodate more migration tools

npx drizzle-kit export --sql

v0.30.0

Compare Source

Starting from this update, the PostgreSQL dialect will align with the behavior of all other dialects. It will no longer include IF NOT EXISTS, $DO, or similar statements, which could cause incorrect DDL statements to not fail when an object already exists in the database and should actually fail.

This change marks our first step toward several major upgrades we are preparing:

• An updated and improved migration workflow featuring commutative migrations, a revised folder structure, and enhanced collaboration capabilities for migrations.
• Better support for Xata migrations.
• Compatibility with CockroachDB (achieving full compatibility will only require removing serial fields from the migration folder).

v0.29.1

Compare Source

• Fix SingleStore generate migrations command

v0.29.0

Compare Source

New Dialects

🎉 SingleStore dialect is now available in Drizzle

Thanks to the SingleStore team for creating a PR with all the necessary changes to support the MySQL-compatible part of SingleStore. You can already start using it with Drizzle. The SingleStore team will also help us iterate through updates and make more SingleStore-specific features available in Drizzle

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

export default defineConfig({
  dialect: 'singlestore',
  out: './drizzle',
  schema: './src/db/schema.ts',
  dbCredentials: {
    url: process.env.DATABASE_URL!,
  },
});

You can check out our Getting started guides to try SingleStore!

New Drivers

🎉 SQLite Durable Objects driver is now available in Drizzle

You can now query SQLite Durable Objects in Drizzle!

For the full example, please check our Get Started Section

import 'dotenv/config';
import { defineConfig } from 'drizzle-kit';
export default defineConfig({
  out: './drizzle',
  schema: './src/db/schema.ts',
  dialect: 'sqlite',
  driver: 'durable-sqlite',
});

v0.28.1

Compare Source

Bug fixes

• Fixed typos in repository: thanks @​armandsalle, @​masto, @​wackbyte, @​Asher-JH, @​MaxLeiter
• fix: wrong dialect set in mysql/sqlite introspect

v0.28.0

Compare Source

Improvements

• Added an OHM static imports checker to identify unexpected imports within a chain of imports in the drizzle-kit repo. For example, it checks if drizzle-orm is imported before drizzle-kit and verifies if the drizzle-orm import is available in your project.
• Adding more columns to Supabase auth.users table schema - thanks @​nicholasdly

Bug Fixes

• [BUG]: [drizzle-kit]: Fix breakpoints option cannot be disabled - thanks @​klotztech
• [BUG]: drizzle-kit introspect: SMALLINT import missing and incorrect DECIMAL UNSIGNED handling - thanks @​L-Mario564
• Unsigned tinyints preventing migrations - thanks @​L-Mario564
• [BUG]: Can't parse float(8,2) from database (precision and scale and/or unsigned breaks float types) - thanks @​L-Mario564
• [BUG]: PgEnum generated migration doesn't escape single quotes - thanks @​L-Mario564
• [BUG]: single quote not escaped correctly in migration file - thanks @​L-Mario564
• [BUG]: Migrations does not escape single quotes - thanks @​L-Mario564
• [BUG]: Issue with quoted default string values - thanks @​L-Mario564
• [BUG]: SQl commands in wrong roder - thanks @​L-Mario564
• [BUG]: Time with precision in drizzle-orm/pg-core adds double-quotes around type - thanks @​L-Mario564
• [BUG]: Postgres push fails due to lack of quotes - thanks @​L-Mario564
• [BUG]: TypeError: Cannot read properties of undefined (reading 'compositePrimaryKeys') - thanks @​L-Mario564
• [BUG]: drizzle-kit introspect generates CURRENT_TIMESTAMP without sql operator on date column - thanks @​L-Mario564
• [BUG]: Drizzle-kit introspect doesn't pull correct defautl statement - thanks @​L-Mario564
• [BUG]: Problem on MacBook - This statement does not return data. Use run() instead - thanks @​L-Mario564
• [BUG]: Enum column names that are used as arrays are not quoted - thanks @​L-Mario564
• [BUG]: drizzle-kit generate ignores index operators - thanks @​L-Mario564
• dialect param config error message is wrong - thanks @​L-Mario564
• [BUG]: Error setting default enum field values - thanks @​L-Mario564
• [BUG]: drizzle-kit does not respect the order of columns configured in primaryKey() - thanks @​L-Mario564
• [BUG]: Cannot drop Unique Constraint MySQL - thanks @​L-Mario564

v0.27.2

Compare Source

• Fix [BUG]: Undefined properties when using drizzle-kit push
• Fix TypeError: Cannot read properties of undefined (reading 'isRLSEnabled')
• Fix push bugs, when pushing a schema with linked policy to a table from drizzle-orm/supabase

v0.27.1

Compare Source

• Fix: [BUG]: When using RLS policies and Views, the view is the last clause generated

v0.27.0

Compare Source

This version of drizzle-jit requires [email protected] to enable all new features

New Features

Row-Level Security (RLS)

With Drizzle, you can enable Row-Level Security (RLS) for any Postgres table, create policies with various options, and define and manage the roles those policies apply to.

Drizzle supports a raw representation of Postgres policies and roles that can be used in any way you want. This works with popular Postgres database providers such as Neon and Supabase.

In Drizzle, we have specific predefined RLS roles and functions for RLS with both database providers, but you can also define your own logic.

Enable RLS

If you just want to enable RLS on a table without adding policies, you can use .enableRLS()

As mentioned in the PostgreSQL documentation:

If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified.
Operations that apply to the whole table, such as TRUNCATE and REFERENCES, are not subject to row security.

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

export const users = pgTable('users', {
	id: integer(),
}).enableRLS();

If you add a policy to a table, RLS will be enabled automatically. So, there’s no need to explicitly enable RLS when adding policies to a table.

Roles

Currently, Drizzle supports defining roles with a few different options, as shown below. Support for more options will be added in a future release.

import { pgRole } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin', { createRole: true, createDb: true, inherit: true });

If a role already exists in your database, and you don’t want drizzle-kit to ‘see’ it or include it in migrations, you can mark the role as existing.

import { pgRole } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin').existing();

Policies

To fully leverage RLS, you can define policies within a Drizzle table.

In PostgreSQL, policies should be linked to an existing table. Since policies are always associated with a specific table, we decided that policy definitions should be defined as a parameter of pgTable

Example of pgPolicy with all available properties

import { sql } from 'drizzle-orm';
import { integer, pgPolicy, pgRole, pgTable } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin');

export const users = pgTable('users', {
	id: integer(),
}, (t) => [
	pgPolicy('policy', {
		as: 'permissive',
		to: admin,
		for: 'delete',
		using: sql``,
		withCheck: sql``,
	}),
]);

Link Policy to an existing table

There are situations where you need to link a policy to an existing table in your database.
The most common use case is with database providers like Neon or Supabase, where you need to add a policy
to their existing tables. In this case, you can use the .link() API

import { sql } from "drizzle-orm";
import { pgPolicy } from "drizzle-orm/pg-core";
import { authenticatedRole, realtimeMessages } from "drizzle-orm/supabase";

export const policy = pgPolicy("authenticated role insert policy", {
  for: "insert",
  to: authenticatedRole,
  using: sql``,
}).link(realtimeMessages);

Migrations

If you are using drizzle-kit to manage your schema and roles, there may be situations where you want to refer to roles that are not defined in your Drizzle schema. In such cases, you may want drizzle-kit to skip managing these roles without having to define each role in your drizzle schema and marking it with .existing().

In these cases, you can use entities.roles in drizzle.config.ts. For a complete reference, refer to the the drizzle.config.ts documentation.

By default, drizzle-kit does not manage roles for you, so you will need to enable this feature in drizzle.config.ts.

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

export default defineConfig({
  dialect: 'postgresql',
  schema: "./drizzle/schema.ts",
  dbCredentials: {
    url: process.env.DATABASE_URL!
  },
  verbose: true,
  strict: true,
  entities: {
    roles: true
  }
});

In case you need additional configuration options, let's take a look at a few more examples.

You have an admin role and want to exclude it from the list of manageable roles

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

export default defineConfig({
  ...
  entities: {
    roles: {
      exclude: ['admin']
    }
  }
});

You have an admin role and want to include it in the list of manageable roles

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

export default defineConfig({
  ...
  entities: {
    roles: {
      include: ['admin']
    }
  }
});

If you are using Neon and want to exclude Neon-defined roles, you can use the provider option

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

export default defineConfig({
  ...
  entities: {
    roles: {
      provider: 'neon'
    }
  }
});

If you are using Supabase and want to exclude Supabase-defined roles, you can use the provider option

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

export default defineConfig({
  ...
  entities: {
    roles: {
      provider: 'supabase'
    }
  }
});

You may encounter situations where Drizzle is slightly outdated compared to new roles specified by your database provider.
In such cases, you can use the provider option and exclude additional roles:

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

export default defineConfig({
  ...
  entities: {
    roles: {
      provider: 'supabase',
      exclude: ['new_supabase_role']
    }
  }
});

RLS on views

With Drizzle, you can also specify RLS policies on views. For this, you need to use security_invoker in the view's WITH options. Here is a small example:

...

export const roomsUsersProfiles = pgView("rooms_users_profiles")
  .with({
    securityInvoker: true,
  })
  .as((qb) =>
    qb
      .select({
        ...getTableColumns(roomsUsers),
        email: profiles.email,
      })
      .from(roomsUsers)
      .innerJoin(profiles, eq(roomsUsers.userId, profiles.id))
  );

Using with Neon

The Neon Team helped us implement their vision of a wrapper on top of our raw policies API. We defined a specific
/neon import with the crudPolicy function that includes predefined functions and Neon's default roles.

Here's an example of how to use the crudPolicy function:

import { crudPolicy } from 'drizzle-orm/neon';
import { integer, pgRole, pgTable } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin');

export const users = pgTable('users', {
	id: integer(),
}, (t) => [
	crudPolicy({ role: admin, read: true, modify: false }),
]);

This policy is equivalent to:

import { sql } from 'drizzle-orm';
import { integer, pgPolicy, pgRole, pgTable } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin');

export const users = pgTable('users', {
	id: integer(),
}, (t) => [
	pgPolicy(`crud-${admin.name}-policy-insert`, {
		for: 'insert',
		to: admin,
		withCheck: sql`false`,
	}),
	pgPolicy(`crud-${admin.name}-policy-update`, {
		for: 'update',
		to: admin,
		using: sql`false`,
		withCheck: sql`false`,
	}),
	pgPolicy(`crud-${admin.name}-policy-delete`, {
		for: 'delete',
		to: admin,
		using: sql`false`,
	}),
	pgPolicy(`crud-${admin.name}-policy-select`, {
		for: 'select',
		to: admin,
		using: sql`true`,
	}),
]);

Neon exposes predefined authenticated and anaonymous roles and related functions. If you are using Neon for RLS, you can use these roles, which are marked as existing, and the related functions in your RLS queries.

// drizzle-orm/neon
export const authenticatedRole = pgRole('authenticated').existing();
export const anonymousRole = pgRole('anonymous').existing();

export const authUid = (userIdColumn: AnyPgColumn) => sql`(select auth.user_id() = ${userIdColumn})`;

For example, you can use the Neon predefined roles and functions like this:

import { sql } from 'drizzle-orm';
import { authenticatedRole } from 'drizzle-orm/neon';
import { integer, pgPolicy, pgRole, pgTable } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin');

export const users = pgTable('users', {
	id: integer(),
}, (t) => [
	pgPolicy(`policy-insert`, {
		for: 'insert',
		to: authenticatedRole,
		withCheck: sql`false`,
	}),
]);

Using with Supabase

We also have a /supabase import with a set of predefined roles marked as existing, which you can use in your schema.
This import will be extended in a future release with more functions and helpers to make using RLS and Supabase simpler.

// drizzle-orm/supabase
export const anonRole = pgRole('anon').existing();
export const authenticatedRole = pgRole('authenticated').existing();
export const serviceRole = pgRole('service_role').existing();
export const postgresRole = pgRole('postgres_role').existing();
export const supabaseAuthAdminRole = pgRole('supabase_auth_admin').existing();

For example, you can use the Supabase predefined roles like this:

import { sql } from 'drizzle-orm';
import { serviceRole } from 'drizzle-orm/supabase';
import { integer, pgPolicy, pgRole, pgTable } from 'drizzle-orm/pg-core';

export const admin = pgRole('admin');

export const users = pgTable('users', {
	id: integer(),
}, (t) => [
	pgPolicy(`policy-insert`, {
		for: 'insert',
		to: serviceRole,
		withCheck: sql`false`,
	}),
]);

The /supabase import also includes predefined tables and functions that you can use in your application

// drizzle-orm/supabase

const auth = pgSchema('auth');
export const authUsers = auth.table('users', {
	id: uuid().primaryKey().notNull(),
});

const realtime = pgSchema('realtime');
export const realtimeMessages = realtime.table(
	'messages',
	{
		id: bigserial({ mode: 'bigint' }).primaryKey(),
		topic: text().notNull(),
		extension: text({
			enum: ['presence', 'broadcast', 'postgres_changes'],
		}).notNull(),
	},
);

export const authUid = sql`(select auth.uid())`;
export const realtimeTopic = sql`realtime.topic()`;

This allows you to use it in your code, and Drizzle Kit will treat them as existing databases,
using them only as information to connect to other entities

import { foreignKey, pgPolicy, pgTable, text, uuid } from "drizzle-orm/pg-core";
import { sql } from "drizzle-orm/sql";
import { authenticatedRole, authUsers } from "drizzle-orm/supabase";

export const profiles = pgTable(
  "profiles",
  {
    id: uuid().primaryKey().notNull(),
    email: text().notNull(),
  },
  (table) => [
    foreignKey({
      columns: [table.id],
	  // reference to the auth table from Supabase
      foreignColumns: [authUsers.id],
      name: "profiles_id_fk",
    }).onDelete("cascade"),
    pgPolicy("authenticated can view all profiles", {
      for: "select",
	  // using predefined role from Supabase
      to: authenticatedRole,
      using: sql`true`,
    }),
  ]
);

Let's check an example of adding a policy to a table that exists in Supabase

import { sql } from "drizzle-orm";
import { pgPolicy } from "drizzle-orm/pg-core";
import { authenticatedRole, realtimeMessages } from "drizzle-orm/supabase";

export const policy = pgPolicy("authenticated role insert policy", {
  for: "insert",
  to: authenticatedRole,
  using: sql``,
}).link(realtimeMessages);

Bug fixes

• [BUG]: Studio + mysql default mode, wrong format related timezone
• [BUG]: Drizzle Studio CORS error
• [BUG]: TIMESTAMPS showing up incorrectly on drizzle studio

v0.26.2

Compare Source

• Updated internal versions for the drizzle-kit and drizzle-orm packages. Changes were introduced in the last minor release, and you are required to upgrade both packages to ensure they work as expected

v0.26.1

Compare Source

• Fix data is malformed for views

v0.26.0

Compare Source

While writing this update, we found one bug that may occur with views in MySQL and SQLite, so please use the [email protected] release

New Features

Checks support in drizzle-kit

You can use drizzle-kit to manage your check constraint defined in drizzle-orm schema definition

For example current drizzle table:

import { sql } from "drizzle-orm";
import { check, pgTable } from "drizzle-orm/pg-core";

export const users = pgTable(
  "users",
  (c) => ({
    id: c.uuid().defaultRandom().primaryKey(),
    username: c.text().notNull(),
    age: c.integer(),
  }),
  (table) => ({
    checkConstraint: check("age_check", sql`${table.age} > 21`),
  })
);

will be generated into

CREATE TABLE IF NOT EXISTS "users" (
  "id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
  "username" text NOT NULL,
  "age" integer,
  CONSTRAINT "age_check" CHECK ("users"."age" > 21)
);

The same is supported in all dialects

Limitations

• generate will work as expected for all check constraint changes.
• push will detect only check renames and will recreate the constraint. All other changes to SQL won't be detected and will be ignored.

So, if you want to change the constraint's SQL definition using only push, you would need to manually comment out the constraint, push, then put it back with the new SQL definition and push one more time.

Views support in drizzle-kit

You can use drizzle-kit to manage your views defined in drizzle-orm schema definition. It will work with all existing dialects and view options

PostgreSQL

For example current drizzle table:

import { sql } from "drizzle-orm";
import {
  check,
  pgMaterializedView,
  pgTable,
  pgView,
} from "drizzle-orm/pg-core";

export const users = pgTable(
  "users",
  (c) => ({
    id: c.uuid().defaultRandom().primaryKey(),
    username: c.text().notNull(),
    age: c.integer(),
  }),
  (table) => ({
    checkConstraint: check("age_check", sql`${table.age} > 21`),
  })
);

export const simpleView = pgView("simple_users_view").as((qb) =>
  qb.select().from(users)
);

export const materializedView = pgMaterializedView(
  "materialized_users_view"
).as((qb) => qb.select().from(users));

will be generated into

CREATE TABLE IF NOT EXISTS "users" (
  "id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
  "username" text NOT NULL,
  "age" integer,
  CONSTRAINT "age_check" CHECK ("users"."age" > 21)
);

CREATE VIEW "public"."simple_users_view" AS (select "id", "username", "age" from "users");

CREATE MATERIALIZED VIEW "public"."materialized_users_view" AS (select "id", "username", "age" from "users");

Views supported in all dialects, but materialized views are supported only in PostgreSQL

Limitations

• generate will work as expected for all view changes
• push limitations:

1. If you want to change the view's SQL definition using only push, you would need to manually comment out the view, push, then put it back with the new SQL definition and push one more time.

Updates for PostgreSQL enums behavior

We've updated enum behavior in Drizzle with PostgreSQL:

• Add value after or before in enum: With this change, Drizzle will now respect the order of values in the enum and allow adding new values after or before a specific one.

• Support for dropping a value from an enum: In this case, Drizzle will attempt to alter all columns using the enum to text, then drop the existing enum and create a new one with the updated set of values. After that, all columns previously using the enum will be altered back to the new enum.

If the deleted enum value was used by a column, this process will result in a database error.

• Support for dropping an enum

• Support for moving enums between schemas

• Support for renaming enums

v0.25.0

Compare Source

Breaking changes and migrate guide for Turso users

If you are using Turso and libsql, you will need to upgrade your drizzle.config and @libsql/client package.

1. This version of drizzle-orm will only work with @libsql/[email protected] or higher if you are using the migrate function. For other use cases, you can continue using previous versions(But the suggestion is to upgrade)
   To install the latest version, use the command:

npm i @​libsql/client@latest

2. Previously, we had a common drizzle.config for SQLite and Turso users, which allowed a shared strategy for both dialects. Starting with this release, we are introducing the turso dialect in drizzle-kit. We will evolve and improve Turso as a separate dialect with its own migration strategies.

Before

import { defineConfig } from "drizzle-kit";

export default defineConfig({
  dialect: "sqlite",
  schema: "./schema.ts",
  out: "./drizzle",
  dbCredentials: {
    url: "database.db",
  },
  breakpoints: true,
  verbose: true,
  strict: true,
});

After

import { defineConfig } from "drizzle-kit";

export default defineConfig({
  dialect: "turso",
  schema: "./schema.ts",
  out: "./drizzle",
  dbCredentials: {
    url: "database.db",
  },
  breakpoints: true,
  verbose: true,
  strict: true,
});

If you are using only SQLite, you can use dialect: "sqlite"

LibSQL/Turso and Sqlite migration updates

SQLite "generate" and "push" statements updates

Starting from this release, we will no longer generate comments like this:

      '/*\n SQLite does not support "Changing existing column type" out of the box, we do not generate automatic migration for that, so it has to be done manually'
      + '\n Please refer to: https://www.techonthenet.com/sqlite/tables/alter_table.php'
      + '\n                  https://www.sqlite.org/lang_altertable.html'
      + '\n                  https://stackoverflow.com/questions/2083543/modify-a-columns-type-in-sqlite3'
      + "\n\n Due to that we don't generate migration automatically and it has to be done manually"
      + '\n*/'

We will generate a set of statements, and you can decide if it's appropriate to create data-moving statements instead. Here is an example of the SQL file you'll receive now:

PRAGMA foreign_keys=OFF;
--> statement-breakpoint
CREATE TABLE `__new_worker` (
  `id` integer PRIMARY KEY NOT NULL,
  `name` text NOT NULL,
  `salary` text NOT NULL,
  `job_id` integer,
  FOREIGN KEY (`job_id`) REFERENCES `job`(`id`) ON UPDATE no action ON DELETE no action
);
--> statement-breakpoint
INSERT INTO `__new_worker`("id", "name", "salary", "job_id") SELECT "id", "name", "salary", "job_id" FROM `worker`;
--> statement-breakpoint
DROP TABLE `worker`;
--> statement-breakpoint
ALTER TABLE `__new_worker` RENAME TO `worker`;
--> statement-breakpoint
PRAGMA foreign_keys=ON;

LibSQL/Turso "generate" and "push" statements updates

Since LibSQL supports more ALTER statements than SQLite, we can generate more statements without recreating your schema and moving all the data, which can be potentially dangerous for production environments.

LibSQL and Turso will now have a separate dialect in the Drizzle config file, meaning that we will evolve Turso and LibSQL independently from SQLite and will aim to support as many features as Turso/LibSQL offer.

With the updated LibSQL migration strategy, you will have the ability to:

• Change Data Type: Set a new data type for existing columns.
• Set and Drop Default Values: Add or remove default values for existing columns.
• Set and Drop NOT NULL: Add or remove the NOT NULL constraint on existing columns.
• Add References to Existing Columns: Add foreign key references to existing columns

You can find more information in the LibSQL documentation

LIMITATIONS

• Dropping foreign key will cause table recreation.

This is because LibSQL/Turso does not support dropping this type of foreign key.

CREATE TABLE `users` (
  `id` integer NOT NULL,
  `name` integer,
  `age` integer PRIMARY KEY NOT NULL
  FOREIGN KEY (`name`) REFERENCES `users1`("id") ON UPDATE no act

</details>

---

### Configuration

📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.

♻ **Rebasing**: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://redirect.github.com/renovatebot/renovate/discussions) if that's undesired.

---

 - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/fmhy/mix).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4xNzMuMCIsInVwZGF0ZWRJblZlciI6IjM5LjIzOC4wIiwidGFyZ2V0QnJhbmNoIjoidHJ1bmsifQ==-->