DBaaS, database as a service, means renting a running database instead of installing and operating one. You ask a provider for "PostgreSQL, 4 CPUs, 100 GB, highly available" through a console or an API, and a few minutes later you get a hostname and credentials. The provider owns the servers, the operating system, installation, patching, backups, replication and failover. You own the schema, the queries, the data and the bill.
Amazon RDS, Azure SQL Database, Google Cloud SQL and MongoDB Atlas are all DBaaS. So is a self-service database platform your own company runs internally on Kubernetes or OpenStack.
Who does what
The split of responsibilities is the whole point, and misunderstanding it causes most DBaaS incidents.
| Task | Self-managed on a VM | DBaaS |
|---|---|---|
| Hardware, OS install and OS patching | You | Provider |
| Database install and minor-version patching | You | Provider, in a maintenance window you choose |
| Backups and point-in-time recovery | You build it | Provider runs it; you set retention and test restores |
| Replication and automatic failover | You build it | A setting, at extra cost |
| Monitoring infrastructure | You build it | Built-in metrics and query insights |
| Major-version upgrades | You | You start it; provider automates the mechanics |
| Schema design, indexes, query tuning | You | You |
| Users, roles, network access rules | You | You |
Protecting against DROP TABLE and bad deployments | You | You |
| Capacity planning and cost control | You | You |
A managed service does not tune your queries, and it will not notice that you left the database open to the internet.
The kinds of service you will meet
Managed instances of an open-source or commercial engine. Amazon RDS, Google Cloud SQL, Azure Database for PostgreSQL or MySQL, and Azure SQL Database (the SQL Server engine) run a standard engine at a size you choose. Behaviour matches the upstream database closely, which keeps you portable.
Cloud-native engines with a compatible interface. Amazon Aurora, Google AlloyDB and the Hyperscale tier of Azure SQL Database keep the PostgreSQL, MySQL or SQL Server wire protocol and SQL dialect but replace the storage layer. You gain faster failover and storage that grows on its own; you accept differences from the upstream engine.
Vendor-operated services. The company behind the database runs it for you on the cloud of your choice: MongoDB Atlas, Redis Cloud, CockroachDB Cloud, Snowflake and many others. Third parties such as Aiven do the same for open-source engines.
Serverless databases. Capacity scales with load and can drop to zero when idle, and you are billed for usage, not for a fixed instance. Amazon DynamoDB on-demand, Aurora Serverless and Neon are examples. They suit spiky and development workloads. The first connection after an idle period can be slow while the database resumes.
Private DBaaS. The same self-service model on infrastructure you control. The usual building blocks are Kubernetes operators (CloudNativePG and the Percona and Crunchy operators for PostgreSQL, among others) and OpenStack Trove, which is still an active OpenStack project. Tesora, the company once best known for a commercial Trove distribution, was acquired by Stratoscale in 2017.
What you give up
You do not get the operating system, and you do not get a true superuser. The practical effects on a managed PostgreSQL service:
- No
SUPERUSER. You receive an administrative role with most privileges (rds_superuseron Amazon RDS,cloudsqlsuperuseron Cloud SQL,azure_pg_adminon Azure). Scripts that assume a real superuser fail. - Extensions come from an allow-list. If the extension you rely on is not offered, you cannot install it.
- No server file system.
COPY ... FROM '/path/file.csv'reads a file on the server, which you cannot reach. Use\copyinpsql, which streams the file from your machine, or the provider's import feature. - Configuration through the provider. There is no
postgresql.confto edit. You change settings in a parameter group or the console, only those the provider exposes, and some need a restart. - Versions on the provider's schedule. New major versions arrive after the community release, and old ones are retired. When a version reaches end of support you are either upgraded automatically or, on some services, moved to paid extended support.
Check these on day one, before you commit:
SELECT version();
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb
FROM pg_roles
WHERE rolname = current_user;
SELECT name, default_version
FROM pg_available_extensions
ORDER BY name;
SHOW max_connections;
The first tells you the exact engine version, the second what your admin role really is, the third which extensions you may enable, and the fourth how many connections the instance size allows.
Connecting safely
A DBaaS endpoint is a network service, so two settings matter more than they do on a private server.
Keep it off the public internet where you can: use private networking (a VPC or private endpoint) and allow only your application's addresses. And verify the server's certificate, not just encrypt the connection:
psql "host=mydb.example-provider.com port=5432 dbname=app user=app_user sslmode=verify-full sslrootcert=/etc/ssl/provider-ca.pem"
sslmode=require encrypts but does not check who you are talking to. verify-full also checks the certificate chain and the hostname. Download the CA bundle from your provider's documentation.
What it really costs
The hourly instance price is the headline. The bill has more lines:
- Storage, per GB-month, and on some services provisioned IOPS separately.
- High availability. A standby in a second zone roughly doubles the instance cost.
- Read replicas, each billed as another instance.
- Backup storage beyond the included allowance, and long-term snapshots.
- Data transfer out of the cloud or between regions.
- Extended support fees if you stay on a retired engine version.
- Licences, for commercial engines such as SQL Server and Oracle, unless you bring your own.
For a small or variable workload DBaaS is almost always cheaper than the engineering time it replaces. For a large, steady workload, compare against reserved or committed-use pricing and against running it yourself; the answer is not always the managed service.
Things that catch people out
- Deleting the instance can delete its backups. Automated backups usually belong to the instance. Take a final snapshot, or enable backup retention after deletion, before removing anything. Turn on deletion protection for production.
- A backup you have not restored is a hope, not a backup. Run a restore to a new instance and time it. That number is your real recovery time.
- Provider backups are not an exit plan. Snapshots restore only inside the same service. Keep a periodic logical export (
pg_dump,mysqldump,mongodump) if you ever want to leave or need a copy elsewhere. - Connection limits are tied to instance size. Serverless functions and autoscaled application servers can exhaust them quickly. Put a pooler in front: PgBouncer, or the provider's proxy.
- Failover drops connections. High availability means the database comes back within seconds to minutes, not that your sessions survive. Applications need reconnect and retry logic, and must not cache the resolved IP address of the endpoint.
- Maintenance windows cause restarts. Set the window to a quiet period instead of leaving the default.
- Latency. Put the database in the same region as the application. A cross-region round trip on every query will dominate response times.
- Compatible is not identical. A service that is "PostgreSQL-compatible" or "MongoDB-compatible" can differ in supported features and versions. Test your own queries and drivers against it.
When DBaaS is the wrong choice
- You need an extension, plugin, engine patch or OS-level setting the provider does not offer.
- Data must stay in a location or network no provider serves, such as an air-gapped site. A private DBaaS can still apply.
- The workload is large and steady enough that provider margins outweigh your staffing cost, and you already have the people to run it.
- You need replication topologies or upgrade timing fully under your control.
A short evaluation checklist
- Is the engine the real upstream database or a compatible one? Which exact versions?
- Are the extensions and features you use available?
- What are the backup retention limits, and how long does a restore take at your data size?
- What happens during failover and maintenance, and how long does each take?
- How do you get all your data out, in a standard format, and what does that transfer cost?
- What is the total monthly cost with high availability, backups and expected traffic included?
Further reading
Get the weekly commit
New database deep dives every week.
