You can also create a managed PostgreSQL instance and let the cloud provider handle a big part of the operational work.

The confusing part is not setting up the database.

It is understanding which problems you are actually agreeing to own when you choose one over the other.

The Problem It Solves

Before managed databases became common, running a production database usually meant running the database server yourself.

You had a machine, installed PostgreSQL or MySQL on it, configured storage, opened the right network ports, created users, scheduled backups, watched disk usage, applied security patches and figured out what to do when the machine died. Moving that server to AWS EC2, Google Compute Engine or an Azure VM did not fundamentally change that model.

The hardware became someone else's problem.

The database was still yours. That is where managed database services came in.

Services such as Amazon RDS and Google Cloud SQL take over a large part of the infrastructure and database operations. With a VM, you still have to deal with things like the database software, operating system, backups and scaling. With a managed service, the provider takes responsibility for many of those layers.

But there is an important detail here:

Managed does not mean someone else manages everything.

It means the responsibility boundary has moved.

That distinction is the foundation of this entire comparison.

What It Actually Is

Let's take PostgreSQL as an example.

Option A: PostgreSQL on a VM

Your architecture might look something like this:

             Your Responsibility
                    |
                    v
          +-------------------+
          |      Cloud VM     |
          |                   |
          |   Linux / Ubuntu  |
          |         |         |
          |     PostgreSQL    |
          |         |         |
          |   Database Storage|
          +-------------------+
                    ^
                    |
                 Your App

The cloud provider gives you the VM infrastructure. You handle the rest.

If PostgreSQL needs an upgrade, you plan it.

If the disk fills up, you deal with it. If backups fail, you need to find out why.

If the VM dies and you never built a proper recovery strategy, that is also your problem.

Now compare that with a managed database.

Option B: Managed PostgreSQL

With something like Cloud SQL:

         Your Application
                |
                v
      +----------------------+
      |      Cloud SQL       |
      |                      |
      |      PostgreSQL      |
      |                      |
      |      Backups         |
      |      Maintenance     |
      |      Monitoring      |
      |      HA / Failover   |
      +----------------------+
                |
                v
      Cloud Provider
       Infrastructure

The database still runs on compute and storage underneath.

The difference is that you do not manage that underlying VM like a normal Compute Engine machine.

Google handles infrastructure, operating system and database software maintenance, while you remain responsible for things such as database configuration, access control, query optimization and deciding whether you need HA or disaster recovery features.

That distinction is the entire topic.

Managed DB does not remove responsibility. It removes a specific class of responsibility.

How Developers Actually Use It

Suppose I am deploying a small Node.js API with PostgreSQL.

For a self-hosted setup, I might create a VM:

gcloud compute instances create postgres-vm
--zone=asia-south1-a --machine-type=e2-medium

Then SSH into it:

gcloud compute ssh postgres-vm

Install PostgreSQL:

sudo apt update sudo apt install postgresql postgresql-contrib

At this point, the database is running.

But the work is not over.

I still need to think about:

PostgreSQL configuration Users and authentication Firewall rules Private networking Backups Backup verification Disk capacity Monitoring Upgrades Replication Failover Disaster recovery

That is a lot of responsibility for a database that might initially have 50 users.

With Cloud SQL, the equivalent starts much closer to:

gcloud sql instances create my-postgres
--database-version=POSTGRES_16 --region=asia-south1

Then:

gcloud sql databases create appdb --instance=my-postgres

Your application connects to the managed instance instead of you maintaining the PostgreSQL server itself. Cloud SQL provides built-in capabilities around backups, replication, maintenance, monitoring and high availability.

But this is where the comparison actually gets interesting.

What Most Tutorials Don't Tell You

This is where the managed vs self-hosted decision becomes more complicated than a simple pricing comparison.

4.1 Managed Does NOT Automatically Mean Highly Available

This is probably one of the easiest things to misunderstand. You create a managed database and think:

"The cloud provider manages it, so my database is highly available."

Not necessarily.

For example, Cloud SQL's HA configuration uses a primary and standby across zones, with synchronous replication to persistent disks in both zones.

But you have to configure the HA setup for that protection. Without HA, you can still be dealing with a single database instance failure.

The same idea exists with RDS. Multi-AZ is a specific deployment configuration. Simply using RDS does not mean every database is automatically highly available.

So remember:

Managed != HA

and

Backup != HA

A backup helps you recover. HA helps you keep operating when an instance or zone fails. Those are two different problems.

4.2 Your Managed Database Can Still Surprise You on the Bill

People often compare:

VM: ₹X/month
Managed DB: ₹Y/month

and stop there.

That comparison is incomplete.

Database cost can include compute, provisioned storage, backups, I/O or network transfer depending on the provider and configuration.

For example, Cloud SQL backup storage is charged separately based on backup usage. Automated backups are incremental, while on-demand backups remain until you manually delete them.

So a database that looks small from the application's perspective can still accumulate additional storage-related costs.

But the opposite mistake is just as common.

A "$20 VM" is not necessarily a "$20 production database" if you also need:

VM + Persistent disk + Backup storage + Monitoring + Replica + Failover setup + Engineering time + Incident response

The last two are especially easy to ignore because they do not necessarily appear on your cloud bill.

And that is one of the biggest traps in this comparison:

You are not only choosing infrastructure cost. You are choosing operational cost.

4.3 Managed Databases Still Have Maintenance Windows

Another common assumption is:

"The provider manages updates, so updates don't affect me."

They can.

Cloud SQL separates infrastructure updates, online updates and maintenance updates. Some maintenance operations involving the operating system or database program can require an instance restart. Google provides scheduling and controls to reduce the impact.

That is still much less work than manually patching and maintaining an entire database server.

But your application should still assume that database connections can disappear.

That means you should have:

• Connection retry logic

• Sensible timeouts

• Connection pooling

• Graceful error handling

The managed service reduces operational work.

It does not eliminate distributed systems problems.

4.4 Self-Hosting Gives You Freedom, Then Charges You for That Freedom

There are legitimate reasons to run PostgreSQL yourself.

Maybe you need:

• A PostgreSQL extension unavailable in the managed service

• OS-level access

• An unusual filesystem configuration

• A specific PostgreSQL build

• Deep kernel or database tuning

• Complete control over upgrade timing

With a VM, you control the machine.

That is powerful.

It is also exactly why you are responsible for the consequences. AWS even has RDS Custom for situations where customers need privileged OS access or more customization than normal RDS provides.

That tells you something important.

The choice is not always: Managed vs Self-hosted

Sometimes there is a middle ground.

The better question is: How much control does this workload genuinely require?

4.5 The Scariest Database Problem Isn't Always the Database

GitLab's famous 2017 database outage is a good example (This is what i got to know while exploring for this article).

GitLab.com was running PostgreSQL with a primary and secondary. During an incident, replication lagged. While engineers were trying to rebuild the secondary, an engineer accidentally deleted data from the primary instead.

The recovery process then exposed another problem.

Their normal backup process was not producing usable backups.

GitLab eventually recovered from an older staging snapshot, losing roughly six hours of database data and spending many hours restoring service.

The lesson is not:

Self-hosted databases are bad.

GitLab was operating at a scale and complexity where self-managed PostgreSQL gave them capabilities they needed.

The more uncomfortable lesson is this:

A backup that has never been restored is an assumption, not a recovery strategy.

And this applies to managed databases too.

A cloud provider can automate backups.

You still need to know:

• How long are they retained?

• Where are they stored?

• What happens during a region failure?

• How quickly can you restore?

• Can your application reconnect?

• Can the data actually be recovered?

Having a backup and having a tested recovery process are not the same thing.

When Should You Use Which?

Here is the framework I actually use.

Choose a Managed Database When You are building a normal production application

A common architecture might look like:

You probably do not want your development team spending Friday night manually patching PostgreSQL.

Your team is small

If you have three developers, having one of them become the unofficial "Postgres person" can create a serious operational dependency.

The database should support the product.

It should not become a separate job nobody planned for. You need backups and HA without building everything yourself, Managed services provide mechanisms for backups, failover and maintenance. You still need to configure them correctly, but you are not starting from an empty VM.

Consider Self-Hosting When You need deep customization

If the managed service prevents an important database extension or configuration you genuinely need, a VM may make sense.

You already have strong database and infrastructure expertise

If your team already operates PostgreSQL clusters, replication, monitoring, backups and disaster recovery, the operational burden is very different.

The workload is unusual

Some specialized workloads simply do not fit neatly inside the constraints of managed services.

You have a clear reason for the control

This is the important part.

Do not choose self-hosting because:

The VM is cheaper.

Choose it because:

We need something the managed service cannot provide, and we are prepared to operate it.

That is a very different argument.

A Simple Decision Framework

The mistake is starting with:

"Which one is cheaper?"

Start with:

"Which operational responsibilities am I willing to own?"

Then calculate the cost.

The Real-World Lesson

GitLab's 2017 incident is a useful reminder that database architecture is about much more than choosing PostgreSQL versus MySQL or VM versus managed service.

• Their system had replication.

• They had backups.

• They had snapshots.

• They had engineers.

And yet the recovery process still failed because the pieces did not work together reliably when they were actually needed.

That distinction matters.

A production database is not just:

Database -> Store Data

A managed database takes several of those boxes away from you. A VM gives those boxes back to you. Neither architecture magically makes them disappear.