Overview

Same database — different routes

The other strings Supabase shows you change the host, port, and username — and each change means a completely different path to your database.

Hostdb.[ref].supabase.co vs pooler host

Port5432 vs 6543

Usernamepostgres vs postgres.[ref]

Each combination is a different path

Direct · IPv6

PgBouncer · transaction

Supavisor · transaction

Supavisor · session

Connection strings

Four connection strings

Here’s what they are — and when to use each one.

String 1

Direct

Host db.[ref].supabase.co

Port 5432

User postgres

IPv4 Not IPv4

No pooler. One backend per connection. Requires IPv6 (or IPv4 add-on). Best for long-lived servers with a stable pool.

String 2

Transaction pooler (PgBouncer)

Host db.[ref].supabase.co

Port 6543

User postgres

IPv4 Not IPv4

Same host as direct. Transaction mode. IPv6 or add-on. Battle-tested PgBouncer.

String 3

Transaction pooler (Supavisor)

Host [region].pooler.supabase.com

Port 6543

User postgres.[ref]

IPv4 IPv4 compatible

Regional pooler host, routed user. IPv4-friendly. Ideal for serverless and short-lived connections.

String 4

Session pooler (Supavisor)

Host [region].pooler.supabase.com

Port 5432

User postgres.[ref]

IPv4 IPv4 compatible

Session-scoped like direct, via pooler. IPv4-friendly. Alternative to direct on IPv4 networks.

Interactive explorer

Supabase connection

1 2 main tabs · ← → step · Shift+←→ slides

Example URIs for project ref cqesudmnzjvyhffjvipn — Prev/Next highlights the same step in all four rows at once

—

Choosing a connection

Which one do I use?

Next.js API routes, Vercel serverless, Cloudflare Workers — Transaction pooler, port 6543 (Supavisor or PgBouncer).
Long-running server — Express, Rails, Django — Direct or Session pooler.
Migrations — Always Direct.

Remember the port

Direct connection doesn’t use a pooler — default Postgres port 5432.
On pooler strings, the port picks the mode: 5432 on the pooler = session; 6543 = transaction (Supavisor or PgBouncer).

Security

SSL modes

By default, Supabase allows connections without SSL for compatibility — you can enforce SSL in database settings. Postgres has six sslmode values; mode matters for security.

Mode	What it means
`disable`	No encryption, no negotiation.
`allow`	No preference; encrypts if the server demands it.
`prefer`	Tries SSL but can fall back to plaintext — many clients’ default; you might think you’re encrypted when you aren’t.
`require`	Encrypts the connection; doesn’t verify the server certificate. Good default for most Supabase apps — encryption without managing a CA bundle.
`verify-ca`	Encrypts and checks the cert was signed by a trusted CA.
`verify-full`	Encrypts, verifies CA, and checks hostname matches the certificate — strongest mode; aligns well when SSL enforcement is on.

Tip: Don’t leave clients on prefer if you care about knowing you’re encrypted — use require or stronger.

Summary

One line, many decisions

The connection string is routing in one line: host and port decide direct vs pooler and which mode; SSL settings decide how the channel is protected; the role you use decides what the session can do.

Next: IPv4 add-on and checking your project’s IP — then roles and least privilege in production.