Which open-source option replaces Render Postgres for your app
If your Render Postgres bill is rising, or you need recovery and lock-in protection that a managed instance does not give you, PostgreSQL that you operate can replace it. The deciding factor is how much failover and point-in-time recovery (PITR) your app needs, not the database engine itself. For a small app with modest recovery expectations, Coolify or Dokku running a single PostgreSQL container with scheduled S3-compatible backups is usually enough. For an app that needs automatic failover and PITR, plan for CloudNativePG or Patroni on infrastructure you manage. PostgreSQL is released under the PostgreSQL License, a permissive license similar to the BSD and MIT licenses, so the database itself carries no usage fee or copyleft obligation.
Coolify and Dokku both deploy PostgreSQL as a container on a server you control. Coolify's scheduled backups produce pg_dump custom-format archives, upload them to S3-compatible storage and apply retention by count, days or size. The official dokku-postgres plugin offers comparable one-off and scheduled backups to S3-compatible storage. Both give you logical backups and a restore path, but neither provides automatic failover or PITR, so a rollback of the application image will not restore the database. Before you commit, confirm the backup frequency, retention and restore time you need with a test restore into a staging server. CloudNativePG and Patroni add hot standby replicas, failover and WAL archiving for PITR, but they bring Kubernetes or consensus-store operations with them. PostgreSQL does not detect a failed primary by itself, so the failover tooling and its on-call runbook are part of the cost.
Ask each candidate to show how it handles a lost primary, a corrupted table and a major version upgrade. The PostgreSQL versioning policy lists supported major versions, and version 14 reaches end of support on November 12, 2026, so pick a major version that will still be supported for the life of your app. Check the PostgreSQL upgrading documentation for logical replication options that keep downtime short during a major upgrade. Map each recovery requirement you have to a specific mechanism, document who runs the restore, and only then choose between the simple and the high-availability path.
How each Render Postgres capability maps to self-hosted PostgreSQL
This table maps each Render Postgres capability to the self-hosted option that covers it, from Coolify and Dokku for small apps to CloudNativePG or Patroni where you need failover and point-in-time recovery. Read the gap in the Coolify and Dokku column first, since their scheduled backups are logical dumps and do not give point-in-time recovery out of the box. Confirm each behavior against the platform version you plan to run.
| Render Postgres capability | Coolify or Dokku | CloudNativePG or Patroni | Confirm before you commit |
|---|---|---|---|
| Instance tiers | Size is set by the host server's CPU, memory and disk, with no tier catalog | Resources are set in the cluster or VM definition and sized from measured load | Measured peak load and connection counts, not the tier names you used on Render |
| Expandable storage | Data sits on the host volume, so growth means resizing that disk outside the platform | CloudNativePG depends on storage class expansion; Patroni expands the volume on each node | Whether your storage class and filesystem support online volume expansion |
| Point-in-time recovery | Not provided out of the box; restores go to the last scheduled dump | Continuous WAL archiving with base backups gives recovery to a chosen moment | The archive target, retention period and a timed restore test on your version |
| Backups | Scheduled pg_dump custom-format backups to S3-compatible storage with retention by count, days or size | Backups run through the operator or a tool such as pgBackRest, stored in object storage you control | Backup frequency, encryption at rest, and where restore runbooks are kept |
| High availability and failover | Single database container on one server; no automatic standby promotion | Operator or Patroni manages a primary and standbys and promotes one on failure | Failover time, fencing behavior and what your application does during a switch |
| Read replicas | Not a built-in managed option in the platform | Hot standbys serve read-only queries; PostgreSQL does not detect failure on its own | Whether your app routes read queries to standbys and handles replication lag |
| Connection pooling | Run PgBouncer as a separate service next to the database container | Deploy PgBouncer yourself or use the operator's pooler resource where available | Pool mode and maximum client connections for your app's worker count |
| Authentication and major upgrades | Database credentials are set by the platform; TLS and access rules are yours to configure | Certificate, SCRAM or directory-based authentication; logical replication supports major upgrades with brief downtime | Your chosen auth method and a tested upgrade path for PostgreSQL 14 through 18 |
Which self-hosted PostgreSQL option fits your app
Render Postgres bundles provisioning, storage expansion and point-in-time recovery into one managed service. Each self-hosted option below moves some of those duties to your team, so the right choice depends on how much uptime and recovery you need and how much operating work you can carry. Check each card against your recovery objectives before you choose.
Coolify one-click PostgreSQL
Coolify deploys PostgreSQL from a maintained template on a server you connect over SSH. Scheduled backups use the pg_dump custom format, can be uploaded to S3-compatible storage and are pruned by count, days or size. This fits a single-application app with a modest database and a tolerance for restoring from a dump. Recovery is a logical restore, so the restore point is only as recent as your last backup. Confirm how the backup schedule and retention match your recovery needs, and test a restore into a separate server. You own the server, patching, storage and any replication you add.
Dokku dokku-postgres plugin
The official dokku-postgres plugin installs PostgreSQL on the Dokku host, links it to an app so that DATABASE_URL is set, and runs one-off or scheduled backups to S3-compatible storage. It suits a team that already deploys with git push to one server and wants the database managed the same way. The plugin is built around a single server, so the host is a single point of failure. Confirm the backup schedule, retention and restore steps in your own environment. You own the host, the plugin upgrades, the PostgreSQL minor updates and every restore drill.
CloudNativePG on Kubernetes
CloudNativePG is a Kubernetes operator that manages PostgreSQL clusters, replicas and failover inside your cluster. It fits teams that already run Kubernetes, need automated failover and want continuous WAL archiving for point-in-time recovery. The trade-off is that you take on a Kubernetes platform, its storage classes, backup target configuration and the skills to run them. Test failover and PITR restores before you rely on them, because a cluster that has never been restored is not a recovery plan. You own the cluster, the operator upgrades, the backup credentials and the on-call rota for database incidents.
Patroni on virtual machines
Patroni manages PostgreSQL high availability on virtual machines, using a distributed configuration store to coordinate leader election and failover. It fits teams running PostgreSQL on VMs who need automated failover without moving to Kubernetes. PostgreSQL itself does not detect a primary failure or promote a standby, so you must select, configure and test the external failover tooling and the load balancer or DNS switch that clients use. Replication mode, whether synchronous or asynchronous, changes how much data can be lost during failover, so confirm it against your objectives. You own the cluster, the coordination store, the connection routing and the backup and PITR setup.
What point-in-time recovery and failover require when you run Postgres
Point-in-time recovery and automatic failover are two separate capabilities, and PostgreSQL gives you the building blocks for both but not the orchestration. PostgreSQL supports hot standby servers that answer read-only queries, and it offers synchronous replication, where a commit waits for standbys, as well as asynchronous replication. The database itself does not detect that a primary has failed or promote a standby on its own, so automatic failover depends on an external tool such as CloudNativePG or Patroni, plus fencing and a clear rule for how clients find the new primary. Synchronous replication lowers the risk of losing committed transactions during a failover but adds latency to every commit, and asynchronous replication does the reverse. Decide which trade-off your application can tolerate before choosing a topology.
PITR depends on continuous archiving. You need a base backup taken from the cluster plus a continuous stream of write-ahead log (WAL) segments shipped to storage you control, typically S3-compatible object storage. Restoring to a chosen moment means replaying that archived WAL on top of the base backup. A logical dump, such as the pg_dump custom format used by the Coolify and dokku-postgres scheduled backups, is a snapshot of a database at the time it ran and cannot replay changes between snapshots. The two approaches cover different failures, so many teams keep both: dumps for portable copies and selective restores, and base backups with archives for recovery to a specific point. Test the restore path on a schedule, because an archive you have never restored is not yet a recovery plan.
Confirm the retention window against your recovery point objective and recovery time objective before you write the backup policy. Render's three- or seven-day PITR windows are a reference point only, so ask your team how far back an incident might be discovered, how many base backups and WAL days you must keep for that period, and how much storage that adds. Also confirm who owns each piece: the backup job, the archive bucket lifecycle rules, the failover tool, and the runbook that decides when to promote a standby. Those owners carry the work that a managed service previously handled for you.
Choosing between a single server and a clustered database
Coolify fits teams that want a PostgreSQL database next to their applications on one or a few servers they control. You connect the server over SSH, and Coolify deploys PostgreSQL as a managed resource with scheduled backups. Its PostgreSQL backups use the pg_dump custom format, can be uploaded to S3-compatible storage, and run on cron schedules with retention by count, days or size. The platform itself needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on a Linux distribution that Coolify supports. Those figures cover Coolify alone, so size the server for the database and applications as well.
- Logical backups, not point-in-time recovery: Scheduled dumps give you restore points at the times they run. They do not replay changes between dumps, so your recovery point is the last successful backup.
- Single-instance failure domain: If the server fails, the database goes down with it until you restore onto replacement hardware. Confirm your restore time against your own recovery targets.
- Restore testing: Coolify's restore documentation covers importing dumps, but you must rehearse restores on a schedule yourself.
- Operating work: You own OS patching, Docker updates, disk monitoring and off-server backup retention.
- Scale path: Vertical scaling is the simplest lever. Read replicas and automatic failover are not part of this model.
Before you commit, confirm the recovery point and recovery time objectives in writing, and check whether a dump-based restore meets them.
Dokku is an open source PaaS that runs on a single server by default. Its default docker-local scheduler runs containers directly on the Dokku host, so the application, its processes and the database plugin share that machine. Official plugins add PostgreSQL, and the dokku-postgres plugin installs PostgreSQL 18.6 by default. It supports scheduled and one-off backups to S3-compatible storage and exports and imports databases with postgres:export and postgres:import. This model suits small applications where one host and logical backups meet the business need.
- Single-server scope: The default scheduler keeps everything on one host. The k3s scheduler can build a multi-server cluster, but it requires a Docker registry and only the initial Dokku server is configured as the git push target.
- Resource planning: Dokku needs 1 GB of RAM for the default Docker scheduler, but databases, builds and applications compete for the same CPU, memory and disk.
- Backups: Schedule plugin backups to off-host storage and test imports into a clean instance.
- Version currency: Dokku is still versioned 0.x, so plan upgrades and review release notes before each one.
- Database version: The plugin default is not the only choice, so confirm which PostgreSQL major version you need and whether it is still supported.
Confirm that a single host is an acceptable failure domain for this application before choosing this path.
CloudNativePG runs PostgreSQL on Kubernetes and manages replicas, failover and backups for you. This suits teams already operating Kubernetes who need automatic failover and point-in-time recovery. PostgreSQL itself does not detect a primary failure or promote a standby, so an external tool must handle that job. Plan for a cluster with several database instances across failure domains, object storage for WAL archives and base backups, and monitoring for replication lag. Confirm the operator's current feature set and supported PostgreSQL versions with its project before you design around them.
- Failover and replicas: Hot standby servers can serve read-only queries, and you choose between synchronous replication, where commits wait for standbys, and asynchronous replication.
- Point-in-time recovery: Continuous WAL archiving to object storage is what makes recovery to an arbitrary moment possible. Rehearse it.
- Kubernetes overhead: You need cluster operations skills, storage classes, network policies and upgrade procedures for the cluster itself.
- Connection management: Consider a pooler such as PgBouncer when many application instances connect.
- Cost drivers: Replica count, storage, cross-zone traffic and the people time to run the cluster.
Ask which team owns the Kubernetes platform and on-call rotation before you select this option.
Patroni manages PostgreSQL high availability on virtual machines or bare metal, using a distributed configuration store to coordinate leader election. It is a common choice where teams run VM clusters rather than Kubernetes. Patroni supplies the failover logic that PostgreSQL leaves to external tools, while you still provide backups, WAL archiving and point-in-time recovery. A VM-based cluster needs at least three nodes for quorum in the coordination layer, along with load balancing, fencing and monitoring. Verify the current Patroni documentation before you finalize the design.
- Leader election: The coordination store decides which node is primary. Its availability is a dependency you must operate.
- Backup tooling: Pair the cluster with a backup tool such as pgBackRest or Barman and archive WAL to off-host storage.
- Network and fencing: Plan client routing to the current primary and prevent split-brain.
- Upgrades: Major version upgrades use pg_upgrade or logical replication, which allows several seconds of downtime, instead of simple executable replacement.
- Team skills: You need staff who can operate PostgreSQL, the coordination store and the load balancer during incidents.
Run a failover and a point-in-time restore drill in a staging cluster before production depends on either.
The right model follows from your recovery point objective, recovery time objective, data volume and team capacity, not from the platform brand. A single server with scheduled dumps can be a sound choice for a small application that tolerates a restore from the last backup. Once downtime or data loss is costly, the case for replicas, WAL archiving and automatic failover grows. Many teams run the single-server model for development and internal tools while reserving clustered PostgreSQL for customer-facing systems. This tab gives you a checklist to take into that decision.
- Recovery point: Decide how much recent data you can lose. Dumps at fixed intervals set a hard floor.
- Recovery time: Time a full restore of your largest database into a clean host.
- Failure domains: Count what fails together, including the host, the disk, the network and the region.
- Ownership: Name who receives alerts, who restores and who approves upgrades.
- Quote scope: Ask any implementation partner to price the named model, backup storage, monitoring and on-call support separately.
Document the chosen model and its recovery targets in your runbooks before the first production cutover.
How to move a Render Postgres database without losing data
The sequence inventories the source database, copies it with a logical dump, restores and checks it on the target, cuts over with a replication or short write freeze, and proves the new backups can be restored.
Inventory the source database and its connections
Before touching data, record the Render Postgres major version, instance plan, storage size, installed extensions, roles and schemas, and every service that reads DATABASE_URL, including workers and cron jobs. Confirm the connection string and any IP allow-list or TLS settings the services depend on. The step is done when you have a written list that another engineer could use to find every connection to repoint. Ask Render support to confirm which export options your plan includes before you rely on them.
Choose the target and match the major version
Decide where PostgreSQL will run: Coolify's one-click database on a server you control, or the dokku-postgres plugin on a Dokku host, which installs PostgreSQL 18.6 by default. Match or exceed the source major version, and check that every extension you found is available on the target image. PostgreSQL 14 is supported until November 12, 2026, so a source on an older major needs a planned upgrade. The step is done when the target version and extension list are confirmed in writing.
Take a logical dump of the source
Run pg_dump against the Render database using a connection with read access, choosing the custom or directory format so the archive can be restored selectively and in parallel. Keep the dump file and record its checksum. Capture roles separately with pg_dumpall --roles-only if your application depends on them. The step is done when the archive lists its tables and you have verified its checksum on a second copy.
Restore into the target and verify the data
Restore the archive into an empty database on the target. In Coolify, use Import Backup, which accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps. On Dokku, use postgres:import on the service. Then compare row counts for the largest tables, sequence values, and extension objects against the source. The step is done when counts and sequences match and the application can run its migration check against the restored copy.
Synchronize changes and choose the cutover method
Decide between two paths. For a write-heavy database, set up logical replication from the source to the target, which PostgreSQL supports across major versions, and let it catch up. For a small application that can tolerate downtime, stop writes, take a final dump and restore only the changes. Test whether the chosen path works in staging first. The step is done when the replication lag is near zero or the freeze window is agreed with the application owners.
Repoint DATABASE_URL and cut over
Update DATABASE_URL in Coolify or with dokku config:set for each service, then redeploy web services, workers and cron jobs so none keep the old connection. Confirm that no writes still reach Render by checking connection counts and recent write activity on the source. Keep the Render database read-only and running until the new system has been checked. The step is done when every service reports healthy against the new host and the source shows no new writes.
Validate backups and run a restore test
Configure scheduled backups to S3-compatible storage with a retention rule. Coolify's PostgreSQL backups use the pg_dump custom format, and dokku-postgres supports scheduled backups to S3-compatible storage. Then restore the newest backup into a separate scratch instance and run your application checks. Note that a database this setup restores does not give point-in-time recovery, which needs WAL archiving or a managed tool. The step is done when a restore test has passed and the result is recorded with its date.
Which PostgreSQL version to run and how to upgrade it
Pick the PostgreSQL major version by its support window, not by what is newest. The supported majors today are 14, 15, 16, 17 and 18. Version 14 is supported until November 12, 2026, 15 until November 11, 2027, 16 until November 9, 2028, 17 until November 8, 2029, and 18 until November 14, 2030, according to the PostgreSQL versioning policy. A new install should start on 18, which was first released on September 25, 2025. Any cluster on 14 should have a dated upgrade plan well before its end date, because after that date you carry the patching risk yourself. Check the current support table on the PostgreSQL versioning policy before you commit to a version.
Minor releases are the routine work. They never change the internal storage format, so updating means replacing the executables and restarting the server, and the data directory stays as it is. Plan a regular minor update window and test it on a copy of your data first. Major upgrades are different. The documented paths are a dump and restore with pg_dumpall, pg_upgrade, or logical replication from the old major to the new one. Logical replication suits databases where downtime must be measured in seconds, since it works across major versions. For a small app, a pg_dumpall restore into a fresh server is often the simplest choice if a maintenance window is acceptable. Confirm the window with the business owner before you choose.
Version 18 also changes what you configure. Its pg_upgrade keeps planner statistics across major upgrades and adds a --swap option, and it adds an OAuth 2.0 authentication method alongside the SCRAM default direction. MD5 password authentication is deprecated, so set password_encryption to scram-sha-256 and move existing roles to SCRAM before you go live. The dokku-postgres plugin installs PostgreSQL 18.6 by default, so a Dokku deployment starts on a current major, while Coolify's PostgreSQL image choice should be checked in its settings. Before you upgrade anything, confirm the image tag, the backup restore test and the rollback plan in writing.
What teams ask before replacing Render Postgres
What drives the cost of replacing Render Postgres with a self-hosted database?
The cost comes from the servers, the storage for backups, and the people time to operate the database. Render bills Postgres per database plan, so its recurring fee is fixed by the plan you choose. Self-hosting shifts that fee to a server you pay for, plus object storage for S3-compatible backups and the staff hours for upgrades, monitoring and restore drills. Costs rise with data size, the number of replicas you need for failover, and how often you must restore. Ask any quote to list one-time setup separately from monthly infrastructure and ongoing support, and to state which tasks the quote covers after handover.
How long does it take to move a Render Postgres database?
No supplied figure sets a fixed duration, so treat any timeline as something to agree in writing. The timing depends on database size, how many applications connect to it, how much downtime the business accepts, and whether the team already runs PostgreSQL. A small app with a single database and a planned maintenance window is a different job from a database with replicas and strict recovery targets. Ask for milestones: inventory, a rehearsal restore, cutover, and a post-cutover review. Each milestone should name who performs it and what evidence closes it.
What skills does our team need to run PostgreSQL on its own servers?
Your team needs Linux administration, Docker or container operations, PostgreSQL basics, and the ability to read logs and metrics. For small apps, Coolify or Dokku handles much of the setup through a web interface or a git push, so an application engineer with ops experience can run the database. For failover and point-in-time recovery, you need people who understand streaming replication, WAL archiving and a cluster operator such as CloudNativePG or Patroni. PostgreSQL does not detect a failed primary or promote a standby on its own, so an external tool is required for automatic failover.
Can our own engineers do the migration without an outside partner?
Yes, for a single small database with a planned window and a tested restore. The core steps are a logical backup with pg_dump, a restore into the target PostgreSQL, re-pointing the connection string, and verifying data. Dokku's dokku-postgres plugin and Coolify's import feature both accept standard dumps, which simplifies this. Teams with several databases, replicas, strict recovery objectives or compliance evidence needs usually find the rehearsals and documentation take the most effort. Be honest about who will be on call after cutover, because that person owns the database from then on.
Who owns backups and restore tests after the database moves?
After migration, your organization owns backups and restore tests, even if a partner builds them. Coolify runs scheduled PostgreSQL backups in the pg_dump custom format, can upload them to S3-compatible storage, and applies retention by count, days or size. Dokku's plugin offers scheduled backups to S3-compatible storage too. A backup that has never been restored is not proof of recovery, so schedule restore tests into a separate environment and record the results. Note that Coolify's rollback can redeploy an application image but does not restore databases or persistent files, so the database needs its own recovery plan.
What does Coolify Cloud pricing cover compared with the free self-hosted edition?
Coolify Cloud charges $5 per month for 2 connected servers plus $3 per month for each additional server, with a 20% discount for annual billing, according to Coolify's pricing page. You still bring your own servers, while the Coolify management instance runs on Coolify's managed infrastructure. The self-hosted edition is licensed under Apache-2.0 and described as free forever with all features and no limitations. In both cases your servers, database storage, backup storage, monitoring and on-call work are your costs. Ask any partner quote to state whether it includes the Coolify instance hosting, which Coolify edition it targets, and the server count it assumes.
When does outside help make sense for a Postgres replacement?
Outside help makes sense when the database is business-critical, you need automatic failover or point-in-time recovery, or auditors will ask for evidence of controls. DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with deliverables agreed in writing before work starts. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. Ask for a written scope listing the environments, the backup and restore tests, the handover documents, and the retainer options for upgrades such as PostgreSQL minor releases.
Running self-hosted Postgres alongside the rest of the stack
Moving Render Postgres onto your own servers changes how your apps connect, where secrets live, and how you see problems. The cards below cover the pieces that connect the database to the rest of your stack, in the order most teams hit them during a cutover.
Connection pooling with PgBouncer
Render Postgres handles connection limits for you, while a self-hosted database exposes its own max_connections ceiling. Each container replica opens its own connections, so a scaled-out web service can exhaust the server quickly. Place PgBouncer between the app containers and PostgreSQL, then set the pool size and transaction or session mode to match what your framework expects. Check that prepared statements and session-level settings still behave after the switch.
Secrets for DATABASE_URL
On Render, the connection string appears as an environment variable that Render manages for linked services. On Coolify or Dokku, the URL is generated or set by you, and it often appears in logs, build output or backup scripts if handled carelessly. Store the value as a secret in the platform, rotate the database password, and confirm that preview deployments and one-off containers do not inherit production credentials unless you intend them to.
Network placement next to app containers
The database should sit on the same Docker network or private host network as the apps that use it, and it should not listen on a public interface. Confirm which address each app uses to reach the database, since a hostname on the internal network differs from the public IP of the server. Restrict inbound rules at the host firewall to the ports you actually expose, and document which services may reach port 5432.
Observability for the database
Render shows database metrics in its dashboard, but a self-hosted instance only reports what you collect. Decide which signals you need before cutover: connection counts, replication lag if you run standbys, disk growth, slow queries and backup job results. Route them to your monitoring stack and set alerts on backup failures, since a failed nightly dump is easy to miss until a restore is needed.
Keeping Render services during the move
A safe cutover often keeps the Render web services running while the database moves, so the Render app still points at Render Postgres until the new instance is verified. Plan for a short write freeze, a final dump or replication catch-up, and a documented rollback path. Confirm with the apps' owners which environment variables change at cutover, and ask your provider which data remains on Render during the overlap period.
Restore testing before retirement
Coolify's guide for teams leaving managed platforms notes that a rollback can redeploy an application image but does not restore databases or persistent files. Treat restore as a separate, tested procedure. Restore the latest backup into a scratch database, run your application's read paths against it, and record how long the restore took before you decommission Render Postgres.
How DeployOpen scopes and delivers a Postgres replacement
DeployOpen plans, implements, hardens, backs up and documents self-hosted PostgreSQL inside your own cloud accounts, data centers or air-gapped networks, starting from a written scope. We start by confirming which Render Postgres features your applications depend on, then choose between a single-server Coolify or Dokku database and a replicated, failover-capable design.
How we scope
- Inventory every Render Postgres instance, its version, extensions, connection counts and current storage size
- Agree in writing whether recovery needs daily dumps or point-in-time recovery with archived WAL
- Define the target platform, backup destination and who owns on-call response before any work starts
How we build
- Deploy PostgreSQL on the chosen platform with settings, authentication and TLS configured to your written standard
- Configure scheduled backups to S3-compatible storage, and add replication and external failover tooling where scoped
- Test a restore into a separate environment and record the measured recovery steps as evidence
How we hand over
- Deliver runbooks for connection changes, minor updates, major upgrades and restore procedures in your own documentation set
- Walk your operators through backup verification, monitoring alerts and the migration cutover checklist
- Document which controls are configured and what evidence they produce, so your auditors can assess them independently
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
- Ongoing support, upgrades and continuous testing are available as a retainer
- Ask us to confirm any retainer terms, response expectations and the quote that follows from your written scope
