--- title: "Databases: managed Postgres with point-in-time recovery · Frazer" description: "Managed Postgres on your own servers: standbys with failover, pooling, a private endpoint in your VPC, daily backups and point-in-time recovery into a new instance, with every change a plan that states its disruption." url: https://frazer.ai/databases index: https://frazer.ai/llms.txt tokens: 3849 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Databases: managed Postgres with point-in-time recovery · Frazer **Databases** frazer.ai # 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. [Create a database](https://frazer.ai/start?product=databases) [Read the docs](https://frazer.ai/docs) *The storefront database in the Frazer console: PostgreSQL 18.1, healthy and managed. A primary and two standbys run on three servers behind a pooler. The recovery panel shows any second of the last 7 days restorable, daily base backups, an off-site copy, the write-ahead log archive and a passed restore drill. Beside it: the private endpoint, production checks and the next maintenance window.* A managed Postgres instance and its recovery window product UI, demo organization 01 · How it works Fig. 1 ## 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. **Fig. 1** Where a managed database runs, and how it is reached - ### From your apps A private endpoint in the subnet you pick, with one DNS name and three entries: `rw`, `ro` and `pooled`. Kubernetes and serverless apps get `DATABASE_URL` from Secrets. - ### From a laptop or an agent `frazer databases connect` opens a session and `frazer databases proxy` serves 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`. 02 · Storage ## 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 shared` - ### Local NVMe Each copy sits on its server's own disk, for the lowest read latency. `--storage local-nvme` - ### Move between them online One API and one product: change a database's storage type with a plan, while it serves traffic. Failover Designed for **under 4 seconds** at p99 Restore Designed to restore any second of the last 7 days in **about 10 seconds** Size Designed to grow to **256 TiB** per database New Postgres versions Designed to arrive within **60 days** of their release Commits Designed to be durable on three racks in **under 1 ms** at p99, inside one site Query path Designed for **under 0.2 ms** at the median through the pooled endpoint, inside one site API `storage: SHARED` or `LOCAL_NVME` 03 · Backups and recovery ## Back 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 24h ``` Point in time Any second of the last **7 days** in production, 1 day in staging; 1 to 35 days, your choice Base backups Daily in your backup window; 14 daily, 8 weekly and 12 monthly kept Where Frazer Storage, with an optional copy at another site Restore Into a **new instance**, at a time or a log position; never in place On delete A final backup that is kept after the instance is gone Restore drill Daily for production instances, monthly for the rest, with the result on its page 04 · Replicas and upgrades ## High 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 `ro` endpoint. 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. Changes to a database, how Frazer makes them, and the disruption the plan states | 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. 05 · Checks ## 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. 06 · Query insights Fig. 2 ## 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. *Query insights for storefront in the Frazer console: database load against its 7-day baseline, rising after a rollout of checkout-api; the top queries by total time with calls, p95 latency and rows; and the index advisor proposing one index, with its what-if evidence, its build cost and a choice to run it as a plan, a migration pull request or now.* **Fig. 2** Query insights for one database product UI, demo organization - ### Top queries From `pg_stat_statements` through 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 `hypopg` what-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 `EXPLAIN` and estimated rows shown first, row and time limits, and every generated query audited. 07 · What you get ## 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 `pooled` endpoint; 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. 08 · Controls ## 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 is `databases.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 09 · Pricing ## 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 price](https://frazer.ai/pricing#lines) Your servers **Included** in the per-core server fee Frazer fleet $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 Fleet rates $0.030 per vCPU-hour, $0.007 per GiB-hour, per second vCPU A hardware thread; two vCPU are one core Standbys on Shared At the fleet rates while they serve no reads; a standby that serves reads bills as a read replica, at the managed rates Backups 100 GB per server included, then $0.012 per GiB-month Powered off Backups only Network No per-GB fees Benchmark reruns A published report's shape, free for up to 40 hours per account per release Questions ## Databases, 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](https://frazer.ai/memory). ## More in Data - [**In-memory store** Pick the engine and version](https://frazer.ai/memory) - [**Frazer Storage** Objects next to servers](https://frazer.ai/storage) - [**Secrets** Write-only for people](https://frazer.ai/secrets) - [**Volumes and snapshots** NVMe or replicated](https://frazer.ai/volumes) ## Postgres you don’t have to run. On the servers you already have. [Create a database](https://frazer.ai/start?product=databases) [Read the docs](https://frazer.ai/docs)