Managed PostgreSQL means a provider runs the database for you, handling backups, point-in-time recovery, failover, patching and monitoring, while your team just connects and builds. Self-hosting gives you full control and can look cheaper on the server bill, but only pays off if someone on your team has the time and skills to do that operational work reliably, every week. For most SMEs and product teams without a dedicated database administrator, managed is the lower-risk choice.
What "managed" actually covers
Managed does not mean "nothing to do". It is a shared-responsibility model, and it helps to be clear about who owns what.
| Task | Self-hosted | Managed |
|---|---|---|
| Server provisioning and OS patches | You | Provider |
| PostgreSQL minor version updates | You | Provider (usually in a maintenance window) |
| Backups and retention | You | Provider |
| Point-in-time recovery | You build and test it | Provider |
| Replication and automatic failover | You | Provider |
| Monitoring and alerting | You | Provider, with dashboards for you |
| Network access and TLS | You | Shared |
| Schema design, indexes, slow queries | You | Still you |
| Access roles for your applications | You | Still you |
The last two rows matter. A managed service will keep a badly indexed database online, but it will not make it fast.
Backups and point-in-time recovery
A nightly pg_dump is a start, but it only captures the database at one moment and can be slow to restore for larger databases. Serious setups combine physical base backups with continuous archiving of the write-ahead log (WAL). That enables point-in-time recovery (PITR): restoring to, say, 14:32, just before someone ran a DELETE without a WHERE clause.
If you self-host, tools such as pgBackRest, WAL-G or Barman do this well. You still need to:
- store copies off the database server, ideally in another location, and encrypt them;
- define retention (how many days you can go back);
- run restore drills on a schedule, because a backup you have never restored is only a hope;
- agree on RPO (how much data you can afford to lose) and RTO (how long you can be down).
High availability and failover
High availability usually means a primary server streaming changes to one or more standbys. Replication alone is not enough; something has to detect a failed primary, promote a standby, and redirect applications. Self-hosted teams typically use Patroni with a consensus store such as etcd, or a Kubernetes operator such as CloudNativePG, plus a connection layer (HAProxy, PgBouncer or DNS). Done badly, failover can produce "split brain", where two servers both accept writes. That is one of the hardest database problems to clean up.
With a managed service, failover is part of the product. Read the SLA carefully: what uptime it promises, what counts as downtime, and whether the standby sits in a different zone or region.
Upgrades
The PostgreSQL project ships minor releases regularly (at least quarterly) with security and bug fixes, and each major version is supported for about five years. Minor updates are low risk but still need a restart. Major upgrades need pg_upgrade or logical replication, checks for extension compatibility, and application testing. Self-hosters often postpone them, then find themselves on an unsupported version.
Monitoring
Whoever runs the database should be watching, and alerted on:
- disk space and WAL growth (a full disk stops the database);
- connection counts and connection pool saturation;
- replication lag;
- long-running transactions and locks;
- autovacuum activity and table bloat;
- slow queries, via the
pg_stat_statementsextension.
Self-hosted teams commonly use Prometheus with postgres_exporter and Grafana dashboards. The tooling is free; the time to tune alerts and respond at 2 a.m. is not.
Security
Whichever route you take: keep the database off the public internet (private network, VPN or strict IP allowlists), require TLS, use SCRAM-SHA-256 authentication, give each application its own least-privilege role, encrypt backups, and patch promptly. If the database holds customer data, Thailand's PDPA expects you to protect it and to be able to show how.
Total cost of ownership
Comparing only the server price is the most common mistake. A fair comparison over a year looks like this:
| Cost item | Self-hosted | Managed |
|---|---|---|
| Compute and storage | Primary server | Included in the service fee |
| Standby server for failover | Roughly doubles compute | Included, depending on plan |
| Backup storage off-site | Extra | Usually included |
| Monitoring stack | Setup and hosting | Usually included |
| Engineer time: setup, upgrades, drills | Significant and recurring | Minimal |
| On-call coverage | Needed for real HA | Provider's responsibility |
| Cost of an incident | Fully yours | Reduced, with SLA terms |
For a small team, engineer time and incident risk usually outweigh the difference in server bills.
When self-hosting makes sense
Self-hosting is a reasonable choice when:
- you already have experienced DBAs or SREs and an on-call rotation;
- the workload is large and steady enough that hardware savings are substantial;
- you have strict data-residency or air-gapped requirements no provider can meet;
- you need extensions or configuration that managed services do not allow;
- it is a development, test or learning environment where downtime is acceptable.
What about Redis?
Redis is often used as a cache, session store, rate limiter or lightweight queue. As a pure cache it is forgiving, because data can be rebuilt. Once it holds sessions or jobs, it needs the same care as a database: persistence (RDB snapshots and/or AOF), replication with Sentinel or Redis Cluster for failover, a maxmemory limit with a sensible eviction policy, and no exposure to the internet, since open Redis instances are routinely attacked. Also note that Redis changed its licence in 2024 and added an AGPLv3 option with Redis 8 in 2025, while Valkey emerged as an open-source fork. A managed service lets you skip most of that decision-making.
Vectorkub managed infrastructure
Vectorkub's managed infrastructure service runs PostgreSQL, Redis, RabbitMQ, MongoDB, Elasticsearch and MinIO on a pay-as-you-go basis, with a 99.9% uptime SLA, automated backups and monitoring, regional failover, and the ability to scale up or down at any time. It is the same stack we use for our own products, including systems like the ones in our payment gateway integration guide.
FAQ
Is managed PostgreSQL slower than self-hosted?
Not inherently. Performance depends on CPU, memory, storage and configuration, and on network distance between your application and the database. Keep them in the same region or network.
Can I move from self-hosted to managed later?
Yes. Smaller databases can be moved with a dump and restore during a maintenance window. Larger ones can use logical replication to keep downtime to minutes.
Do I still need a DBA with a managed database?
You need someone who owns schema design, indexing and query performance. You no longer need someone to handle backups, patching and failover.
What RPO and RTO should a small business aim for?
It is a business decision, not a technical one. Ask how much data and how much downtime you can tolerate before customers or revenue are affected, then choose a setup that meets it and test it.
Next step
If your team spends more time babysitting databases than building features, it may be time to hand that work over. Contact us to discuss your workload, and we will suggest a plan and a migration path.
