Contents5
Your CRM, your automation tool, your business application: many company tools store their data in PostgreSQL, an open source database. Twenty, the CRM we have operated since early 2025, is one of them: its hosting documentation backs up its data with an export of its Postgres database.
Then comes a decision often taken without noticing: does the database run at a provider that manages it, or on your own server? This guide from our Infrastructure and cloud section describes what each option takes care of, what it leaves to the team, and the criteria that decide. It recommends no provider: the major clouds and European hosts all offer a managed Postgres.
In short
A managed Postgres takes care of updates, automated backups and restoring to a precise point in time.
A self-hosted Postgres costs less in hardware, but that work falls to the team, every quarter.
Each major version of Postgres is maintained for five years: version 14 reaches end of life on 12 November 2026.
A managed backup lives with the same provider as the database: a copy elsewhere is still needed.
Either way, only a tested restore proves the data can be recovered.
What “managed” means in practice
A managed database service is a Postgres that the provider installs, updates, backs up and monitors for you. You get a connection address; the rest is their job. The documentation of Amazon RDS, AWS’s managed database service, gives an idea of what its automated backups cover:
- a retention period adjustable from 0 to 35 days, seven days by default when the database is created from the console;
- restoring the database to any point in time within that period.
Other managed offers, from the major clouds and European hosts alike, have their own durations and options: compare them line by line. Automatic failover to a copy, if the machine fails, is a point to check in each offer, along with its price.
Watch out
A managed backup lives with the same provider
AWS states it in its documentation: if the option to retain automated backups is not ticked when a database is deleted, they are deleted with it. A handling error, a blocked account or a dispute with the provider hits the database and its backups at the same time. A regular export stored elsewhere, in your name, remains the only independent copy.
What a self-hosted database needs, every quarter
Running Postgres on your own server, in a container or not, is perfectly serious. But the work the provider was doing falls to the team, and it recurs. The PostgreSQL project says so in its versioning policy: each major version receives fixes, security ones included, at least once every three months, and it recommends always running the latest minor release. Each major version is maintained for five years, then dropped:
- 12 November 2026
End of life for PostgreSQL 14.
- 11 November 2027
End of life for PostgreSQL 15.
- 9 November 2028
End of life for PostgreSQL 16.
- 8 November 2029
End of life for PostgreSQL 17.
- 14 November 2030
End of life for PostgreSQL 18.
A database installed in 2021 and never upgraded therefore reaches end of life within a few weeks. On your own server, nobody will plan that upgrade for you.
Backups next. The PostgreSQL documentation distinguishes three approaches: the SQL dump, a copy of the database files, and continuous archiving, which lets you go back to a precise point in time. The dump is enough for many companies; continuous archiving is justified when losing a day of data entry costs too much. Our guide to backing up your own server details what breaks in practice.
From the field
On Palmora Property, a real estate portal we operate, the restore test runs in a disposable container and is validated on content: the number of tables and records, not the command’s exit code, which reports an error on mere warnings. On our own server, on 5 July 2026, a badly targeted clean-up command destroyed the containers of ten services in one go: the data survived because it lived in volumes separate from the containers, and our operating rules are now written down.
Managed or self-hosted: the criteria that decide
Managed Postgres
Updates, backups and point-in-time recovery handled
Automatic failover offered depending on the plan
Higher price for the same machine, rising with options
Settings limited to what the provider exposes
Self-hosted Postgres
Cost of the machine alone, on a server already paid for
Full control over version, extensions and tuning
Updates, backups and restore tests are on you
Monitoring and on-call to organise
Five questions decide, in this order:
- Who will do the work? If nobody in the team or at your provider has time to apply quarterly updates and test a restore, managed is the answer.
- How much data can you lose, and how long can you stay down? These are the two objectives set by the disaster recovery plan. The more demanding they are, the more point-in-time recovery and automatic failover matter.
- What does the difference cost? Compare the price of the managed service with the machine and the operating time, over three years. Our article on the five items that inflate a cloud bill helps read the options.
- Where must the data live? Provider region, applicable law, contracts: our article on dependence on the American cloud sets out the questions.
- Can you leave? Postgres is still Postgres: a standard export lets you move from one provider to another, or from managed to your own server. Just watch out for provider-specific extensions, which make leaving more costly.
Key takeaway
The choice is not about Postgres, which is the same on both sides, but about who handles updates, backups and the night of the outage.
Where to start
- List your databases
Which tool, which Postgres version, where it runs, who is responsible.
- Check end-of-life dates
Starting with any database still on version 14.
- Run a restore test
Of each database, validated on content, and note how long it takes.
- Store a regular export outside the provider or the server
In your name.
- Decide database by database
Managed when nobody can handle operations, self-hosted when the team or your provider can.
The database is part of the infrastructure foundation shared by your projects. The rest of the section covers neighbouring decisions: dedicated server, VPS or cloud, Kubernetes and mid-sized companies, monitoring, NIS2 in France, self-hosted n8n in production, which tools to move out of SaaS first, the three-year cost of leaving SaaS, cloud migration without breaking things, the team password manager, stolen API keys, the hardware to run an AI model yourself and choosing a business email provider.
For self-hosted tools whose databases are backed up off the server with a tested restore, see our Leaving SaaS offer. For an opinion on an existing database, describe your setup to us.
Frequently asked questions
Does a managed Postgres cost more than a self-hosted one?
For the same machine, almost always, since the price includes the operating work. The real comparison adds to the self-hosted Postgres the time spent on updates, restore tests and monitoring, over three years. For a small database on a server that is already in place and well run, self-hosting is often cheaper; for a critical database with no team to look after it, the extra cost of managed is quickly justified.
Can you move from a managed Postgres to a self-hosted one, and back?
Yes. A standard export of the database can be restored on the other side, provided you target a compatible version and avoid provider-specific extensions. The difficulty lies mainly in the downtime during the copy: it gets planned, and a large database needs a replication method to shorten it.
Is a Postgres database in Docker reliable in production?
Yes, on two conditions: the data lives in a volume separate from the container, and backups leave the server with a tested restore. A container can be destroyed and recreated without harm if its data is elsewhere; that is what protected our services during our incident of 5 July 2026.
What should we do if our Postgres version reaches end of life?
Plan the major version upgrade: test it on a copy of the database, check that the tool using it supports the new version, then switch over with a fresh backup and a planned rollback. After end of life, no more security fixes are published for the dropped version.
Sources
- Twenty, self-hosting with Docker Compose (new tab)docs.twenty.com
- AWS, Amazon RDS, Backup retention period (new tab)docs.aws.amazon.com
- AWS, Amazon RDS, Introduction to backups (new tab)docs.aws.amazon.com
- PostgreSQL, Versioning Policy (new tab)postgresql.org
- PostgreSQL, Backup and Restore (new tab)postgresql.org
Jim · founder of Brain Plus AI
Also in infrastructure and cloud
Practical guide7 min
Backing up your own server: what really breaks
Everyone knows the 3-2-1 rule, but what loses data is more mundane: a backup never restored, a forgotten volume, a global clean-up command run in production. Here is what we learned from operating our own server.
Practical guide8 min
Disaster recovery plan: what has to be written down
The day a server, a data centre or an account disappears, it is too late to decide the order of things. What a disaster recovery plan must contain, the two figures management must set, and how to know it works.
Choose and price8 min
Dedicated server, VPS or cloud: choosing by use
Dedicated server, VPS or cloud: none of them is the right choice for everything. What really sets them apart, the four questions that decide for each use, and why most companies end up combining all three.