apps/docs/content/guides/database/connecting-to-postgres.mdx
How you connect to your database depends on where you're connecting from:
The Data APIs allow you to interact with your database using REST or GraphQL requests. You can use these APIs to fetch and insert data from the frontend, as long as you have RLS enabled.
For convenience, you can also use the Supabase client libraries, which wrap the Data APIs with a developer-friendly interface and automatically handle authentication:
The direct connection string connects directly to your Postgres instance. It is ideal for persistent servers, such as virtual machines (VMs) and long-lasting containers. Examples include AWS EC2 machines, Fly.io VMs, and DigitalOcean Droplets.
<Admonition type="caution">Direct connections use IPv6 by default. If your environment doesn't support IPv6, use Supavisor session mode or get the IPv4 add-on.
</Admonition>The connection string looks like this:
postgresql://postgres:[YOUR-PASSWORD]@db.abcdefghijklmnopqrst.supabase.co:5432/postgres
Get your project's direct connection string from your project dashboard by clicking Connect.
Every Supabase project includes a connection pooler. This is ideal for persistent servers when IPv6 is not supported.
The session mode connection string connects to your Postgres instance via a proxy. This is only recommended as an alternative to a Direct Connection, when connecting via an IPv4 network.
The connection string looks like this:
postgres://postgres.apbkobhfnmcqqzqeeqss:[YOUR-PASSWORD]@aws-0-[REGION].pooler.supabase.com:5432/postgres
Get your project's Session pooler connection string from your project dashboard by clicking Connect.
The transaction mode connection string connects to your Postgres instance via a proxy which serves as a connection pooler. This is ideal for serverless or edge functions, which require many transient connections.
<Admonition type="caution">Transaction mode does not support prepared statements. To avoid errors, turn off prepared statements for your connection library.
</Admonition>The connection string looks like this:
postgres://postgres:[YOUR-PASSWORD]@db.abcdefghijklmnopqrst.supabase.co:6543/postgres
Get your project's Transaction pooler connection string from your project dashboard by clicking Connect.
For paying customers, we provision a Dedicated Pooler (PgBouncer) that's co-located with your Postgres database. This will require you to connect with IPv6 or, if that's not an option, you can use the IPv4 add-on.
The Dedicated Pooler ensures best performance and latency, while using up more of your project's compute resources. If your network supports IPv6 or you have the IPv4 add-on, we encourage you to use the Dedicated Pooler over the Shared Pooler.
Get your project's Dedicated pooler connection string from your project dashboard by clicking Connect.
Connection pooling improves database performance by reusing existing connections between queries. This reduces the overhead of establishing connections and improves scalability.
You can use an application-side pooler or a server-side pooler (Supabase automatically provides one called Supavisor), depending on whether your backend is persistent or serverless.
Application-side poolers are built into connection libraries and API servers, such as Prisma, SQLAlchemy, and PostgREST. They maintain several active connections with Postgres or a server-side pooler, reducing the overhead of establishing connections between queries. When deploying to static architecture, such as long-standing containers or VMs, application-side poolers are satisfactory on their own.
Postgres connections are like a WebSocket. Once established, they are preserved until the client (application server) disconnects. A server might only make a single 10 ms query, but needlessly reserve its database connection for seconds or longer.
Serverside-poolers, such as Supabase's Supavisor in transaction mode, sit between clients and the database and can be thought of as load balancers for Postgres connections.
<Image alt="New migration files trigger migrations on the preview instance." src={{ dark: '/docs/img/guides/database/connecting-to-postgres/how-connection-pooling-works.png', light: '/docs/img/guides/database/connecting-to-postgres/how-connection-pooling-works--light.png', }} width={1851} height={907} caption="Connecting to the database directly vs using a Connection Pooler"
/>
They maintain hot connections with the database and intelligently share them with clients only when needed, maximizing the amount of queries a single connection can service. They're best used to manage queries from auto-scaling systems, such as edge and serverless functions.
You should connect to your database using SSL wherever possible, to prevent snooping and man-in-the-middle attacks.
You can obtain your connection info and Server root certificate from your application's dashboard:
Below are answers to common challenges and queries.
A “Connection refused” error typically means your database isn’t reachable. Ensure your Supabase project is running, confirm your database’s connection string, check firewall settings, and validate network permissions.
This error occurs when your credentials are incorrect. Double-check your username and password from the Supabase dashboard. If the problem persists, reset your database password from the project settings.
Supabase’s default direct connection supports IPv6 only. To connect over IPv4, consider using the Supavisor session or transaction modes, or a connection pooler (shared or dedicated), which support both IPv4 and IPv6.
Your connection string is located in the Supabase Dashboard. Click the Connect button at the top of the page.
You can technically use both, but it’s not recommended unless you’re specifically trying to increase the total number of concurrent client connections. In most cases, it is better to choose either PgBouncer or Supavisor for pooled or transaction-based traffic. Direct connections remain the best choice for long-lived sessions, and, if IPv4 is required for those sessions, Supavisor session mode can be used as an alternative. Running both poolers simultaneously increases the risk of hitting your database’s maximum connection limit on smaller compute tiers.
Supavisor and PgBouncer work independently, but both reference the same pool size setting. For example, If you set the pool size to 30, Supavisor can open up to 30 server side connections to Postgres. These connections are shared between the session mode port (5432) and the transaction mode port (6543). Each mode can use up to 30 connections independently, or split them between both, but the total combined connections across both modes cannot exceed 30. PgBouncer can also open up to 30 connections under the same limit. If both poolers are active and reach their roles/modes limits at the same time, you could have as many as 60 backend connections hitting your database, in addition to any direct connections. You can adjust the pool size in Database settings in the dashboard.
There are two different limits to understand when working with poolers. The first is client connections, which refers to how many clients can connect to a pooler at the same time. This number is capped by your compute tier’s “max pooler clients” limit, and it applies independently to Supavisor and PgBouncer. The second is backend connections, which is the number of active connections a pooler opens to Postgres. This number is set by the pool size for that pooler.
Total backend load on Postgres =
Direct connections +
Supavisor backend connections (≤ supavisor_pool_size) +
PgBouncer backend connections (≤ pgbouncer_pool_size)
≤ Postgres max connections for your compute instance
The “max pooler clients” limit for your compute tier applies separately to Supavisor and PgBouncer. One pooler reaching its client limit does not affect the other. When a pooler reaches this limit, it stops accepting new client connections until existing ones are closed, but the other pooler remains unaffected. You can check your tier’s connection limits in the compute and disk limits documentation.
You can track connection usage from the Observability section in your project dashboard. There are three key reports:
Keep in mind that the Roles page is not real-time, it shows the connection count from the last refresh. If you need up-to-the-second data, set up Grafana or run the query against pg_stat_activity directly in SQL Editor. We have a few helpful queries for checking connections.
-- Count connections by application and user name
select
count(usename),
count(application_name),
application_name,
usename
from
pg_stat_ssl
join pg_stat_activity on pg_stat_ssl.pid = pg_stat_activity.pid
group by usename, application_name;
-- View all connections
SELECT
pg_stat_activity.pid,
ssl AS ssl_connection,
datname AS database,
usename AS connected_role,
application_name,
client_addr,
query,
query_start,
state,
backend_start
FROM pg_stat_ssl
JOIN pg_stat_activity
ON pg_stat_ssl.pid = pg_stat_activity.pid;
Even if your application isn’t making queries, some Supabase services keep persistent connections to your database. For example, Storage, PostgREST, and our health checker all maintain long-lived connections. You usually see a small baseline of active connections from these services.
Different modes use different ports:
5432 (database server)6543 (database server)6543 (separate server)5432 (separate server)The port helps route the connection to the right pooler/mode.
Because the dedicated pooler is hosted on the same machine as your database, it connects with lower latency than the shared pooler, which is hosted on a separate server. Direct connections have no pooler overhead but require IPv6 unless you have the IPv4 add-on.
Direct connection:
Shared pooler:
Dedicated pooler (paid tier):
You can follow the decision flow in the connection method diagram to quickly choose the right option for your environment.
<Image alt="Decision tree diagram showing when to connect directly to Postgres or use a connection pooler." src={{ dark: '/docs/img/guides/database/connecting-to-postgres/connection-decision-tree.svg', light: '/docs/img/guides/database/connecting-to-postgres/connection-decision-tree-light.svg', }} caption="Choosing between direct Postgres connections and connection pooling" width={291} height={150}
/>