Connecting Prisma and Drizzle to WattleDB (Postgres)

Connecting Prisma and Drizzle to WattleDB

WattleDB is standard PostgreSQL, so your favourite ORM just works — once you point the right URL at the right job. Here's the clean setup for Prisma and Drizzle: pooled connection for your app, direct connection for migrations, TLS on, and the one transaction-pooler gotcha to know about.

Guide · 7 min read · Updated July 2026

Because WattleDB is plain PostgreSQL, there's no special driver or adapter — Prisma, Drizzle, TypeORM, whatever you like, all connect normally. The only thing to get right is which connection string does which job. Get that right and everything from migrations to serverless just works.

The rule for every ORM

App / query runtime → pooled DATABASE_URL.
Migrations → direct DIRECT_URL.
Always keep sslmode=require — both endpoints are TLS.

Two URLs, two jobs

Your app makes lots of short queries under load — that's the pooled DATABASE_URL's job (see connection pooling). Migrations create objects and hold longer transactions that a transaction pooler breaks — that's the direct DIRECT_URL's job. Every ORM setup below is just wiring those two strings to those two roles.

Prisma

Prisma has first-class support for exactly this split. Point url at the pooled endpoint and directUrl at the direct one — Prisma uses url at runtime and directUrl for prisma migrate and introspection:

// schema.prisma
datasource db {
  provider  = "postgresql"
  url       = env("DATABASE_URL")   // pooled — app queries
  directUrl = env("DIRECT_URL")     // direct — migrations
}

# .env
DATABASE_URL="postgresql://app:***@<id>.db.wattledb.com.au:PORT/app?sslmode=require&pgbouncer=true"
DIRECT_URL="postgresql://app:***@<id>.db.wattledb.com.au:PORT/app?sslmode=require"

The pgbouncer=true flag tells Prisma it's talking to a transaction pooler, so it manages prepared statements accordingly.

Drizzle

Drizzle uses a Postgres driver directly. For the pooled connection with postgres.js, disable prepared statements so the transaction pooler is happy; use the direct URL in your Drizzle Kit migration config:

// db.ts — runtime, pooled
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";

const client = postgres(process.env.DATABASE_URL!, { prepare: false });
export const db = drizzle(client);

// drizzle.config.ts — migrations, direct
export default {
  schema: "./src/schema.ts",
  dbCredentials: { url: process.env.DIRECT_URL! },
} satisfies Config;

TLS and the CA certificate

Both endpoints require TLS — keep sslmode=require in your connection strings. For verified TLS (recommended in production), download the CA certificate from the console and point your driver at it with sslmode=verify-full and the cert path, so the client checks it's really talking to your database and not a man in the middle.

Common pitfalls

Migrations failing or hanging? They're probably running through the pooled URL. Point your migration command at DIRECT_URL.
"prepared statement already exists"? Disable prepared statements on the pooled connection (prepare: false / pgbouncer=true).
Connection refused / SSL errors? Make sure sslmode=require is present — WattleDB doesn't accept unencrypted connections.
Too many connections under load? Confirm your app is on the pooled DATABASE_URL, not the direct one.

ORM connection questions

How do I connect Prisma to WattleDB?

Set url to the pooled DATABASE_URL and directUrl to the direct DIRECT_URL in your Prisma datasource block. Prisma uses url for app queries at runtime and directUrl for prisma migrate and introspection. Add pgbouncer=true to the pooled URL so Prisma handles prepared statements correctly through the transaction pooler, and keep sslmode=require on both.

How do I connect Drizzle to WattleDB?

Use a standard Postgres driver such as postgres.js pointed at the pooled DATABASE_URL, with prepare: false so the transaction pooler works, then wrap it with drizzle(). For migrations, put the direct DIRECT_URL in your Drizzle Kit config's dbCredentials. As with any ORM, keep sslmode=require on both connection strings.

Why do my migrations fail through the pooled connection?

Transaction-mode pooling doesn't preserve session state between statements, and migrations rely on it — creating objects and holding longer transactions. Run migrations over the direct DIRECT_URL instead, which is a dedicated session connection. Keep your app's runtime queries on the pooled DATABASE_URL.

What causes 'prepared statement already exists' errors?

This happens when a driver caches prepared statements but the transaction pooler hands you a different backend connection next time. Disable prepared statements on the pooled connection — prepare: false with postgres.js, or pgbouncer=true with Prisma — and the error goes away. The direct connection doesn't have this constraint.

Do I need SSL to connect?

Yes. WattleDB only accepts TLS-encrypted connections, so keep sslmode=require in your connection strings. For verified TLS in production, download the CA certificate from the console and use sslmode=verify-full with the certificate path, so your client confirms it's connecting to the genuine database endpoint.