sherbase

sherbase is shebang's database service — a dedicated Postgres database and role, provisioned by a single call, reachable two different ways depending on what you're building.

A database is a slug

base_create_database({ slug }) provisions a database named base_<slug> and a role of the same name, and hands back a password and connection string shown exactly once. From then on the slug is how every other base_* tool refers to it — Databases covers the full tool set and what a slug actually is.

Two ways in

• Direct SQL — the connection strings sherbase returns work with psql, migrations, and any Postgres client, or with base_run_sql if you'd rather stay inside the MCP server.
• The Data API — every database also gets a PostgREST-based Supabase-shaped API at https://api.shebang.pro/db/<slug>, with sherlock as the auth provider behind it. This is what supabase-js talks to, and what row- level security checks auth.uid() against. See the Data API.

In this section

• Databases — the seven base_* tools, and what provisioning actually creates.
• Connection strings — the session and transaction pooler strings, and TLS verification.
• The Data API — the PostgREST endpoint, publishable vs. secret keys, and sherlock-backed RLS.
• supabase-js examples — embedded and redirect sign-in, both against the Data API.
• Reload schema and rotate secret — keeping the Data API in sync with DDL, and replacing a leaked key.
• Enable on older databases — the Data API is on by default now; this is for databases from before it existed.
• Limits — what's actually enforced on base_run_sql and the pooler today.

A database's home Project scopes it the same way every other resource does — see projects and scoping if you haven't read that yet.

Next

Databases.