# A managed database, end to end

> Managed Postgres with backups, point-in-time recovery, patching and monitoring. See how an app connects and how a schema change ships.

Source: https://customhosted.com/databases/

№ 01 Databases

A managed database for anything that needs to remember something: nightly backups, point-in-time recovery, patching, and monitoring, at one fixed monthly rate. This page also covers how your app actually reaches it, how a schema change ships, and what happens when one fails halfway.

From $12/mo [See full pricing →](https://customhosted.com/pricing)

№ 02 Sizing

## Three tiers, one rate each

From a side project to a production workload — sized for memory and storage, with retention that grows alongside the tier.

- DB Starter — Shared-tier Postgres · 1 GB RAM · 10 GB storage — Side projects, small apps — Daily backups · 7-day retention — $12/mo
- Recommended — DB Standard — Postgres · 2 GB RAM · 40 GB storage — Production apps — 7-day PITR — $25/mo
- DB Plus — Postgres · 4 GB RAM · 100 GB storage — Heavier production workloads — 30-day PITR — $49/mo

Full rate detail, add-ons and fair-use limits live on the rate card → [Pricing](https://customhosted.com/pricing)

№ 03 What goes in one

## What a database actually holds

A database holds anything an app needs to remember. Here is what that actually means.

- Records with a fixed shape — Users, orders, subscriptions, comments. — Rows an app reads and writes constantly. They must stay consistent with each other. This is most of what a database is for.
- Anything that must survive a restart — A shopping cart, a login session, a saved draft. — If losing it on a redeploy would be a real problem, it belongs here, not held only in a running process.
- What it is not for — An uploaded photo, a generated report file. — Those are files, not rows, and they live on a different kind of storage. See [Files](https://customhosted.com/files).

№ 04 How it connects

## How your app reaches it, hop by hop

What a connection string actually is, why the network stays private, and what a pool limit means in practice.

1. 1 — Your app holds one secret — A single connection string, kept the way any other secret is — never written into the code itself. See [Access](https://customhosted.com/access#secrets). — You
2. 2 — The path between app and database is private — Not reachable from the open internet at all — only from the app it is attached to. — CustomHosted
3. 3 — A connection comes from a shared pool, not one at a time — A pool is a small set of open connections an app reuses, instead of opening and closing one for every query. It is faster. It is also what has a limit. — CustomHosted
4. 4 — The tier sets that limit — Every tier caps how many connections it will hold open at once. Staying near that cap for more than a spike is the outgrown signal on the ladder below. See [Scaling](https://customhosted.com/scaling#ladder). — CustomHosted

№ 05 Changing the schema

## A schema change, step by step

The migration is yours to write, or a CodeHerder brief's to open. Everything after that is ours — including what happens if it fails halfway.

1. 1 — The migration is written — A new column, a new index, a changed constraint — the migration is application code. Write it yourself, or let a CodeHerder brief open it as a pull request. — You
2. 2 — Tried against a copy first — Pulled in on request from a recent backup, or seeded with placeholder data if a real copy isn't needed for the check being done. See [Environments](https://customhosted.com/environments). — CustomHosted
3. 3 — A snapshot is taken before it runs — Nightly dump, plus point-in-time recovery on the tiers that carry it. See [Recovery](https://customhosted.com/recovery). — CustomHosted
4. 4 — It runs inside the same deploy — No separate migration step to remember. The pipeline that ships the code runs the migration too. — CustomHosted
5. 5 — If it fails halfway — The pipeline halts and the last known-good version keeps serving; a human is notified. See [Monitoring](https://customhosted.com/monitoring). — CustomHosted

You do not have to write the migration yourself. Describe the change in plain language instead. From the brief onward it takes the same path as every other reviewed change on this platform, which [Patching](https://customhosted.com/patching) describes in full. That is the Agentic iteration — CodeHerder add-on ($25/mo):

1. 1 — Briefed as a change — Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers. — CustomLabs
2. 2 — An agent opens the pull request — The upgrade lands as a real pull request against the repository, with the test suite run against it. — CodeHerder
3. 3 — A human reviews and merges — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind. — CustomLabs
4. 4 — It ships through the same pipeline — The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit. — CustomHosted
5. 5 — You're told it's done — A note confirming what changed and that it merged, in the same shape as every other note on this site. — CustomHosted

№ 06 Operations

## Managed end to end

The database is yours, but running it isn't your job — we keep it backed up, patched, [watched](https://customhosted.com/monitoring), and encrypted.

- Automated daily backups
- Point-in-time recovery
- Managed patching & minor-version upgrades
- Monitoring & alerts
- Encrypted at rest and in transit
- A human who answers

The tick list above promises minor-version upgrades. Version upgrades run on two tracks. What changes between them is who asks for the move, and when it runs:

- Minor version — Standing window, monthly — A brief connection blip, noted after the fact. See [Patching](https://customhosted.com/patching). — CustomHosted
- Major version — Only when you ask, in a window you pick — A major release can change how the engine behaves, so it never applies itself. You ask for the move. It runs the same way as a tier change: scheduled, snapshotted first, rollback ready. See [Scaling](https://customhosted.com/scaling). — CustomHosted

№ 07 Backups & retention

## The honest retention story

Backups run nightly on every tier. Point-in-time recovery (PITR) lets you roll the database back to a specific moment, not just the last snapshot — and how far back you can go grows with the tier.

| Tier | Retention |
| --- | --- |
| DB Starter | Daily backups · 7-day retention |
| DB Standard Popular | 7-day PITR |
| DB Plus | 30-day PITR |

A retention window is only useful if a restore from it actually works — see [what a restore actually involves](https://customhosted.com/recovery).

№ 08 What we watch

## What we watch, and who hears about it

Connections, replication, and backup completion — logged continuously, escalated to a human once anything crosses a safe margin.

| Signal | What fires it | First response | Auto or human |
| --- | --- | --- | --- |
| Connections, replication, and backup completion | A connection pool running out, replication falling behind, or a nightly backup that never reported success | Logged and, for anything past a safe margin, handed to a human the same day | Auto, then human |

1. 1 — Auto-handled — Restart, retry, or redeploy the last known-good version, done automatically — No one, unless it recurs — it goes in the log, not a message to you
2. 2 — You hear from us — A human looks at it and decides what to do — revert, restore, or a fix in code — You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent
3. 3 — Outage handling — Worked ahead of the routine queue — You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk

№ 09 Outgrowing a tier

## The signal, and the next rung

Every rung names the signal that means you've outgrown it, and exactly where it points next.

| Tier | Outgrown when | Next step |
| --- | --- | --- |
| DB Starter | Storage fills past headroom, or a second app wants to share the same database. | Move to DB Standard — more memory, more storage, and point-in-time recovery. |
| DB Standard | Connections sit near the pool limit, or query volume needs more memory to stay fast. | Move to DB Plus — production sizing with extended retention. |
| DB Plus | One database can no longer hold the whole workload on its own. | A Custom quote for a database shaped around the workload — see "When a bigger box is the wrong answer" below. |

"When a bigger box is the wrong answer" is [on Scaling](https://customhosted.com/scaling#architecture).

№ 10 Data in, and out

## Getting the data in, and out

Moving in from wherever it runs today, and taking a copy with you whenever you leave.

- A one-time import, on the way in — A dump from wherever the database runs today, restored into the new tier ahead of the cutover. Checked before anything points at it for real. See [Migrations](https://customhosted.com/migrate).
- A standard dump, on the way out — Standard dump format. Restore into any compatible database. See [Portability](https://customhosted.com/portability).

№ 11 What it costs

## What it costs

See [Billing](https://customhosted.com/billing) for the invoice, and [Pricing](https://customhosted.com/pricing) for the full rate card.

- Storage is billed inside the tier, not on the instance disk — Sized and billed as part of the tier itself: 10 to 100 GB, depending which one. That is a different disk from the one an app writes to. See [Files](https://customhosted.com/files).
- A longer backup window is the one add-on — Extended backup retention (30-day), +$8/mo — daily backups kept for 30 days instead of 7.

№ 12 Worked example

## The database this site does not have

We sell a managed database and run none ourselves. Here is why that is the right call for this site.

- This site keeps no database at all — The one form on customhosted.com posts to a relay and keeps nothing — no row is ever written or read back.
- That is the right call for a marketing site — A quote form does not need to survive a restart. It does not need a later query either. Adding a database here would add risk, not value.
- The moment that stops being true — The day this site needs to show a customer their own account or history, it needs a real database. One of the tiers on this page would do — sized the same way as any other app.

№ 13 Said plainly

## The honest limits

Not buried in a footnote — the same discipline as every other honesty band on this site.

- No read replicas today — When read traffic alone is the bottleneck, a second database built for reads is a rebuild, not a resize. See [Scaling](https://customhosted.com/scaling) for the rest of it.
- No automatic failover to a second machine — One instance is one instance. Losing it triggers a restore, the same procedure as any other data-loss event. There is no silent switch to a standby. See [Recovery](https://customhosted.com/recovery) for the rest of it.
- Query tuning is consulting work, not a managed feature — A slow query needs a person to read it and rewrite it. That is real engineering, not a setting anyone flips. It is CustomLabs work, quoted like any other change.
- Postgres today, another engine on request — This page prices Postgres. A different engine is a custom quote, sized and reviewed the same way as any other bespoke shape. See [Custom](https://customhosted.com/custom) for the rest of it.

№ 14 Attach

## Stands alone, or attaches to any plan

A managed database doesn't need a reason to exist on its own — but it's built to pair with the rest of the stack just as easily.

Run it standalone, or attach it to any Static or Dedicated plan — add the database's flat rate to the base plan's, and that's the total. No egress arithmetic, no connection-count surprises.

[Size it on the estimator →](https://customhosted.com/pricing#estimate) [Pricing](https://customhosted.com/pricing)

№ 15 Answers

## Database questions

The questions that come up once "just add a database" stops being a one-line decision.

1. 01 What actually happens if too many connections open at once? Each tier caps how many it will hold open. Running near that cap for more than a brief spike is exactly the "outgrown" signal on the ladder above — it gets flagged, and the fix is either a bigger tier or fixing a connection leak in the app.
2. 02 Who writes the schema migration? You do, or a CodeHerder brief does on your behalf as a pull request. Everything after that — the snapshot, running it inside the deploy, what happens if it fails halfway — is ours.
3. 03 What happens if a migration fails halfway through? The same thing that happens to any other deploy that fails partway: the pipeline halts and the last known-good version keeps serving, with a human notified. The pre-migration snapshot is there if anything needs restoring from before it ran.
4. 04 Who upgrades the database version? Minor versions move on the same standing patch window as everything else — a brief connection blip, noted after the fact. A major version never applies itself; you ask for it, and it runs on a window you pick, the same way a tier change does.
5. 05 Do you offer read replicas or automatic failover? Not today. A read replica is a rebuild CustomLabs can design once read traffic alone is the bottleneck, not a setting to switch on. Losing the one instance is a restore, the same procedure as any other data-loss event.
6. 06 Can you help with a slow query? Query tuning is real engineering, not a managed feature we flip on — it's CustomLabs work, designed and quoted like any other change.
7. 07 Does this database ever hold my customers' data? This site's own form doesn't — it posts to a relay and keeps nothing. The tiers on this page exist for your app, sized the same way whether it holds ten rows or ten million.

№ 16 Keep reading

## What databases connect to

- [Your data What sits in a table here — the personal data your app stores, who can reach it, and what deleting it actually does.](https://customhosted.com/your-data)
- [Logins One reason to attach a database at all: a real home for the session store behind your app's login.](https://customhosted.com/logins)
- [Pricing The full rate card — flat, predictable, and posted in the open.](https://customhosted.com/pricing)
- [Dedicated compute A dedicated instance to attach the database to, sized to the workload.](https://customhosted.com/dedicated)
- [Static hosting Static sites and SPAs served from the edge network, deployed on every push.](https://customhosted.com/static)
- [Scaling The database ladder in full, and what "outgrowing a tier" actually means.](https://customhosted.com/scaling)
- [Environments What a staging copy of the database actually holds before a schema change ships.](https://customhosted.com/environments)
- [Recovery What a restore actually involves, and the retention ladder behind it.](https://customhosted.com/recovery)
- [Portability The full handover pack, including the database dump this page's exit row reuses.](https://customhosted.com/portability)
- [Access How a connection string is held as a secret, and who can reach it.](https://customhosted.com/access)
- [Configuration Where the connection string itself lives once it leaves this page — a setting, a secret, and how one changes.](https://customhosted.com/configuration)
- [Forms A submission saved as a row is one of the destinations a form's endpoint can write to.](https://customhosted.com/forms)

## Sizing a database, or planning a schema change?

Brief it through the same quote channel as any other request — an agent opens the pull request, a human merges it, and the same pipeline ships it.

[Get a quote →](https://customhosted.com/contact)