The managed vs self-hosted database choice comes down to one question: do you want to be the database administrator, or pay someone else to be? A managed database hands the patching, backups, failover, and tuning to a provider for a monthly fee. Self-hosting on a server you control is cheaper and more flexible, but the operational work becomes yours. If you have the skills and want to save money, self-host. If you would rather your engineers build features than babysit a database, go managed. There is no universally correct answer, only the one that fits your team.
This guide defines both options, compares them across the things that matter (cost, maintenance, backups, high availability, scaling, and security), and gives you a checklist to decide. We will also cover the honest middle ground that most growing teams land on.
What is a managed database versus a self-hosted one?
A managed database is one a provider runs for you. You get a connection string and a dashboard; they handle the server, the operating system, patching, backups, and failover. A self-hosted database is software you install and run yourself, usually on a virtual private server (VPS) or your own hardware. You own every layer, from the OS up.
Most people mean PostgreSQL or MySQL when they say "database," and both can be run either way. Managed versions go by names like Amazon RDS, DigitalOcean Managed Databases, Neon, or Supabase. Self-hosting means you run Postgres or MySQL on a box you rent or own, often inside a container, and you are the one logging in when something breaks. If the term VPS is new, our explainer on what a VPS is covers the foundation this all sits on.
The split is not about the database software. PostgreSQL is the same engine in both cases. The difference is who is responsible for keeping it healthy, secure, and recoverable. That single line of responsibility is what you are choosing between, and it shapes every tradeoff below.
How much does each one cost?
Managed databases cost more per month but include the operational work in the price. Self-hosting on a VPS is dramatically cheaper on paper, often 60 to 70 percent less for the same hardware, but the savings only hold if you do not value the hours you spend running it. The true comparison is not server price against server price, it is server price plus your time against the managed fee.
The raw numbers are stark. For a mid-range configuration of 4 vCPUs, 16 GB of RAM, and 1 TB of storage, a managed AWS RDS instance runs around $266 a month, while the equivalent self-managed EC2 instance is around $98, and a comparable box on a budget host like Hetzner can be near $80 (OnlineOrNot). The managed markup is real: one analysis pegged AWS RDS at roughly 93 percent more than the underlying compute, a premium that "pays for automated backups, Multi-AZ failover, monitoring, and CloudWatch integration" (selfhost.dev).
That markup is either a bargain or an outrage depending on your scale. At small sizes it buys you peace of mind cheaply. At large scale it can fund an entire team. One administrator running a colocated SQL Server cluster put it bluntly: every time they priced out RDS to replace it, the cost was "so unrealistically expensive that I just have to laugh," with the markup alone "enough to pay for the colocation rack, the AWS Direct Connects, the servers, the SAN, the SQL Server licenses, the maintenance contracts, and a full-time in-house DBA" (Hacker News). The lesson is not that managed is bad, it is that the math flips as you grow.
What maintenance does each one require?
Managed databases handle the recurring operational chores for you: security patching, minor version upgrades, configuration, and monitoring setup. Self-hosting hands all of that back. You apply OS and database patches, tune the configuration, watch the metrics, and respond when something falls over, often at an inconvenient hour. The work is not constant, but it is yours, and it never fully goes away.
On a self-hosted box, the baseline tasks are non-negotiable. You secure access to the database, monitor CPU, RAM, disk, and slow queries, and keep an eye on the server itself (OnlineOrNot). None of this is hard for an experienced administrator, and a single well-configured Postgres instance can run for months untouched. But "untouched" is a gamble. Patches land, disks fill, and a query that was fast at ten thousand rows crawls at ten million.
One honest caveat cuts against the managed side: major version upgrades are frequently still your job even on managed plans. The provider keeps you patched within a version, but moving from one major Postgres release to the next is usually a decision you make and a migration you oversee. Managed reduces the maintenance burden, it does not erase it. Tuning is the other gray area. Managed services expose fewer knobs, so if your workload needs a non-default configuration or a specialized extension compiled a particular way, self-hosting gives you control the managed plan will not.
Who handles backups and point-in-time recovery?
Managed databases include automated daily backups and point-in-time recovery (PITR), the ability to rewind your database to a specific moment, usually any second within a retention window. Self-hosting means you build that yourself: scheduled dumps, write-ahead log archiving for PITR, and off-site copies. The mechanics are well understood, but you own getting them right and, more importantly, testing them.
For self-hosting, plenty of people get by with very little. One developer described running Postgres on a $5 VPS "with a 10-line shell script and cron job for backups to Backblaze B2" (Hacker News). That works for a side project. PITR is harder. Recovering to an arbitrary point in time requires archiving write-ahead logs continuously and knowing how to replay them, which is a meaningful step up from a nightly dump.
The rule that survives every database horror story is the same one that applies to any hosting: a backup you have never restored is not a backup. Whether the provider runs it or you do, you are responsible for confirming that recovery works before you need it. Managed plans make this easier with a tested PITR feature, which for many teams is reason enough to pay the markup. If you self-host, schedule a restore drill, not just a backup job.
What about high availability and scaling?
High availability means your database survives a single machine failing, usually through an automatic failover to a standby replica. Managed services offer this as a checkbox (often called Multi-AZ), and they handle the replication and the failover logic. Self-hosting it is possible but genuinely hard: you configure streaming replication, a failover mechanism, and the connection routing yourself, and you test that it works under failure.
This is where the gap between the two options is widest. Setting up a single Postgres instance is a beginner task. Setting up automatic failover that does not lose data or split-brain under a network partition is an expert one. If your uptime requirements are serious, the engineering cost of building reliable HA yourself can dwarf the managed markup, which is part of what that 93 percent buys.
Scaling splits in two directions. Scaling up (a bigger box) is easy either way: managed services resize with a click, and on a VPS you move to a larger plan. Scaling out (read replicas, connection pooling, sharding) is where managed pulls ahead in convenience, since it provisions replicas and poolers for you. Self-hosting gives you the freedom to architect it however you want, at the cost of doing the architecting. For most small and mid-size workloads, a single right-sized instance is plenty, and the urge to build for scale you do not have yet is one of the more expensive mistakes in this space.
How do the two compare on security and compliance?
Both can be secure; they put the responsibility in different places. A managed database handles OS hardening, network isolation, encryption at rest, and timely patching as part of the service, which removes a class of mistakes. Self-hosting gives you full control over the security posture, including data residency and audit access, but every one of those controls is now yours to configure correctly and keep current.
For many teams, the managed model is a security win precisely because it removes the chance of an unpatched server sitting on the internet. The provider patches on a schedule, isolates the network, and encrypts storage without you thinking about it. That is a meaningful reduction in attack surface for a team without a dedicated operations person.
Self-hosting wins when control is the requirement, not a preference. If you must keep data in a specific jurisdiction, restrict who can touch the underlying host, or meet an audit requirement that a shared managed environment cannot satisfy, running your own database may be the only path that fits. The tradeoff is honest: you trade the provider's patching discipline for control, and you have to supply that discipline yourself.
So which should you pick, managed or self-hosted?
Pick managed if you do not want to be the DBA, your uptime needs are real, or your team is small and should be shipping features instead of tuning Postgres. Pick self-hosted if you have the operational skills, want to cut cost meaningfully, or need control that managed plans will not give you. The decision is mostly about your people and your priorities, not the technology.
Run through these criteria honestly:
- Team skills. If nobody on the team is comfortable doing a database restore, configuring replication, or reading slow-query logs, managed is the safer call. Self-hosting assumes you can be the DBA, or already are.
- Budget versus time. Self-hosting saves money only if your hours are cheaper than the markup. As one developer running their own infrastructure put it, the whole point was "to not have to pay that kind of money for my projects with no revenue" (Hacker News). For a funded team where engineer time is the scarce resource, that math inverts.
- Uptime needs. If downtime costs you customers or money, the automatic failover in a managed plan is hard to beat without serious in-house expertise. If a few minutes of downtime during a restart is fine, you do not need to pay for HA you will not use.
- Compliance and control. Strict data residency, audit, or custom-extension requirements push you toward self-hosting. Standard workloads do not need it.
The path most teams travel is worth naming: start managed when you are small and moving fast, stay managed while the markup is cheaper than a hire, and consider self-hosting once you are paying a provider what a full-time engineer would cost. That crossover point, not a principle, is when self-hosting starts to pay for itself.
The honest middle ground
The cleanest middle path is self-hosting on a VPS if you have the skills, and managed if you do not. A modest VPS running Postgres in a container, with scripted off-site backups, handles the workload of most applications for a fraction of a managed plan's cost, and you keep full control. The catch is the word "skills." That setup is only cheap if you can run it, and quietly fix it when it breaks.
If you do go self-hosted, a few habits keep it sane:
- Right-size the box, do not over-provision. A single well-tuned instance covers most workloads. Resist building for scale you do not have. Our guide on how to choose a VPS walks through sizing CPU, RAM, and disk for a database workload.
- Automate and test backups off-site. A scheduled dump to separate storage is the floor. Restore from it at least once so you know it works.
- Decide if you need PITR and HA before you build them. They add complexity. Add them when the workload justifies it, not by default.
- Patch on a schedule. The convenience you gave up by self-hosting is exactly the patching cadence a managed provider would have handled, so put it on a calendar.
For teams choosing where to run that VPS, the same logic from picking any host applies, which we cover in which hosting type is best for small websites. A managed database (including what we offer at Carpathian) removes this entire list, which is the point of paying for it. If you would rather not run the server, that is a perfectly good reason to go managed, and not a sign you did anything wrong.
The best database is the one you stop thinking about: backed up, patched, and sized for the work in front of you. Whether you reach that by paying a provider or by running a tidy server yourself, pick for the team you have today, keep your own off-site copy either way, and add complexity only when a need shows up.
