0.44.0
drizzle-team/drizzle-orm0.44.0May 28, 2025by github-actions[bot]
AI Summary
This release introduces a new DrizzleQueryError that wraps database driver errors with useful debugging information including stack traces, generated SQL strings, parameters, and original driver errors. It also adds a new caching module with Upstash Redis integration, allowing explicit or global caching strategies with full cache invalidation support.
Key Highlights
- New DrizzleQueryError provides better error debugging with stack traces, SQL strings, parameters, and original driver errors
- New caching module with Upstash Redis native integration
- Explicit caching strategy (global: false) as default - no automatic caching
- Optional global caching (global: true) for all select queries
- Custom cache implementation API with get, put, mutate methods and invalidation support
New Features
- DrizzleQueryError - wraps all database driver errors with comprehensive debugging information
- Cache module with upstashCache() for Redis-based caching
- Two caching strategies: 'explicit' (per-query via .$withCache()) and 'all' (global)
- Cache invalidation via tables and tags through onMutate() callback
- Custom cache implementation support via Cache class with get, put, strategy, and onMutate methods
Full Release Notes
## 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
```ts
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](https://orm.drizzle.team/docs/cache#custom-cache)
```ts
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](https://orm.drizzle.team/docs/cache#cache-usage-examples)