How to use Supabase as your PostgreSQL hosting

I recently found out you can use Supabase as your PostgreSQL hosting.

Supabase is a very interesting project. It’s not “just a database hosting” but it’s also one, so you can use it as that. Every Supabase project contains a full, real PostgreSQL database — not a compatible clone, actual Postgres. It’s an app development platform built on top of PostgreSQL, and they offer a free connection pooler, which helps not exhausting the database connection limit with Prisma.

They allow up to 2 projects in the free account, so it’s worth trying it.

You can also work on a new project, then delete the old ones once you’re done.

Supabase markets itself as a Firebase alternative, and in addition to the database you have authentication, subscriptions, and a lot more you can explore later on.

NOTE: Supabase can also be self hosted, so your 2 projects limit will disappear, at the expense of having to manage your own infrastructure

To set it up, first login with GitHub on supabase.com

Create a new project

All connection strings live in the dashboard Connect UI. Click Connect at the top of the project page. You will see Direct connection, Session pooler, and Transaction pooler. Copy the ones you need from that dialog. Don’t try to build the pooler host from your region name: a region can have more than one pooler cluster, so the host must come from the dashboard.

The screenshots below are from 2022, when the connection string lived under Settings → Database. The steps are the same today, the panel just looks different.

Remember to fill [YOUR-PASSWORD] with the password you set for the project when you created it on Supabase.

If you’re ever unsure about the parts of a Postgres connection string, I built a free connection string builder that builds and parses them for you.

Which URL goes where

The pooler comes in two flavors: a session pooler on port 5432 (each client keeps a server connection for the whole session) and a transaction pooler on port 6543 (a server connection is borrowed only for the duration of each transaction). The transaction pooler is the one you want for serverless functions, because hundreds of short-lived function invocations would otherwise each open their own direct connection and exhaust the database limit.

For Prisma in a serverless / auto-scaling setup, keep two env vars. This is what the current Supabase Prisma guide recommends:

# App queries: Transaction pooler (port 6543)
DATABASE_URL="postgres://postgres.[PROJECT-REF]:[YOUR-PASSWORD]@[POOLER-HOST]:6543/postgres?pgbouncer=true"

# Migrations: Session pooler or Direct (port 5432)
DIRECT_URL="postgres://postgres.[PROJECT-REF]:[YOUR-PASSWORD]@[POOLER-HOST]:5432/postgres"

DATABASE_URL is what your app uses at runtime. DIRECT_URL (or a session / direct string on port 5432) is what prisma migrate needs. Transaction pooling cannot support prepared statements the way migrations expect, so do not point migrate at the 6543 URL.

The ?pgbouncer=true flag on DATABASE_URL tells Prisma it’s talking to a transaction-mode pooler, so it disables prepared statements.

With Prisma 7, set datasource.url in prisma.config.ts to DIRECT_URL. That is the URL the CLI uses when you run npx prisma migrate dev. Your app passes DATABASE_URL to the driver adapter (@prisma/adapter-pg) instead. On Prisma 6 and earlier, the datasource block in schema.prisma took both url and directUrl; Prisma 7 removed directUrl.

Either way, copy the exact host and username from the dashboard Connect panel.

Want me to talk about your product? You can sponsor this site.