DataProduct page Pricing

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.

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
Console

Plan the instance. The plan shows the cost, the quota impact and the disruption level, and changes nothing.

frazer databases create storefront --engine postgres --version 18 \
  --tier db-g1-4 --ha --site ovh-vint-hill --storage 200 --dry-run

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

Apply it: run the same command without --dry-run.
Check the instance, its endpoints and its recovery window.
Terminal window
```
frazer databases describe storefront
```

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, 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.

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.

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

From a laptop or an agent

# 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

# 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 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.

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

# 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.

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 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.

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.

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.

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.

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.

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.

Databases product page
In-memory store for Valkey, next to your databases
Secrets for app credentials and DATABASE_URL
Serverless and the serverless with Postgres quickstart
VPC and firewall for subnets and private endpoints
Frazer Monitoring for metrics and alerts