Managed Postgres on your servers.
With point-in-time recovery from day one.
Create Postgres 16 to 18 from the console, the CLI, the API or MCP. Frazer runs it with standbys, pooling and backups, keeps a 7-day recovery window in production by default, and puts it behind a private endpoint in your VPC. On your own servers it is part of the server fee.
Frazer runs the database.
Your apps see one private name.
A managed database runs in a data cluster Frazer operates on your servers, never inside your project’s cluster. Apps reach it through a private endpoint in your VPC; people and agents connect over Frazer Link. Base backups and the write-ahead log go to Frazer Storage.
From your apps
A private endpoint in the subnet you pick, with one DNS name and three entries:
rw,roandpooled. Kubernetes and serverless apps getDATABASE_URLfrom Secrets.From a laptop or an agent
frazer databases connectopens a session andfrazer databases proxyserves local tools, both over Frazer Link with your Frazer identity. No public address needed.From the internet
Off by default. Turn it on and you get an address with an IP allowlist and TLS
verify-full.
Two storage types.
One product.
Shared keeps every copy and every past version in storage. Local NVMe keeps each copy on its server’s own disk for the lowest read latency. Move between them online.
Shared
Every copy and every past version live in storage: replicas in seconds, restores to any second, and no committed data lost when a server fails, even with one instance.
--storage sharedLocal NVMe
Each copy sits on its server's own disk, for the lowest read latency.
--storage local-nvmeMove between them online
One API and one product: change a database's storage type with a plan, while it serves traffic.
storage: SHARED or LOCAL_NVMEBack to the second before it broke.
Into a new instance, never in place.
Frazer takes a daily base backup and archives every change as it happens, so a restore replays the log up to the second you pick. It always lands in a new instance next to the old one: you check it, then switch.
# Restore to a second, into a new instance
frazer databases restore storefront --to storefront-restore \
--time 2026-10-14T09:30:00Z
# storefront keeps serving until you switch to the new one# Every backup, scheduled, on demand and final
frazer databases backups list storefront
# Take one now, before a risky migration
frazer databases backups create storefront# A read replica behind the ro endpoint
frazer databases replicas create storefront-r1 --of storefront
# A copy for one pull request, gone in a day
frazer databases branches create storefront-pr-42 --of storefront --ttl 24hHigh availability by default.
Every change says what it disrupts.
Before you apply a change, its plan names the disruption: none, reload, rolling, restart or downtime. You apply it now or in your maintenance window.
Standbys with failover
A primary and two standbys on three servers, with automatic failover. Synchronous commit to a quorum of one standby is an option. On by default in production projects.
Read replicas
Extra read-only instances in the same site, behind the
roendpoint. Cross-site replicas for disaster recovery, promoted by a live action.Maintenance windows
A day and an hour, three hours long. Staging projects first, production a week later; seven days’ notice by email, console and webhook; deny periods up to 90 days.
| Change | How Frazer does it | Disruption in the plan |
|---|---|---|
| Minor version or patch | Automatic in the window: standbys first, then a switchover | Rolling: reconnects 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; now or in the window |
| More storage | Grown online; auto-grow at 80 % up to a cap you set | None |
| Less storage | Restore into a smaller instance | A new instance |
Minor versions apply on their own in the window. An engine version leaves support with 12 months’ notice.
Proved, not claimed.
Checked on every release.
Every release
The storage engine passes formal models of its protocols, a deterministic simulation of the whole storage layer with disk, network and clock faults, isolation checks on recorded histories, and a comparison of results with standard Postgres.
Every week
Every page of every database is verified.
Every day
Every production database is restored into a scratch copy and checked. Each database's page shows its last checks.
Every number
Benchmarks, from a suite derived from TPC-C to open-loop latency and replays of real traces, are published with their scripts, settings and raw results, compared at matched cores and matched price against the leading managed Postgres services, and rerun with one command on Frazer, free, or against any Postgres you name. Run the same suites on a branch of your own database before you choose a size.
See the query that got slow.
And the index that fixes it.
Insights read Postgres’s own statistics through a read-only role and compare today with the last 7 days. When load rises after a rollout, you see which query moved and what would fix it. Advice never applies itself: it becomes a plan or a pull request.
Top queries
From
pg_stat_statementsthrough a read-only role: time, calls and rows per normalized query, load by wait class, notable queries, unused and missing indexes.Index advisor
Candidates from your top queries, checked with
hypopgwhat-if plans. Advice becomes a plan or a migration file for your repository, never an automatic change.Ask in plain English
Questions become SQL that runs as a read-only role, with
EXPLAINand estimated rows shown first, row and time limits, and every generated query audited.
Everything around the database.
Run by Frazer, changed by plan.
Postgres 16 to 18
With pgvector and pgvectorscale for vectors.
Pooling on by default
A connection pooler in transaction mode on its own
pooledendpoint; session mode as an option.Extensions from a signed catalog
Licenses checked before each is added. No uploads of arbitrary libraries.
Storage that grows
Shared grows with your data; Local NVMe grows online, with auto-grow at 80 % up to a cap you set.
Power off
Stops compute, keeps configuration and backups. Deleted after 180 days, with warnings at 30, 7 and 1 days.
Metrics and alerts
Connections, lag, cache hit ratio, locks; alerts for storage above 85 %, failed backups and replication lag.
Branches
A copy at a point in time with a time to live, for a pull request.
ClickHouse and Qdrant
The same list, create page, backups and maintenance.
Guards for agents
Statements that would change every row of a table, and destructive DDL, are blocked for agents unless they run as a plan a person approves.
Schema changes without downtime
Migrations rehearsed on a branch, applied online under a lock budget, and reverted in seconds within 30 minutes.
Query budgets
Each query pattern's cost is estimated before it runs: a statement over its budget is refused with the limit and the command to ask for more. Each agent has its own budget.
Defaults tuned to the shape
Huge pages everywhere and, on Local NVMe, WAL and I/O settings set from the drive, in a table you can read and change.
Who may touch the data.
And what a cap can never do.
Who may do what
- Developer
- Creates and changes instances, users and databases through plans that state their disruption.
- Viewer, Responder
- Read instances, metrics and backups.
- Anyone with connect
- Opens a session with
frazer databases connect; the permission isdatabases.instances.connect. - Agents
- Read, query read-only and plan. DDL, resize, restore and flag changes wait for a person.
What is logged
- Every applied plan, as a revision of the instance
- Live actions: backup now, switchover, restore
- Every database login with Frazer IAM, per person or agent
- Every query the assistant generates
At the cap
- Deletion protection on by default in production projects
- Delete takes a final backup that outlives the instance
- A spend cap never stops a database: it pauses fleet compute, and databases keep running
- A restore never overwrites: it always creates a new instance
No premium on your servers.
Included in the server fee.
On your own servers a database uses their capacity and is part of the per-core server fee. Backups, the write-ahead log and final backups count against the Frazer Storage allowance. On the Frazer fleet, managed nodes bill $0.039 per vCPU-hour, the fleet rate plus 30 %, and $0.0075 per GiB-hour, and standbys on Shared that serve no reads at the fleet rates.
See every priceDatabases, answered.
Where does a managed database run?
In a data cluster Frazer runs for the server pool you place it on, never inside your project’s cluster. Your project gets its own namespace there, and the capacity counts against your project’s share of the pool. The primary and its standbys sit on different servers, on Shared or Local NVMe storage, and backups go to Frazer Storage.
Can I restore over the running database?
No. A restore always creates a new instance at the time or log position you pick, so the running one is untouched. You check the new instance, then switch your apps to it.
How do people get the password?
They don’t: there is no reveal button. Applications get generated credentials from Secrets, delivered by the cluster’s secret sync and rotated on a schedule, with two valid versions during the switch.
People and agents connect with frazer databases connect or proxy over Frazer Link, which mints a short-lived database login for their own identity, with no password at all.
We already declare Postgres databases in Git. Do we have to move?
No. Databases declared in your environment repository keep working and show in the same list with a From Git badge: status, metrics, backups, the recovery window and connect details, with the spec read-only. Backup now, switchover and restore to a new instance work as audited live actions. When you want Frazer to run one, Move to managed copies it into a managed instance by logical replication, with the lag shown live.
Can I have high availability on one server?
No. High availability puts a primary and two standbys on three servers, so it needs three servers in the pool. A one-server site offers single-instance tiers, and the create page says why.
Which engines besides Postgres?
ClickHouse and Qdrant, with the same list, create page, backups and maintenance. MySQL, Kafka, OpenSearch and a Mongo-compatible engine on request. Valkey lives in the In-memory store.