# metadata

PostgreSQL schema and migration tooling for Sentry's control-plane
config: dashboards, alert rules, and everything else that isn't log data.
See `/docs/phase-3-dashboard-design.md` and
`/docs/phase-3-alerting-design.md` for why this is a separate database
from `/storage` (ClickHouse) rather than new ClickHouse tables — short
version: dashboards and alert state need real row-level locking and
transactional read-modify-write, which ClickHouse's MergeTree family
doesn't provide.

## Schema

Six tables across two features, one shared database (`sentry_metadata`):

- `dashboards`, `dashboard_panels` — owned by `/api` (`api/internal/dashboards`)
- `notification_targets`, `alert_rules`, `alert_state`, `delivery_log` —
  owned by `/alerting`

"Owned" here is a documentation convention, not a technical boundary —
both services connect to the same Postgres instance/database, each with
its own hand-written SQL for the tables it's responsible for. Nothing is
shared across service `internal/` trees for this, matching the existing
repo convention that only `/proto` is shared code (and even that isn't
shared logic, just generated bindings).

## Migration tooling: mirrors `/storage/migrate.sh`, not a framework

Same reasoning as `/storage/README.md`: pulling in `golang-migrate` for
what's currently six `CREATE TABLE` statements is premature machinery.
`migrate.sh` applies `migrations/*.sql` in filename order over `psql`,
tracking what's applied in a `schema_migrations` table, one DDL object
per file (kept for repo-wide consistency of what a migration "version"
means, even though Postgres itself supports multi-statement transactions
unlike ClickHouse's HTTP interface).

## Running

```sh
docker compose up -d                                   # starts a standalone Postgres for local work
POSTGRES_PASSWORD=sentry-dev-only ./migrate.sh          # applies migrations/*.sql
```

Environment variables `migrate.sh` reads (all optional except
`POSTGRES_PASSWORD`, matching the root docker-compose.yml's
`metadata-postgres` service):

| Var | Default |
|---|---|
| `POSTGRES_HOST` | `localhost` |
| `POSTGRES_PORT` | `5432` |
| `POSTGRES_USER` | `sentry` |
| `POSTGRES_PASSWORD` | (empty — must be set) |
| `POSTGRES_DATABASE` | `sentry_metadata` |

The database itself isn't created by `migrate.sh` — the `postgres:16-alpine`
image auto-creates `POSTGRES_DB` on first startup, unlike ClickHouse where
`migrate.sh` has to issue `CREATE DATABASE IF NOT EXISTS` itself.

There's also a `Dockerfile` (bash + the `postgresql16-client` package
baked in, `migrations/` copied in at build time) used by the root-level
`docker-compose.yml` as a one-shot init service (`metadata-migrate`) —
no runtime package install, no host volume mount needed.

## Adding a migration

Add `migrations/000N_description.sql` with the next sequential number and
a single DDL statement. `migrate.sh` picks it up automatically — no
registration step.