# Postgres on SupaHost

> How Postgres is laid out on SupaHost: one Postgres 17 server per instance, one database per project, shared quotas, roles, connections, backups and what isn't offered.

Source: https://supahost.app/docs/database/overview · Updated 2026-11-11

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.

| | Value |
|---|---|
| Postgres version | 17 (image `supabase/postgres:17.6.1.136` in release `2026.11.02`) |
| Database name | `p_` plus the project name, with `-` turned into `_` |
| Example | project `app-one` uses the database `p_app_one` |
| Starting point | a clean copy of the stock Supabase database, with the usual `auth`, `storage`, `extensions` and `public` schemas |

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:

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

And to find the largest tables in that project:

```sql
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

| Role | What it's for |
|---|---|
| `postgres` | Your role. Studio, `sudo supahost-psql` and the SSH tunnel all sign in as `postgres`. It can create objects in `public`. |
| `anon`, `authenticated` | The roles the Data API switches to for requests with the anon key or a signed-in user's JWT. RLS policies target these. |
| `service_role` | Used by requests made with the service_role key. It bypasses RLS. |
| `authenticator`, `supabase_auth_admin`, `supabase_storage_admin` | Internal roles used by PostgREST, Auth and Storage. Leave them alone. |
| `supabase_admin` | Used by the SupaHost agent to manage the server. |

See [Roles and permissions](/docs/database/roles) for grants and custom roles.

## Ways to work with your data

| Tool | Plans | Good for |
|---|---|---|
| Data API (REST) with supabase-js | All | Your application's reads and writes |
| Studio's table editor and SQL editor | All (owner only) | Designing tables, running ad-hoc SQL, policies |
| MCP server (`execute_sql`, `apply_migration`) | All | Letting an AI coding agent inspect and change the schema |
| Direct Postgres over an SSH tunnel | Business, Enterprise | psql, pg_dump, Prisma, Drizzle and other tools that speak the Postgres protocol |
| Exports (pg_dump file) | All | Taking a full copy of a project's database |

Details for each are in [Connecting to your database](/docs/database/connecting).

## 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](/docs/platform/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](/docs/getting-started/feature-support).

## Next steps

- [Connecting to your database](/docs/database/connecting)
- [Using Supabase Studio](/docs/database/studio)
- [Tables, columns and data](/docs/database/tables)
- [Row Level Security](/docs/database/row-level-security)