---
title: "Databases"
description: "Managed Postgres on your servers or the Frazer fleet, with standbys, pooling, a private endpoint in your VPC and point-in-time recovery into a new instance."
url: https://frazer.ai/docs/databases
index: https://frazer.ai/docs/llms.txt
tokens: 5181
---

> For agents: this page is indexed at https://frazer.ai/docs/llms.txt, and every page at https://frazer.ai/llms.txt. Copy commands from this file exactly.

# Databases

Databases is managed Postgres. You create an instance from the console, the `frazer` CLI, the API or MCP, and Frazer runs it on your servers or on the Frazer fleet: standbys with failover, connection pooling, backups, maintenance and a private endpoint in your VPC. Every change is a plan that names its disruption before you apply it, and every restore lands in a new instance, never over the running one.

Product overview: [Databases](https://frazer.ai/databases).

## How it works

A managed database runs in a data cluster that Frazer operates for the server pool you place it on. It never runs inside your project’s own Kubernetes cluster, so cluster upgrades and cluster-admin mistakes cannot touch it. Your project gets its own namespace in that data cluster, and the capacity counts against your project’s share of the pool. You never see or manage the data cluster itself.

Data sits on the servers’ local NVMe. Durability comes from standbys on other servers and from backups in Frazer Storage, not from the disk. Base backups go to Frazer Storage daily and the write-ahead log (WAL) continuously, which is what makes point-in-time recovery possible.

Apps reach an instance through a private endpoint: an address in a subnet of your VPC with one DNS name. People and agents connect over Frazer Link with their Frazer identity. A public address is off unless you turn it on.

-   **Instance**: one database server with an engine, version, tier, high availability (HA) setting, storage, network, backups and a maintenance window.
-   **Engine**: PostgreSQL 16 to 18 is the default. ClickHouse and Qdrant use the same list, create page, backups and maintenance. MySQL, Kafka, OpenSearch and a Mongo-compatible engine are added on request.
-   **Tier**: the shape of each instance (below).
-   **Disruption level**: what a change costs while it runs: `none`, `reload`, `rolling`, `restart` or `downtime`. Every plan states it, for every engine.
-   **Source**: **Managed** for instances created through Frazer, **From Git** for databases declared in your environment repository. Both appear in one list.

| Tier | Shape | Use |
| --- | --- | --- |
| `db-s1-1`, `db-s1-2` | Shared CPU, 2 to 4 GiB, single instance | Development, staging, previews; can power off after a set number of idle hours |
| `db-g1-<n>` | 4 GiB per vCPU, guaranteed CPU | The default |
| `db-m1-<n>` | 8 GiB per vCPU | Large working sets, ClickHouse |
| `dedicated-<server-sku>` | Whole servers with local NVMe, upgraded in place | Large Postgres and ClickHouse |

## Create a database

Choose where the instance runs first. A primary with standbys needs three servers in the pool; a one-server site offers single-instance tiers only, and the create page says why.

### CLI

1.  Plan the instance. The plan shows the cost, the quota impact and the disruption level, and changes nothing.
    
    ```sh
    frazer databases create storefront --engine postgres --version 18 \
      --tier db-g1-4 --ha --site ovh-vint-hill --storage 200 --dry-run
    ```
    
    ```text title="Output"
    Plan    + PostgreSQL 18 · db-g1-4 · a primary and 2 standbys on 3 servers
            + endpoints rw, ro, pooled · storefront.db.acme-production.internal
            + connection pooling · transaction mode
            + daily base backups · point in time: 7 days
            + deletion protection on
    Cost    included in the server fee
    ✓ Disruption: none
    ```
    
2.  Apply it: run the same command without `--dry-run`.
    
3.  Check the instance, its endpoints and its recovery window.
    
    ```sh
    frazer databases describe storefront
    ```
    

### Console

1.  Open **Data › Databases** and choose **Create database**.
    
2.  Pick an engine card, then fill in one form: name, placement (with live capacity), version, tier, HA, storage, network and subnet, backups, maintenance window and deletion protection. Postgres adds pooling and extensions.
    
3.  Check the right rail: the cost, the quota, the disruption level and the plan diff. **Copy as CLI / API / YAML** gives you the same request for automation.
    
4.  Confirm the plan. The instance’s **Overview** shows health, charts and production checks; **Connect** shows the endpoint, ports, CA bundle and ready connection strings.
    

HA is on by default in production projects: a primary and two standbys on three servers, with automatic failover. Synchronous commit to a quorum of one standby is an option. Deletion protection is also on by default in production projects.

## Connect

### From your apps

Each instance gets a private endpoint in the subnet you pick, with the DNS name `<instance>.db.<project>.internal` and three entries:

| Entry | Goes to |
| --- | --- |
| `rw` | The primary |
| `ro` | The read replicas |
| `pooled` | A connection pooler in transaction mode (session mode is an option) |

The endpoint has an IPv4 and an IPv6 address, and the name answers A and AAAA. There is no route between your VPC and the data cluster, so overlapping address ranges are fine. The database sees the endpoint’s address, not your client’s, so control access with credentials and VPC firewall rules, not `pg_hba` source ranges.

Apps get credentials from [Secrets](https://frazer.ai/docs/secrets), never from a person:

-   **Kubernetes**: the cluster’s secret sync writes `DATABASE_URL` into your namespace, and the password rotates on a schedule with two valid versions during the switch.
-   **Serverless**: a binding writes `DATABASE_URL` (through the pooler), `DATABASE_DIRECT_URL` and the `PG*` variables. A new password starts a new revision. See [Serverless](https://frazer.ai/docs/serverless).

Create users for your apps from a role bundle: `owner`, `readwrite` or `readonly`. Frazer keeps its own `insights` role for monitoring. Custom SQL grants still work.

```sh
frazer databases users create app --instance storefront --bundle readwrite
```

### From a laptop or an agent

```sh
# A session with your own identity: a short-lived database login, no password
frazer databases connect storefront --role readonly

# storefront on localhost:5432 for your own tools
frazer databases proxy storefront --port 5432
```

Both run over Frazer Link and need the `databases.instances.connect` permission. Every login is audited. There is no reveal button for passwords: a person who needs a password-based user types one when creating it, and Frazer keeps only the copy for workloads. Postgres also accepts client certificates.

### From the internet

The public endpoint is off by default. Turning it on is a plan like any other change. You get an IPv4 and IPv6 address pair, an IP allowlist and TLS with `sslmode=verify-full`.

## Back up and restore

Frazer takes a daily base backup in your backup window and archives the write-ahead log as it happens, so a restore replays the log up to the second you pick.

| Setting | Default |
| --- | --- |
| Point in time | 7 days in production projects, 1 day in staging; you can set 1 to 35 days |
| Base backups | Daily in your window; 14 daily, 8 weekly and 12 monthly kept |
| Where | Frazer Storage, with an optional copy at another site |
| On delete | A final backup, kept after the instance is gone |
| Restore drill | Monthly for every instance, with the result on its page |

```sh
# Every backup: scheduled, on demand and final
frazer databases backups list storefront

# Take one now, before a risky migration
frazer databases backups create storefront

# Restore to a second, into a new instance; storefront keeps serving
frazer databases restore storefront --to storefront-restore \
  --time 2026-10-14T09:30:00Z
```

**Drills on demand.** Restores that span services and stores have one home, the `recovery` service: `frazer recovery drills run --store databases --kind restore --dry-run` restores to a point in time and verifies every page, `--kind site` rehearses losing a site, and `frazer recovery drills list --json` and `frazer recovery drills get <drill>` show each drill’s measured recovery point and time against its target (MCP `recovery_drills_run`, `recovery_drills_list`, `recovery_drills_get`).

A restore never overwrites. It creates a new instance at the time or log position (LSN) you pick. Check it, then switch your apps to it.

### Deletes, undelete and the backup vault

Deleting a database starts a restore window: 7 days outside production, 14 in production, by default. Until it ends, `frazer databases undelete <name>` brings the database back to its last second. Backups sit in your organization’s backup vault, locked for their retention. Shortening a retention needs two people and takes effect 24 hours after the second approval. Agents can never delete a production database or any backup: they get a plan for a person to approve.

### When funds run out

If your organization’s funds or cap run out, a restore into a new database and an undelete still run: they draw on the [reserve](https://frazer.ai/docs/billing#the-monthly-cap) first, and anything beyond it is billed afterwards. Restores never return `FUNDS_EXHAUSTED`.

For a short-lived copy, create a branch: a Postgres copy at a point in time with a time to live, for one pull request.

```sh
frazer databases branches create storefront-pr-42 --of storefront --ttl 24h
```

Other engines back up differently. ClickHouse takes daily full and incremental backups with no point-in-time recovery, and can restore one table. Qdrant takes daily snapshots and can restore one collection. Every engine restores into a new instance.

## Scale and change

Every change is a plan that states its disruption. Apply it now or in your maintenance window.

| Change | How Frazer does it | Disruption |
| --- | --- | --- |
| Minor version or patch | In the window: standbys first, then a switchover | `rolling` with HA; a restart without |
| Major version, in place | A pre-check of extensions, flags and replication slots, then an offline `pg_upgrade` | `downtime`, stated in the plan |
| Major version, blue/green | Logical replication into a new instance, then an endpoint swap | Read-only during the swap |
| A flag such as `shared_buffers` | From an allowlist per version; unsafe flags are refused in the plan | `restart`, with a switchover |
| More storage | Grown online | `none` |
| Less storage | Restore into a smaller instance | A new instance |

```sh
# A read replica behind the ro entry
frazer databases replicas create storefront-r1 --of storefront

# A major upgrade, planned first
frazer databases upgrade acme-ledger --major 18 --method blue-green --dry-run
```

-   **Storage** grows online, and auto-grow adds space at 80 % up to a cap you set.
-   **Read replicas** run in the same site behind `ro`. A cross-site replica (`--site` with another site) is a disaster recovery copy that you promote with a live action.
-   **Extensions** come from a signed catalog that includes pgvector and pgvectorscale; licenses are checked before an extension is added, and you cannot upload your own libraries.
-   **Power off** stops compute and keeps the configuration and backups. A powered-off instance is deleted after 180 days, with warnings at 30, 7 and 1 days.

### Maintenance windows

A window is a day and an hour, three hours long. Staging projects are updated first and production a week later. You get seven days’ notice by email, in the console and as a webhook, and you can apply an update now or set deny periods of up to 90 days. Before a version leaves support you get 12 months’ notice; after that, the upgrade runs in your window.

**New major versions.** Postgres 19 is planned for November 19, 2026. Frazer offers a preview line within 14 days of its release and makes it generally available within 60 days, Shared storage first (targets).

## Find slow queries

**Query insights** read Postgres statistics through the read-only `insights` role: top queries by total time, calls and rows, load by wait class, notable queries, unused and missing indexes, bloat and vacuum age. When a query’s latency moves against its 7-day baseline, insights link it to the rollout, flag change or plan that came before.

```sh
frazer databases insights top storefront --by total-time
frazer databases ask storefront "top 10 customers by revenue last week"
```

-   The **index advisor** proposes indexes from your top queries and checks them with `hypopg` what-if plans. Advice becomes a plan or a migration file for your repository; it never applies itself.
-   **Ask** turns a question into SQL that runs as a read-only role. You see `EXPLAIN` and the estimated rows first, row and time limits apply, and every generated query is audited. Sample values go to the model only where you allow it.
-   **Metrics** go to your project’s [Frazer Monitoring](https://frazer.ai/docs/monitoring) tenant, with default alerts for storage above 85 %, replication lag, a failed backup, connections near the maximum and certificate expiry. Edit them there.

## Databases declared in Git

Postgres databases you declare in your environment repository keep working in your project cluster. The console shows them in the same list with a **From Git** badge: status, metrics, backups, the recovery window and connect details, with the spec read-only. **Edit** shows the YAML change to make in Git. Backup now, switchover and restore into a new instance work as audited live actions.

```sh
frazer databases list --source git
frazer databases move-to-managed <observed-id> --to storefront \
  --method logical-replication --dry-run
```

Moving to managed is always a plan and can be reversed until cutover. Frazer replicates into a new managed instance and shows the lag live. At cutover the source turns read-only, the lag reaches zero, your app’s `DATABASE_URL` secret switches to the managed endpoint, and Frazer shows you the YAML to delete from Git. Frazer never edits your repository unless your organization granted write access.

## Access and audit

| Who | What they can do |
| --- | --- |
| Developer | Create and change instances, users and databases through plans |
| Viewer, Responder | Read instances, metrics and backups |
| Anyone with `databases.instances.connect` | Open a session with `frazer databases connect` or `proxy` |
| Agents | Read, query read-only and plan; DDL, resizes, restores and flag changes wait for a person |

-   Every applied plan becomes a revision of the instance. Live actions (backup now, switchover, restore) are audited.
-   Every database login through Frazer IAM is recorded per person or agent, and every query the assistant generates is audited.
-   Restores need `databases.backups.restore`. Deletion protection is on by default in production, and delete always takes a final backup first.
-   A spend cap never stops a database on your own servers. On the Frazer fleet it powers instances off and never deletes them.

## Limits and quotas

| Item | Default |
| --- | --- |
| Postgres versions | 16, 17 and 18 |
| Standbys with HA | 2, on 3 servers |
| Point-in-time window | 7 days in production, 1 day in staging; 1 to 35 days |
| Base backup retention | 14 daily, 8 weekly, 12 monthly |
| Storage auto-grow | At 80 % used, up to your cap |
| Maintenance window | 3 hours, with 7 days’ notice |
| Deny periods | Up to 90 days |
| Powered-off instance | Deleted after 180 days |
| End of support | 12 months’ notice |

## Pricing

On your own servers a database uses their capacity and is part of the server fee; backups count against the Frazer Storage allowance.

| Databases | On your servers | On the Frazer fleet |
| --- | --- | --- |
| Price | **Included** | $0.039 / vCPU-hour + $0.0075 / GiB-hour per node (the fleet's vCPU rate + 30 %) · every copy is a node, except standbys on Shared that serve no reads, at the fleet rates · storage $0.012 / GiB-month per copy · backups up to your storage included |

Every line, with the estimator: [pricing](https://frazer.ai/pricing#lines).

## Troubleshooting

| Symptom | Cause | Fix |
| --- | --- | --- |
| The create page offers no HA | The pool has fewer than three servers | Add servers to the pool, or create a single-instance tier |
| An app outside the VPC cannot connect | Instances are private by default | Connect from the VPC, use `frazer databases proxy`, or turn on the public endpoint with an allowlist |
| A `pg_hba` source rule has no effect | The database sees the endpoint’s address | Control access with users and VPC firewall rules |
| Nobody can see the app’s password | There is no reveal, by design | Use `frazer databases connect`; apps read the password from Secrets |
| A plan refuses a flag | The flag is not on the allowlist for this version | Choose an allowed flag; the plan lists them with their disruption |
| A restore did not change the database | Restores always create a new instance | Check the new instance, then switch your apps to it |
| Storage alert above 85 % | Auto-grow is near its cap | Raise the cap or grow the storage; both are online |
| A `frazer.database.backup.failed.v1` event | The scheduled backup did not finish | Open **Backups** on the instance and take one now with `backups create` |

Quota and capacity errors share one format across Frazer: see [Errors](https://frazer.ai/docs/errors).

## Reference

### CLI

| Command | What it does |
| --- | --- |
| `frazer databases create` | Create a database instance from a plan (alias frazer db). |
| `frazer databases list` | List instances, managed and declared in Git (--source managed\|git). |
| `frazer databases describe` | Show an instance with its endpoints, backups and recovery window. |
| `frazer databases connect` | Open a session over Frazer Link with your Frazer identity. |
| `frazer databases proxy` | Serve an instance on a local port for your own tools. |
| `frazer databases users create` | Create a database user from a role bundle. |
| `frazer databases backups list` | List scheduled, on-demand and final backups. |
| `frazer databases backups create` | Take an on-demand backup. |
| `frazer databases restore` | Restore to a time or log position, into a new instance. |
| `frazer databases undelete` | Bring a deleted database back to its last second, inside its restore window. |
| `frazer databases replicas create` | Add a read replica, in the same site or another one. |
| `frazer databases branches create` | Create a Postgres copy at a point in time with a time to live. |
| `frazer databases upgrade` | Plan a major version upgrade, in place or blue/green. |
| `frazer databases insights top` | List an instance's top queries. |
| `frazer databases ask` | Turn a question into read-only SQL and run it. |
| `frazer databases move-to-managed` | Move a database declared in Git to a managed instance. |

All of them: [CLI reference](https://frazer.ai/docs/cli).

### MCP tools

| Tool | What it does |
| --- | --- |
| `database_instances_list` | List database instances. |
| `database_instances_get` | Describe an instance. |
| `databases_query` | Run a read-only query. |
| `databases_explain` | Explain a query's plan. |
| `databases_insights_top` | List an instance's top queries. |
| `databases_recommendations_list` | List index and tuning recommendations. |
| `databases_backups_create` | Take an on-demand backup. Writes become a plan that waits for approval. |

All of them: [MCP tools reference](https://frazer.ai/docs/mcp).

### Events

| Event type | When it is sent |
| --- | --- |
| `frazer.database.created.v1` | A database instance was created. |
| `frazer.database.failover.v1` | A standby took over from the primary. |
| `frazer.database.backup.completed.v1` | A backup finished. |
| `frazer.database.backup.failed.v1` | A backup failed. |
| `frazer.database.restore.completed.v1` | A restore into a new instance finished. |

All of them: [Events reference](https://frazer.ai/docs/webhooks).

## Related

-   [Databases product page](https://frazer.ai/databases)
-   [In-memory store](https://frazer.ai/docs/memory) for Valkey, next to your databases
-   [Secrets](https://frazer.ai/docs/secrets) for app credentials and `DATABASE_URL`
-   [Serverless](https://frazer.ai/docs/serverless) and the [serverless with Postgres quickstart](https://frazer.ai/docs/quickstarts/serverless-postgres)
-   [VPC and firewall](https://frazer.ai/docs/network) for subnets and private endpoints
-   [Frazer Monitoring](https://frazer.ai/docs/monitoring) for metrics and alerts

## Pages in Data

- [Databases](https://frazer.ai/docs/databases.md) (this page)
- [In-memory store](https://frazer.ai/docs/memory.md)
- [Frazer Storage](https://frazer.ai/docs/storage.md)
- [Secrets](https://frazer.ai/docs/secrets.md)
- [Volumes and snapshots](https://frazer.ai/docs/volumes.md)