Managed PostgreSQL hosting

Workflow and dataOn-prem or sovereign site

Managed PostgreSQL on dedicated machines in Switzerland, the EU or your own datacentre, with backups you can restore to the minute and upgrades you approve. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about PostgreSQL

Licence: PostgreSQL
Runs on: Your own hardware, or any of twelve Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: www.postgresql.org

Running PostgreSQL in production: what it takes

Size and deploy
A supported major version on a dedicated machine sized for your data, with the configuration kept as a file in your repository.
Archive continuously
The write-ahead log ships to an offsite bucket as it is written, beside a nightly full backup, so recovery can target any minute in the retention period.
Add a standby
Streaming replication to a second machine, with failover planned and rehearsed rather than improvised.
Restore on a schedule
Once a month we restore to a chosen minute in a scratch environment and compare row counts against production.
Patch and upgrade in your window
Minor releases carry security fixes and are applied in your window. Major upgrades are tested against a copy of your database first, then applied with the previous cluster ready to take back over.

What PostgreSQL is, and who runs it

Managed PostgreSQL on machines you choose

PostgreSQL is the relational database most of the apps we operate run on, and many teams run their own products on it too. We operate it as a service: a dedicated server in any of 12 Pilae Cloud regions, six of them in Switzerland and the EU, or on your own hardware, with backups, replicas, monitoring and upgrades handled by us.

The difference from Amazon RDS or Azure Database for PostgreSQL is where it runs and who controls it. The database sits on a machine dedicated to you, in the jurisdiction you pick. It answers only on your private network. It is standard PostgreSQL, so a plain dump takes your data anywhere else.

PostgreSQL backups with point-in-time recovery

Every server archives its write-ahead log continuously to a second location, beside a nightly full backup. That allows recovery to any minute inside your retention period, which your contract specifies. We restore to a chosen minute every month and record the result, so the backup is proven before the day you need it. Probes check the server every 60 seconds and alert a Pilae engineer when replication lags or disk space runs low.

PostgreSQL upgrades, planned and approved

Minor releases carry security fixes and arrive a few times a year. Major versions arrive once a year and need a planned upgrade of the whole cluster. The Pilae Agent plans each one, takes a verified backup, waits for your approval and applies it in your window. Every step is written to the audit log in the console.

Managed operations run under an SLA with a 99.9% monthly availability commitment and service credits. Pricing is on request. Talk to us about the database you want to move.

PostgreSQL system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 2 vCPU · 8 GBA starting point. Memory sets how much of your working data stays cached, so it grows with the database rather than with users.
Storage: Local NVMeOn a dedicated machine, not network storage. Latency on the write-ahead log is what most workloads feel first.
Backup target: S3-compatible bucketFull backups and the continuous WAL archive go here, in a different location from the database server.
Replica: 1 standby, optionalStreaming replication to a second machine for failover and for read-heavy reporting.
Connection pooling: PgBouncerKeeps hundreds of application connections from becoming hundreds of server processes.
Access: Private network onlyThe database answers on your private mesh. It never has a public address.

Migrating from Amazon RDS to PostgreSQL

Leaving Amazon RDS is a database move, not a rewrite. PostgreSQL is PostgreSQL on both sides, so your schema, your queries and your application code come across unchanged. What needs planning is the cutover. For a small database, a dump and restore in a short window is enough. For a large or busy one, we set up logical replication from RDS to the new server, let it catch up, and switch the application over in minutes. Extensions are checked first, because RDS ships a curated set and a few are AWS-specific. Parameter groups become a configuration file in your repository, and IAM database authentication becomes roles tied to your identity provider.

Inventory the instance
Version, size, extensions, parameter settings, roles and every application that connects. AWS-specific extensions are flagged here, not on cutover night.
Replicate while you keep working
Logical replication streams changes from RDS to the new server. The source stays live and the copy catches up in the background.
Verify the copy
Row counts, checksums on the tables that matter, and your own test suite run against the replica before anything switches.
Switch the connection string
Writes pause briefly, the last changes drain, and applications repoint. The RDS instance stays available until you confirm the move.

A night on a managed PostgreSQL server

postgres · db-017 lines

00:00infowal archive: continuous, last segment shipped 4s ago

01:00infofull backup: ok in 6m12s, checksum verified

01:07infobackup copied offsite: ok, second location

02:30inforestore drill to 01:45:00: ok, 214 tables, row counts match

03:15infovacuum analyze on orders: ok, 1.2M rows

04:02inforeplica db-02: streaming, lag 0.3s

06:00infoslow query report: 3 queries over 500ms, sent to owners

An example overnight window: the write-ahead log is archived continuously, the nightly full backup is verified, and a restore drill proves the backup can come back to a chosen minute.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What drives the price of running PostgreSQL

Pricing is on request: a fixed price for onboarding, then a monthly price for PostgreSQL, quoted in writing within five business days. The plans set what every deployment includes; these are the inputs the quote is built from.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Essential, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where it is passed through at cost plus a fixed margin.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

PostgreSQL: common questions

Is managed PostgreSQL from Pilae compatible with Amazon RDS?

Yes. It is standard PostgreSQL, so drivers, ORMs, migrations and SQL written for RDS work unchanged. The only checks are AWS-specific extensions and features such as IAM authentication, which we list during the inventory.

Can we recover the database to a point before a bad deployment?

Yes. Continuous WAL archiving allows point-in-time recovery to any minute inside your retention period. Your contract specifies that retention, and we rehearse a restore every month.

Who has access to our data?

Your team, through roles you control. Pilae engineers use separate named accounts, every session is logged in the audit trail, and you can revoke that access at any time. The server has no public address.

Where do the database and its backups live?

On dedicated machines in the Pilae Cloud region you choose, from 12 regions, six of them in Switzerland and the EU, in ISO 27001-certified datacentres or on your own hardware. Backups go to a second site in the same jurisdiction.

Is PostgreSQL free to use?

Yes. The PostgreSQL Licence is a short permissive licence with no editions, seat counts or paid tier. You pay for the machines and for our operation of them, not for the database.

Back to apps

Bring us your PostgreSQL. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing