Database Overview

Every AnvilBase project is backed by its own PostgreSQL 15 database, platform_<project_id>. Not a schema, not a set of row tags — a separate database. This is the foundation of multi-tenant isolation.

The database name has no hyphens. <project_id> in this connection string is your project’s UUID with the hyphens stripped — 32 hex characters. A project 3f2b17c4-1d2e-4a9b-8c7d-0e1f2a3b4c5d maps to database platform_3f2b17c41d2e4a9b8c7d0e1f2a3b4c5d, not platform_3f2b17c4-1d2e-….

What you can do with it

You interact with the database five ways, all of which act on the same project database:

Surface	Best for	Docs
Auto REST API (`/v1/rest/...`)	app reads/writes from the SDK	REST API
Schema/DDL API (`/api/v1/.../schema`)	creating tables/columns programmatically	Tables & Schema
SQL Editor / `rpc/exec_sql`	ad-hoc queries, complex DDL	SQL Editor
Migrations (`db push`)	versioned schema changes	Migrations
Console Table Editor	visual browsing & editing	console → Tables

The image and extensions

AnvilBase ships its own tagged, hardened PostgreSQL 15 image, built on PostgreSQL 15 and the open-source extension ecosystem (pgvector, pgvectorscale, pg_graphql, pg_cron, pg_net) with wal-g point-in-time recovery. Available out of the box:

Extension	Purpose
`pgvector`	vector similarity search (embeddings) — see Vector Search
`pgvectorscale`	StreamingDiskANN index for large-scale vector search — see Vector Search
`pg_graphql`	GraphQL over your schema at `POST /graphql/v1` — see GraphQL API
`pgmq`	durable message queues
`pg_cron`	scheduled jobs inside Postgres (platform-managed)
`pg_net`	outbound HTTP requests from SQL
`pgcrypto`	column-level encryption, `gen_random_uuid()`
`uuid-ossp`	UUID generation helpers

List what’s installed in a project:

anvilbase schema extensions --project <project_id>
# or
curl http://localhost:39001/api/v1/projects/<id>/schema/extensions \
  -H "Authorization: Bearer $ANVILBASE_TOKEN"

See Extensions for enabling and using them, and Vector Search for embeddings.

Defaults that matter

RLS is enabled by default on every table you create through AnvilBase. A fresh table denies all access until you add a policy — fail-closed by design. See Row Level Security.
public schema is where your application tables live and what the REST engine exposes.
Identifiers and column types are validated against an allowlist on the schema API; everything is built with quoted identifiers, never string-spliced user SQL.

Connecting directly with `psql`

For local development you can connect straight to Postgres. The connection string is printed by anvilbase status --local:

# Platform/app database (not a specific project)
psql "postgres://anvilbase:<password>@localhost:39432/anvilbase_platform"

# A specific project's database
psql "postgres://anvilbase:<password>@localhost:39432/platform_<project_id>"

The database name has no hyphens. <project_id> in this connection string is your project’s UUID with the hyphens stripped — 32 hex characters. A project 3f2b17c4-1d2e-4a9b-8c7d-0e1f2a3b4c5d maps to database platform_3f2b17c41d2e4a9b8c7d0e1f2a3b4c5d, not platform_3f2b17c4-1d2e-….

In production, prefer the pooled endpoint via Supavisor (Scaling) and restrict direct Postgres access at the network layer (Network Security).

Connection pooling

Per-project REST traffic uses the control plane’s built-in lazy pools (~2–5 MB each). For direct database connections from your own services, Supavisor provides transaction- and session-mode pooling. See Scaling → Connection Pooling.

Next: Tables & Schema.