- In a managed database the provider runs the operating system and database software, applies patches, takes backups and handles failover; you still own schema design, query tuning, access control and cost.
- AWS's own responsibility table for Amazon RDS lists application optimisation as the customer's job under every model, including RDS.
- Self-managing a database on a virtual machine gives full control (any engine version, any extension, OS access) at the cost of doing all operational work yourself.
- Cost is driven by instance size and hours, storage, backup retention, high-availability standbys and data transfer, not by the instance price alone.
What is a managed database?
A managed database is a database engine (PostgreSQL, MySQL, SQL Server and so on) that a provider runs for you as a service. You create it through a console or API by choosing an engine, a size and a region, and you connect to it with the same drivers and tools you would use for a database on your own server. The provider owns the machines, the operating system and the database software, and automates the routine operational work.
The providers describe their services in these terms. AWS calls Amazon RDS "a managed database service" that is "responsible for most management tasks". Microsoft describes Azure SQL Database as a fully managed platform as a service that handles upgrading, patching, backups and monitoring without user involvement, and states that Microsoft handles all patching and updating of the SQL and operating system code. Google describes Cloud SQL as a fully managed relational database service for MySQL, PostgreSQL and SQL Server. DigitalOcean presents its Managed Databases as an alternative to manually installing, configuring, maintaining and securing databases.
"Fully managed" is a marketing phrase as much as a technical one. It means the provider handles the infrastructure and the database software lifecycle; it does not mean the database is designed or tuned for your workload.
What the provider handles and what you still own
The clearest official statement of the split is the comparison table in the Amazon RDS documentation, which sets on-premises servers, databases on Amazon EC2 virtual machines and Amazon RDS side by side. The rows below follow that table.
| Task | On-premises | Self-managed on a cloud VM | Managed database |
|---|---|---|---|
| Application optimisation (schema, queries, indexes) | You | You | You |
| Scaling | You | You | Provider (you choose when and how far) |
| High availability | You | You | Provider (an option you enable and pay for) |
| Database backups | You | You | Provider (you set retention) |
| Database software patching and install | You | You | Provider |
| Operating system patching and install | You | You | Provider |
| Server maintenance and hardware lifecycle | You | Provider | Provider |
| Power, network and cooling | You | Provider | Provider |
What stays with you
AWS puts it plainly: RDS hosts the software components and infrastructure, and you are responsible for query tuning, because performance depends on database design, data size, data distribution, workload and query patterns. In practice you still own:
- Schema and queries. Table design, indexes, and how the application uses transactions.
- Access control. Database users and roles, network rules, and whether the database is reachable from the internet.
- Configuration choices. Instance size, storage type, backup retention, maintenance windows and whether to pay for a standby.
- Cost. Nobody else will notice an oversized instance or a forgotten test database.
- Data portability. Regular logical exports so you can move if you need to.
Managed vs self-managed vs serverless
There are three common ways to run a database in the cloud, and they differ mainly in how much control you keep and how you are billed.
| Self-managed on a VM | Managed (provisioned) | Serverless | |
|---|---|---|---|
| You choose | VM size, OS, engine version, every setting | Engine, version from a supported list, instance class, storage | Engine and a capacity range or limits |
| Billing | VM hours plus disks | Instance hours plus storage, backups and options | Compute used (per second or per request) plus storage |
| Idle cost | Full VM cost | Full instance cost while running | Low; compute can pause on many services |
| Operational work | All of it | Mostly configuration and monitoring | Least; capacity is adjusted for you |
| Main trade-off | Control vs effort | Convenience vs fewer low-level options | Resume delay after idle periods; usage-based bills are harder to predict |
When self-managed still makes sense
Running your own database on a virtual machine is reasonable when you need something the managed service does not offer: an extension or engine version outside the supported list, operating-system access, a custom storage layout, or a licence arrangement that only works on your own VM. Some managed services narrow this gap; Microsoft describes Azure Database for PostgreSQL as giving granular control and flexibility over database management functions and configuration settings. The cost of self-managing is time: backups, patching, monitoring and failover become your team's job.
When serverless is the better form of managed
Serverless databases are managed databases with a different billing and scaling model. They suit development databases and workloads with long idle periods, where paying for an always-on instance wastes money. See serverless databases explained for how they work and when the resume delay matters.
How managed database costs work
Managed relational databases are usually billed per instance hour, with several other items added. When you compare providers, line these up rather than the headline instance price:
- Compute. The instance class (vCPUs and memory), billed per hour or per second while it runs. Burstable classes are cheaper but share CPU.
- Storage. Provisioned storage per GB-month, and on some services extra charges for IOPS or throughput above a baseline.
- Backups. Often free up to a set amount (for example, Azure Database for PostgreSQL includes backup storage up to 100% of provisioned server storage), then charged per GB-month.
- High availability. A standby in another zone adds a second set of compute charges, and often storage charges, for capacity that only serves traffic after a failover.
- Data transfer. Traffic leaving the provider's network, and sometimes between regions or zones.
- Licences. Commercial engines such as SQL Server and Oracle add licence cost on top of the infrastructure.
Some services stop compute billing when you stop the database; Microsoft states that compute billing stops immediately when you stop an Azure Database for PostgreSQL server, while storage is still charged. For dated list prices and worked examples across AWS, Azure and Google Cloud, see the cloud database pricing comparison.
Managed database services by provider
The table lists the main managed relational services and the engines each provider documents. AWS managed database services and Azure managed database services also include NoSQL options (DynamoDB, Cosmos DB), which are covered on the cloud databases overview.
| Provider | Service | Engines | Notes |
|---|---|---|---|
| AWS | Amazon RDS | PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2 | Also Amazon Aurora (PostgreSQL- and MySQL-compatible) |
| Microsoft Azure | Azure SQL Database; Azure Database for PostgreSQL; Azure Database for MySQL | SQL Server engine (Azure SQL), PostgreSQL, MySQL | Azure SQL Database also has a serverless compute tier |
| Google Cloud | Cloud SQL | MySQL, PostgreSQL, SQL Server | AlloyDB and Spanner for larger or distributed workloads |
| DigitalOcean | Managed Databases | PostgreSQL, MySQL, MongoDB, Kafka, caching | Daily backups with point-in-time recovery included |
| Aiven | Aiven for PostgreSQL, MySQL and others | PostgreSQL, MySQL, Valkey, Kafka and more | Runs on several clouds; all-inclusive hourly plans |
Choosing between them
Start with the engine your application uses, then prefer the provider where the application already runs. For a feature-level comparison of the three hyperscalers, read AWS RDS vs Azure SQL Database, AWS RDS vs Google Cloud SQL and Azure SQL vs Google Cloud SQL. Within AWS, Amazon RDS vs Amazon Aurora explains the two managed relational families. If you are weighing a specialist platform, see best database hosting providers.
When a managed database is not the right choice
- You need an unsupported engine, version or extension. Check the provider's supported list before you design around a feature.
- You need operating-system or superuser access. Managed services restrict both.
- The database is tiny and idle most of the time. A serverless option or a free tier may cost far less than an always-on instance.
- Strict data residency or on-premises requirements. If the data cannot leave your own facilities, a public cloud service is ruled out regardless of how it is managed.
Frequently asked questions
What is a managed database service?
It is a database that a provider runs for you: the provider handles servers, operating system, database installation, patching, backups and failover, and you connect to it like any other database. Amazon RDS, Azure SQL Database and Google Cloud SQL are examples.
What does fully managed database mean?
It means the provider handles the infrastructure and the database software lifecycle (installation, upgrades, patching, backups, monitoring). It does not cover your schema, queries or access configuration, which remain your responsibility.
What are the AWS managed database services?
For relational databases, Amazon RDS (PostgreSQL, MySQL, MariaDB, SQL Server, Oracle and Db2) and Amazon Aurora. For NoSQL, Amazon DynamoDB. For analytics, Amazon Redshift.
What are the Azure managed database services?
Azure SQL Database (and Azure SQL Managed Instance) for the SQL Server engine, Azure Database for PostgreSQL, Azure Database for MySQL, and Azure Cosmos DB for NoSQL.
Is a managed database more expensive than running my own?
On infrastructure alone it usually is, because you pay for the operational automation. Whether it costs more overall depends on how much time your team would otherwise spend on backups, patching, monitoring and failover.
Can I still tune a managed database?
Yes. You can change most engine parameters through the provider's parameter settings, add indexes and rewrite queries. Low-level operating system and storage tuning is not available.
Sources
- AWS docs: What is Amazon RDS?
- Amazon RDS product page
- Microsoft Learn: What is Azure SQL Database?
- Microsoft Learn: Azure Database for PostgreSQL overview
- Azure Database for PostgreSQL pricing
- Google Cloud: Cloud SQL overview
- DigitalOcean docs: Managed Databases
- DigitalOcean Managed Databases pricing
- Aiven docs: Service pricing and free tier
Checked 8 October 2026.
How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.