|
| 1 | +--- |
| 2 | +title: "Database connections" |
| 3 | +sidebarTitle: "Database connections" |
| 4 | +description: "Connect a database to your tasks: where to create the client, how to size the pool for your provider's connection limit, and how to release connections so you don't run out." |
| 5 | +--- |
| 6 | + |
| 7 | +Tasks connect to your database from their own process. This guide covers the recommended setup for each client, how to size the pool against your provider's connection limit, and how to release connections at waits. |
| 8 | + |
| 9 | +## Create the client once |
| 10 | + |
| 11 | +Create the client at module scope and import it wherever you query. The worker loads the module once per process, so every run on that worker reuses the same pool. Keep the pool small (see [Size the pool](#size-the-pool)) and attach an error handler, since an idle connection can error asynchronously and an unhandled `error` event crashes the worker. |
| 12 | + |
| 13 | +<CodeGroup> |
| 14 | +```ts lib/db.ts (node-postgres) |
| 15 | +import { Pool } from "pg"; |
| 16 | + |
| 17 | +export const pool = new Pool({ |
| 18 | + connectionString: process.env.DATABASE_URL, |
| 19 | + max: 1, // one connection per run; raise only for in-run parallel queries |
| 20 | +}); |
| 21 | + |
| 22 | +pool.on("error", (err) => console.error("pg pool error", err)); |
| 23 | +``` |
| 24 | + |
| 25 | +```ts lib/db.ts (Prisma) |
| 26 | +import { PrismaPg } from "@prisma/adapter-pg"; |
| 27 | +import { PrismaClient } from "./generated/prisma/client"; |
| 28 | + |
| 29 | +const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL, max: 1 }); |
| 30 | + |
| 31 | +export const prisma = new PrismaClient({ adapter }); |
| 32 | +``` |
| 33 | + |
| 34 | +```ts lib/db.ts (Drizzle) |
| 35 | +import { drizzle } from "drizzle-orm/node-postgres"; |
| 36 | +import { Pool } from "pg"; |
| 37 | + |
| 38 | +const pool = new Pool({ connectionString: process.env.DATABASE_URL, max: 1 }); |
| 39 | +pool.on("error", (err) => console.error("pg pool error", err)); |
| 40 | + |
| 41 | +export const db = drizzle({ client: pool }); |
| 42 | +``` |
| 43 | + |
| 44 | +```ts lib/db.ts (MongoDB) |
| 45 | +import { MongoClient } from "mongodb"; |
| 46 | + |
| 47 | +export const client = new MongoClient(process.env.DATABASE_URL!, { maxPoolSize: 5 }); |
| 48 | +``` |
| 49 | +</CodeGroup> |
| 50 | + |
| 51 | +<Note> |
| 52 | +Import this one client everywhere. Don't create a client inside `run()` or a lifecycle hook, which opens a new pool on every run, and don't store one in [`chat.local`](/ai-chat/chat-local), which is per-run state that gets serialized into subtasks. |
| 53 | +</Note> |
| 54 | + |
| 55 | +## Size the pool |
| 56 | + |
| 57 | +A run uses connections only while it is actively executing. Queued, waiting, and suspended runs use none. So the connections in use at any moment are: |
| 58 | + |
| 59 | +> concurrent executing runs × pool size per run |
| 60 | +
|
| 61 | +Set the pool small. A task usually runs its queries in sequence, so one connection per run (`max: 1`) is enough for node-postgres, Prisma, and Drizzle; raise it only when a single run issues queries in parallel. The MongoDB driver shares one pool across all operations, so keep `maxPoolSize` in the low single digits. Each client's out-of-the-box default is far larger: |
| 62 | + |
| 63 | +| Client | Default pool size | |
| 64 | +| --- | --- | |
| 65 | +| [node-postgres (`pg`)](https://node-postgres.com/guides/pool-sizing) | 10 | |
| 66 | +| postgres-js | 10 | |
| 67 | +| [Prisma (v7, `pg` adapter)](https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections/connection-pool) | 10 (the adapter's `pg` default) | |
| 68 | +| Drizzle (node-postgres) | 10 (the underlying `pg` pool) | |
| 69 | +| [MongoDB driver](https://www.mongodb.com/docs/drivers/node/current/connect/connection-options/connection-pools/) | 100 (`maxPoolSize`) | |
| 70 | + |
| 71 | +Keep `concurrent runs × pool size` under your provider's connection limit, and cap how many runs execute at once with [concurrency limits](/queue-concurrency) so runs queue instead of overrunning the database. Direct connection limits for common Postgres providers: |
| 72 | + |
| 73 | +| Provider | Direct connection limit | |
| 74 | +| --- | --- | |
| 75 | +| [PostgreSQL (self-hosted)](https://www.postgresql.org/docs/current/runtime-config-connection.html) | `max_connections`, default `100` | |
| 76 | +| [Supabase](https://supabase.com/docs/guides/platform/compute-and-disk) | `60` (Nano/Micro) up to `500` (16XL), by compute size | |
| 77 | +| [Neon](https://neon.com/docs/connect/connection-pooling) | `104` (0.25 CU) up to `4000` (capped at 9 CU and above), by compute size | |
| 78 | +| [AWS RDS / Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Limits.html) | `LEAST(DBInstanceClassMemory / 9531392, 5000)`, ~5 reserved for superusers | |
| 79 | +| [PlanetScale Postgres](https://planetscale.com/docs/postgres/connecting) | set per cluster size (Cluster, then Parameters, then `max_connections`) | |
| 80 | + |
| 81 | +[MongoDB Atlas](https://www.mongodb.com/docs/atlas/reference/atlas-limits/) limits connections per node: `500` on Free and Flex, `1500` on M10, `3000` on M20. |
| 82 | + |
| 83 | +When `concurrent runs × pool size` approaches these numbers, connect through a pooler instead. |
| 84 | + |
| 85 | +## Use a connection pooler |
| 86 | + |
| 87 | +A pooler (PgBouncer, RDS Proxy, Supavisor, Prisma Accelerate) sits between your tasks and the database and multiplexes many client connections onto a few backend connections. Point your connection string at the pooler's endpoint and the ceiling rises without changing your code. Use one when many runs execute concurrently, and for chat agents. |
| 88 | + |
| 89 | +| Provider | Pooled endpoint | Pooled client limit | |
| 90 | +| --- | --- | --- | |
| 91 | +| [Supabase Supavisor](https://supabase.com/docs/guides/database/connection-management) | port `6543` (transaction mode) | `200` (Nano) up to `12,000` (16XL) | |
| 92 | +| [Neon](https://neon.com/docs/connect/connection-pooling) | add `-pooler` to the endpoint host | up to `10,000` | |
| 93 | +| [AWS RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html) | the proxy endpoint | managed | |
| 94 | +| [PlanetScale Postgres](https://planetscale.com/blog/scaling-postgres-connections-with-pgbouncer) | PgBouncer endpoint | managed | |
| 95 | +| Self-hosted | PgBouncer or PgCat | configured | |
| 96 | + |
| 97 | +Use the pooled endpoint for your tasks. Use the direct endpoint for schema migrations (Prisma Migrate, Drizzle Kit), which need a stable session that a transaction pooler does not provide. |
| 98 | + |
| 99 | +Transaction-mode poolers (Supavisor on `6543`, PgBouncer in transaction mode) do not keep server-side prepared statements across queries. With Prisma, add `?pgbouncer=true` to the pooled URL. With node-postgres, don't rely on prepared statements. |
| 100 | + |
| 101 | +## Provider notes |
| 102 | + |
| 103 | +- [Supabase](https://supabase.com/docs/guides/database/connecting-to-postgres): the direct connection (`db.<ref>.supabase.co:5432`) resolves to IPv6 only and is unreachable from many environments, so connect through the Supavisor pooler or add the IPv4 add-on. The pooler presents Supabase's own CA, so pass that CA or set `ssl: { rejectUnauthorized: false }`. |
| 104 | +- A `DATABASE_URL` with `sslmode=verify-full&sslrootcert=system` uses a libpq feature the `pg` driver (node-postgres, and the Prisma and Drizzle pools built on it) cannot read. Build the pool from discrete fields with `ssl: { rejectUnauthorized: true }` (Node's CA store), or point `sslrootcert` at a real CA file. |
| 105 | + |
| 106 | +## Release connections at a wait |
| 107 | + |
| 108 | +A run holds its connections while it is paused at a wait until the process is torn down, which is not instant. Free them sooner so other runs can reuse them. How you release depends on the client: |
| 109 | + |
| 110 | +- Prisma reconnects lazily, so disconnect it from a global [`tasks.onWait`](/tasks/overview#onwait-and-onresume-functions) handler colocated with the client. One handler covers every task. |
| 111 | +- A `pg` Pool (node-postgres and Drizzle) and the MongoDB client can't be reused after a full close, so give them a short idle timeout instead. Idle connections close themselves during the wait while the pool stays usable. |
| 112 | + |
| 113 | +<CodeGroup> |
| 114 | +```ts lib/db.ts (node-postgres) |
| 115 | +import { Pool } from "pg"; |
| 116 | + |
| 117 | +export const pool = new Pool({ |
| 118 | + connectionString: process.env.DATABASE_URL, |
| 119 | + max: 1, |
| 120 | + idleTimeoutMillis: 10_000, // idle connections close during a wait; the pool stays usable |
| 121 | +}); |
| 122 | + |
| 123 | +pool.on("error", (err) => console.error("pg pool error", err)); |
| 124 | +``` |
| 125 | + |
| 126 | +```ts lib/db.ts (Prisma) |
| 127 | +import { tasks } from "@trigger.dev/sdk"; |
| 128 | +import { PrismaPg } from "@prisma/adapter-pg"; |
| 129 | +import { PrismaClient } from "./generated/prisma/client"; |
| 130 | + |
| 131 | +const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL, max: 1 }); |
| 132 | +export const prisma = new PrismaClient({ adapter }); |
| 133 | + |
| 134 | +// Disconnect when any run pauses; Prisma reconnects on the next query. |
| 135 | +tasks.onWait("db", () => prisma.$disconnect()); |
| 136 | +``` |
| 137 | + |
| 138 | +```ts lib/db.ts (Drizzle) |
| 139 | +import { drizzle } from "drizzle-orm/node-postgres"; |
| 140 | +import { Pool } from "pg"; |
| 141 | + |
| 142 | +const pool = new Pool({ |
| 143 | + connectionString: process.env.DATABASE_URL, |
| 144 | + max: 1, |
| 145 | + idleTimeoutMillis: 10_000, |
| 146 | +}); |
| 147 | +pool.on("error", (err) => console.error("pg pool error", err)); |
| 148 | + |
| 149 | +export const db = drizzle({ client: pool }); |
| 150 | +``` |
| 151 | + |
| 152 | +```ts lib/db.ts (MongoDB) |
| 153 | +import { MongoClient } from "mongodb"; |
| 154 | + |
| 155 | +export const client = new MongoClient(process.env.DATABASE_URL!, { |
| 156 | + maxPoolSize: 5, |
| 157 | + maxIdleTimeMS: 10_000, // idle sockets close during a wait; the client stays usable |
| 158 | +}); |
| 159 | +``` |
| 160 | +</CodeGroup> |
| 161 | + |
| 162 | +Don't hold a client across a slow await, either. `pool.query()` checks a connection out and returns it in one call. If you `pool.connect()` and keep the client across an external HTTP call or a model stream, you pin that connection for the whole operation. Query, release, then do the slow work. |
| 163 | + |
| 164 | +## Chat agents |
| 165 | + |
| 166 | +A chat agent runs one long-lived worker per conversation and suspends between messages, so its connection count tracks the conversations streaming a turn at the same moment. The global `tasks.onWait` handler above covers chat agents too. Two more specifics: |
| 167 | + |
| 168 | +- Don't hold a connection across `streamText()`. A turn spends most of its time waiting on the model, so query and release before the stream starts. |
| 169 | +- To release only when a conversation goes idle (rather than on every internal wait within a turn), use [`onChatSuspend`](/ai-chat/lifecycle-hooks#onchatsuspend--onchatresume) instead of the global handler. |
| 170 | + |
| 171 | +```ts /trigger/chat.ts |
| 172 | +import { chat } from "@trigger.dev/sdk/ai"; |
| 173 | +import { streamText } from "ai"; |
| 174 | +import { openai } from "@ai-sdk/openai"; |
| 175 | +import { prisma } from "@/lib/db"; |
| 176 | + |
| 177 | +export const myChat = chat.agent({ |
| 178 | + id: "my-chat", |
| 179 | + run: async ({ messages, clientData, signal }) => { |
| 180 | + const user = await prisma.user.findUnique({ where: { id: clientData.userId } }); |
| 181 | + // The connection is back in the pool before the model stream starts. |
| 182 | + return streamText({ |
| 183 | + model: openai("gpt-4o"), |
| 184 | + system: `Helping ${user?.name ?? "the user"}.`, |
| 185 | + messages, |
| 186 | + abortSignal: signal, |
| 187 | + }); |
| 188 | + }, |
| 189 | +}); |
| 190 | +``` |
| 191 | + |
| 192 | +## Troubleshooting |
| 193 | + |
| 194 | +`too many connections` or connection refused: `concurrent runs × pool size` is over your provider's limit. Lower the pool size, cap [concurrency](/queue-concurrency), or connect through a pooler. |
| 195 | + |
| 196 | +The worker crashes right after resuming from a wait: an idle connection that closed during the suspend emitted an unhandled `error` event. Attach `pool.on("error", ...)` on a `pg` pool (node-postgres or Drizzle); Prisma and the MongoDB driver handle this internally. |
| 197 | + |
| 198 | +## How suspend affects connections |
| 199 | + |
| 200 | +When a task waits, the runtime can [checkpoint](/how-it-works#the-checkpoint-resume-system) the run: it snapshots the process and frees the compute, then restores the process when the wait resolves. Process memory comes back, so your pool object survives, but the database closed the idle connections in the meantime. The pool reconnects on the first query after resume. This is why a suspended run holds no connections, and why the pool needs an error handler to absorb the closed connection cleanly. |
| 201 | + |
| 202 | +## See also |
| 203 | + |
| 204 | +- [Wait](/wait) for the primitives that trigger a checkpoint. |
| 205 | +- [Concurrency and queues](/queue-concurrency) to cap how many runs execute at once. |
| 206 | +- [Lifecycle functions](/tasks/overview#onwait-and-onresume-functions) for global `tasks.onWait` and `tasks.onResume`. |
| 207 | +- [Chat agent lifecycle hooks](/ai-chat/lifecycle-hooks) for `onChatSuspend` and `onChatResume`. |
0 commit comments