Skip to main content

Managed PostgreSQL database

Most applications need a relational database, and PostgreSQL is the default pick: ACID transactions, rich types, a mature extension ecosystem. Running it in production is a different job: replication, automatic failover, transaction-log archiving, tested backups, version upgrades. Bunker takes that load off your hands.

Under the hood, each database runs on PostgreSQL 18 driven by CloudNativePG, the reference open source Kubernetes operator. You get a standard connection string and you build.

Why managed PostgreSQL?

A lone PostgreSQL on a VPS holds up until something breaks. Production needs at least a standby ready to take over, continuous backups, and a way to rewind the database to a precise moment after a mistake. CloudNativePG orchestrates all of that.

The cluster runs several instances spread across separate datacenter zones, with strict anti-affinity: two replicas never run on the same zone. If the primary goes down, the operator promotes a standby within seconds and repoints the service. Your application keeps talking to the same endpoint.

Two tiers

The Pico tier, at €25/mo, fits small projects, staging environments and low-traffic apps. The Nano tier, at €50/mo, targets production apps with more connections, memory and volume. You move between tiers as your load grows, without recreating the database.

Comparison with alternatives

CriterionBunkerSelf-hostedAWS RDSGoogle Cloud SQLScaleway
EnginePostgreSQL 18PostgreSQLPostgreSQLPostgreSQLPostgreSQL
Sovereign hostingYes (France)Up to youNo (USA)No (USA)Yes (EU)
High availabilityIncluded, multi-zoneUp to youPaid optionPaid optionOption
Point-in-time recoveryIncludedTo configureYesYesYes
Daily backupsIncludedTo configureYesYesYes
MonitoringIncluded (Prometheus, Grafana)To set upCloudWatchCloud MonitoringBasic
CLOUD ActNot subjectUp to youSubjectSubjectNot subject
PricingFrom €25/moTime + serverInstance + storage + I/OInstance + storage + I/OPay-as-you-go

What actually changes

PostgreSQL is PostgreSQL everywhere: the same database, the same queries, the same pg_dump. The difference comes down to sovereignty and price. Your data stays in France, out of reach of the CLOUD Act, and the bill is a flat monthly amount rather than a sum of instance, provisioned storage and per-million I/O.

You leave whenever you want: a pg_dump, a pg_restore elsewhere, and you're done. You depend on no proprietary format and no in-house service.

Typical use cases

Main application database. Your API needs a reliable database behind it. You grab the connection string, put it in your environment variables, and deploy.

Staging and tests. Take a Pico tier for staging and a Nano tier for production: the same database serves both sides, which avoids the surprises of a local SQLite drifting away from production Postgres.

Database behind a managed service. Already hosting Matomo, Odoo or Metabase on Bunker? They run on the same PostgreSQL foundation. A dedicated database for your own application slots in naturally.

Incident recovery. A SQL migration goes wrong at 6pm? Thanks to continuous WAL archiving, you rewind the database to its 5:59pm state, to the minute, within the retention window.

High availability and backups

Each database is streamed to standbys placed on other zones. Failover is automatic: the operator watches the primary and promotes a standby when needed, with no action on your side.

On backups, two mechanisms stack. A full base backup ships every night to encrypted S3 storage, in France. In parallel, the transaction logs (WAL) are archived continuously. Together they enable point-in-time recovery (PITR): you rewind the database to the exact minute you want, not just to the last nightly backup. The default retention covers 30 days.

Everything is instrumented for Prometheus. If you run the managed Grafana stack, your database metrics land in your dashboards with no extra configuration.

Why not self-host?

An apt install postgresql on a VPS costs a few euros. Production asks for more:

AspectSelf-hostingBunker
High availabilityA single serverMulti-zone replicas, automatic failover
WAL archivingTo configure (barman, wal-g)Included
Point-in-time recoveryTo configure and testIncluded
Off-site backupsTo set upEncrypted S3 in France
Version upgradesTo planManaged
MonitoringTo installPrometheus + Grafana included
Base tuningUp to youTuned parameters (connections, buffers)

The real cost of self-hosting is not the server, it's the on-call. A production database with no standby and no PITR turns the smallest outage into a sleepless night.

Quick start

1. Subscribe to the service

  1. Go to console.getbunker.net and create an account
  2. Pick the PostgreSQL database and the tier (Pico or Nano)
  3. You receive your credentials and your connection string

2. Connect

The connection string follows the standard PostgreSQL format:

postgres://app:<password>@<your-database>.getbunker.net:5432/app?sslmode=require

With psql:

psql "postgres://app:<password>@<your-database>.getbunker.net:5432/app?sslmode=require"

Two endpoints are provided: one read-write (the primary) and one read-only (the standbys), handy to offload reporting queries.

3. Wire up your application

Any PostgreSQL client works. Set the connection string in your framework's environment variable:

DATABASE_URL="postgres://app:<password>@<your-database>.getbunker.net:5432/app?sslmode=require"

TLS-encrypted connections are required by default (sslmode=require).

Migration from your current database

PostgreSQL is standard end to end, so migration uses the usual tools:

# Export from your current database
pg_dump "postgres://user@old-database:5432/mydb" -Fc -f mydb.dump

# Import into Bunker
pg_restore -d "postgres://app:<password>@<your-database>.getbunker.net:5432/app?sslmode=require" mydb.dump

For a cutover without a long downtime, do a first cold import, then replay the delta just before repointing your application.

Known limits

The port is the standard 5432. Access goes through TLS and sslmode=require is enforced: an old client that can't encrypt won't connect.

Available extensions are the ones shipped with the CloudNativePG image. If you need a specific extension like PostGIS or pgvector, talk to us before subscribing to confirm it's packaged.

Resizing between tiers happens without data loss, but triggers a short switchover while the new parameters take effect. Plan it outside peak hours.

Next steps