Postgres on SupaHost

Every SupaHost project is a normal Supabase project, and at its heart is a Postgres database. This page explains how those databases are arranged on your instance, what you share between projects, and the ways you can work with your data.

One server, one database per project

Your instance runs a single Postgres server. Each project you create gets its own database on that server, so the tables, functions, grants, extensions and RLS policies in one project are separate from every other project's.

Because each project starts from the same pristine template as a fresh Supabase project, anything you know from Supabase Cloud or self-hosting applies: auth.users, auth.uid(), Storage tables, the anon, authenticated and service_role roles, and so on.

You will normally only see the database name when you connect directly over the SSH tunnel on Business. Studio, the Data API and the MCP server pick the right database for you.

What projects share

Projects on one instance are isolated at the database level, but they run on the same VM and draw from the same allowances.

• Database size. The plan's database allowance (8 GB on Builder, 25 GB on Pro, 50 GB on Business) is shared across all projects. Usage is the sum of each project database's pg_database_size. You can buy more in 10 GB steps.
• Connections. The server allows 400 connections in total, shared by every project and service on the instance. Each project's Data API (PostgREST) keeps a pool of 5 connections and Auth keeps another 5.
• CPU and memory. Heavy queries in one project slow down the others on the same instance. Keep that in mind when you put a busy production app next to experiments.

To check how big a project's database is right now, run this in Studio's SQL editor:

select pg_size_pretty(pg_database_size(current_database())) as size;

And to find the largest tables in that project:

select relname as table_name,
       pg_size_pretty(pg_total_relation_size(relid)) as total_size
from pg_catalog.pg_statio_user_tables
order by pg_total_relation_size(relid) desc
limit 10;

Roles you will meet

See Roles and permissions for grants and custom roles.

Ways to work with your data

Details for each are in Connecting to your database.

Durability and upkeep

• Backups. The whole Postgres server is backed up daily, and write-ahead logs are shipped continuously. Builder and Pro keep 7 days, Business keeps 14. Pro and Business can also restore to a point in time. A restore replaces one project's database without touching the others. See Backups.
• Disk. The instance disk grows automatically as it fills, without a restart.
• No pausing. Projects never pause for inactivity.

What isn't offered

Some Supabase Cloud database features don't exist on SupaHost. Plan around them rather than looking for a setting:

• No connection pooler (Supavisor), so there is no transaction-mode port 6543.
• No read replicas and no multi-server failover.
• No public Postgres port. Port 5432 listens only inside the VM; direct access is through the SSH tunnel on Business and Enterprise.
• No pg_graphql over HTTP, because there is no /graphql/v1 route.
• No log explorer in the dashboard. Studio's Logs and Reports pages are switched off.

For the full matrix of Supabase features, see Supabase features on SupaHost.

Next steps

• Connecting to your database
• Using Supabase Studio
• Tables, columns and data
• Row Level Security