Database SaaS (DBaaS): What You Are Paying For, What You Give Up, and How to Size One

A database SaaS, usually written DBaaS, is a database engine run for you by a provider: you get a hostname, a port and credentials, and the provider owns the server, the patches, the backups, the disk and the monitoring. You are paying for the absence of a job, not for the software, which is why the price makes sense to people who have done that job and looks steep to people who have not yet.

The definitions in the search results are accurate and useless: cloud, managed, on demand. What they skip is the trade underneath, which is that you are swapping control for someone else’s on-call rota, and the questions that decide whether that trade is a good one for your application.

Table of contents

• What DBaaS means in practice
• What you are actually paying for
• What you give up
• The questions that separate a good one from a bad one
• Sizing it
• Where it fits next to the application
• How this fits the rest of the stack
• FAQ

What DBaaS means in practice

Strip the acronym and it is this. You choose an engine, MySQL or Postgres most often, and a size. A few minutes later there is a running instance with a connection string. Behind it, the provider has installed the engine, configured it sensibly for the size, set up automated backups, put it on a network, and pointed monitoring at it. Version upgrades, security patches and disk expansion happen without you.

What you do not get is a server. There is no SSH, no filesystem, no ability to install a random extension or change every parameter. The instance is a database, not a machine that happens to run one, and most of what follows comes from that distinction.

The other name for the same thing is a managed database. The SaaS framing is more honest about the billing: it is a monthly subscription for a running thing, priced by size.

What you are actually paying for

The software is free. The engines that matter are open source and you can run them on any server for the cost of the server. So the DBaaS premium over a plain server is buying something else, and it is worth naming precisely.

• Backups that exist, run on schedule, and can be restored from a button rather than a runbook.
• Patching, including the security releases that arrive at inconvenient times.
• Disk that does not fill up at 3am, or that at least pages someone who is not you.
• Version upgrades planned by someone who has done them before.
• Monitoring and metrics, connection counts, slow query visibility, without installing an agent.
• User management, connection limits and network isolation configured correctly from the start rather than after the incident.

Every item on that list is a thing a competent engineer can do. The premium is that they no longer have to, every week, for as long as the application exists. A form without storage is a demo; a database without backups is a demo that has not failed yet.

What you give up

The trade is real, and the list of what you lose should be read before signing up, not after the first surprise.

• Superuser. You get an admin role with most privileges, not the OS-level user. Some operations are simply unavailable.
• Extensions and plugins beyond the provider’s approved list. If your application depends on an unusual one, check before you migrate.
• Filesystem access. No reading the data directory, no custom log shipping from the box, no tuning at the OS layer.
• Some tuning knobs. Providers expose the parameters that are safe at the plan size and hide the ones that are not.
• Sometimes, network placement. The instance lives where the provider puts it, which matters if the application is somewhere else.

Migration out is the one people worry about most and the one that is least of a problem. A managed MySQL or Postgres is still MySQL or Postgres. A dump and a restore moves it to any other host of the same engine. The lock-in is in the operational conveniences you got used to, not in the data.

The questions that separate a good one from a bad one

Two DBaaS offerings at the same price can be very different products. Six questions find the difference.

1. What is the backup schedule, how long is retention, and can I restore one myself without a ticket?
2. Is there a private network between the database and my application, or is the only route a public hostname with a firewall rule?
3. What is the connection limit on this plan, and is it written down? An application with a connection pool per process will hit it faster than you expect.
4. What does moving up a plan involve: a resize in place, or a new instance and a migration?
5. Can I see logs and metrics without asking?
6. How do I export everything, and is the answer a standard dump?

The second and third questions are the ones most often unanswered on the pricing page and most often the cause of the first production incident.

Sizing it

Memory is the number. A database is fast when the working set, the rows and indexes it touches regularly, fits in memory, and slow when it does not. CPU matters for heavy queries and connection counts, and storage grows predictably, but the plan decision is almost always about memory.

The rough ladder: a development database or a small side project fits in a few hundred megabytes. A small production application with a few tens of thousands of rows in its hot tables is comfortable at one gigabyte. Two gigabytes covers a surprising amount of real business software. Beyond that, measure, because the cost of guessing goes up with the plan.

On RunxBuild a managed MySQL or Postgres sits on the general plan ladder: the $4 Dev plan with 624MB for development, the $13 BasicMini with a full vCPU and 1GB for a small production app, the $20 BasicPlus with 2GB, and up from there, with backups, user management, a documented connection limit per plan and private networking to the services beside it. Moving up is a plan change, not a migration, which is the fourth question above answered in advance.

Where it fits next to the application

The database and the application talk on every request, so where they sit relative to each other decides latency and, often, the bill. A database in one provider and an application in another means every query crosses the public internet, and outbound bandwidth from at least one side is metered. Keep them on the same platform and the same private network, and the query path is short, free and not exposed to the internet at all.

This is the argument for choosing the database and the application platform together rather than separately. The database SaaS that is cheapest on its own pricing page is frequently not the cheapest once the application’s bandwidth bill and the extra ten milliseconds on every query are counted.

How this fits the rest of the stack

The database is one line on the bill, and the application, the storage and the bandwidth between them are the others. The RunxBuild hosting calculator shows all of them together, so a managed database is priced as part of the stack it serves rather than as a standalone subscription you compare in isolation.

Useful related references:

• SaaS Meaning: The Definition and What It Implies Technically
• SaaS Company: What One Actually Runs Under the Hood
• SaaS Full Form: Software as a Service, and the Two Layers Beneath It
• Databases on RunxBuild

FAQ

What is database as a service?

A database engine run for you by a provider. You get a hostname, credentials and a size; the provider owns the server, patching, backups, disk, monitoring and upgrades. It is also called a managed database, and the SaaS framing reflects that it is a monthly subscription priced by plan size.

What is the difference between DBaaS and running a database on a server?

The software is the same. The difference is who does the operational work: backups, patching, disk, upgrades and monitoring. On a server you do it. With DBaaS the provider does it, and you give up OS access, some extensions and some tuning parameters in exchange.

Is a managed database worth the cost for a small app?

Usually, because the alternative is not a cheaper database but a cheaper server plus your own time on backups and patches. For a small app the plan is in the four to twenty dollar range per month, and the first restored backup pays for a year of it.

How do I choose the size of a managed database?

By memory. Development databases fit in a few hundred megabytes, a small production app is comfortable at one gigabyte, and two gigabytes covers most small business software. Check the connection limit on the plan as well, since a pooled application can exhaust it before memory becomes the issue.

Can I move away from a database SaaS later?

Yes. A managed MySQL or Postgres is standard MySQL or Postgres, so a dump and restore moves it to any other host running the same engine. What you leave behind is the operational convenience, not the data.