Direct naar content

A closer look at DBaaS

There is a growing interest in Database-as-a-Service (DBaaS). At the same time we only seem to be at the forefront with regard to quality and possibilities. Countless variations are now available from different cloud providers.

Databases can be deployed in the cloud with seeming simplicity. If you believe the marketing stories, you no longer need a database administrator. Developers with ready-to-use building blocks – containers – can get started right away. But did they really take a good look at DBaaS?

Edco Wallet

Co-Founder & eigenaar
Edco Wallet - Co-Founder & eigenaar

Speed and modern development methods

Since the emergence of DevOps and CI/CD methods of developing and deploying, there have been lots of opportunities for developers. Speed of development has become key. Therefore the need has grown to make progress independently of others. Today’s development teams can pick ready-to-use building blocks and APIs from the internet. Setting up an application or even an environment or platform from scratch is no longer necessary.


We see a clear trend that suppliers and providers try to make everything as easy as possible. The easiest and fastest way to deploy software in the cloud using your own API. You could say that (Public) DBaaS has won as the way to deploy databases in the cloud. Peter Zaitsev of Percona recently dedicated a keynote to it during the Percona Live Online 2020 event.

Popular Public DBaaS models

The most well-known and used public DBaaS models are:

  • Amazon RDS
  • Azure database for (PostgreSQL, MySQL, MariaDB)
  • Azure SQL
  • Google Cloud SQL
  • IBM Cloud Databases

And then there are a number of cloud-native DBaaS models such as:

  • CockroachDB
  • MongoDB Atlas
  • Amazon Aurora
  • Google Cloud Spanner and Bigtable
  • TimeScaleDB

In the GigaOm radar for Cloud databases (the full report can be downloaded here) the following overview is published.

GiGaOm radar report Cloud databases

Possibilities and advantages DBaaS

DBaaS has its advantages. Security, Patching, High Availability (HA) adjustment and management, making backups, performance tuning, it’s all taken care of. You don’t need a DBA anymore to help you or give you permission to get rid of a database. The developer can choose exactly that database which he thinks is best suited for the application. Then he trust the cloud provider to keep it up and running and to ensure everything keeps performing well.

Big differences

The differences are large and diverse. There are differences in optimization for memory I/O, or performance and scalability of storage. In some cases even a fork of open-source software is created to achieve better performance at the expense of core features (such as Aurora from AWS). In addition, cloud-native solutions and DBaaS models are derived from existing on-prem applications.


On our website we have published a DBaaS overview of the most commonly used models and their strengths and challenges. This website of Trustradius gives a nice overview with details, comparisons and also reviews. The basic configurations are generally good for most database instances. This allows developers and engineers to get the most out of the service without being a complete DBA or Database Expert.

But then the downside

In practice, developers, without supervision or advice from a DBA or Database Expert, deploy all kinds of databases. The result is a confusing jumble of databases and connections. In this way some objections arise.

Disappointing results from practice

Percona recently published a study on the use and application of databases. In practice, 69% of the companies surveyed now use a certain form of DBaaS solution. 22% of this group indicated that the cost of these managed database services in the cloud is much more expensive than previously estimated. Furthermore, no less than 74% cite performance issues as the main (already experienced) problem at the moment and 45% cited the unpredictability of downtime as an issue.


In practice, as the platform and database grow in size, more and more storage space is simply added. If database performance deteriorates as a result of the growing use of the application, people just simply add CPUs or some extra memory. But everything has its price. DBaaS is designed to facilitate just this and the revenue model is also designed to do that. The monthly invoice will grow along with the database and quality of the application, data model and/or queries. Let alone if we start talking about clusters and redundancy. In that case a number of servers will be added and costs will grow exponentially.

Vendor Lock-in

All cloud providers offer a wide range of services to further enhance the convenience of DBaaS. All providers now offer a more or less compatible open source variant. This makes it look as if you are working with native Postgres or native MySQL. However, the extent to which the purchased database is set up, the API that is used, how it is monitored and how the High Availability is arranged, makes moving to another provider or even to your own (rented) server very difficult and very expensive. This is called Vendor Lock-in.

Shared instances

All DBaaS solutions are designed for the common divisor, the large average. Customization is almost impossible. Of course with some puzzling and cloud rocket science and making miraculous combinations there can be some performance gain. But basically, the chosen DBaaS will not be adapted to specific wishes. In addition, and that is what the DBaaS revenue model is set up for, they are huge shared instances. This makes the performance of your databases partly dependent on the use of this shared space by other customers. In short: we are all on the same boat, someone jumps up and down and you get seasick.

DBA expertise

Last but not least, in the end almost all DBaaS solutions lack DBA expertise. Such as the use of indexes, a targeted data model, smart clustering and serious database maintenance. Imagine a kitchen after leaving your toddler unattended for a few hours…

In short

DBaaS can still be a good option in experimental and analytical environments. Or in small and fast development teams where a database is needed ‘just for the moment’. But if you are considering putting databases structurally in the cloud and setting them up as a DBaaS solution? Then make a good consideration and don’t forget to hire a DBA as a database expert, supervisor and trusted advisor. Not only from a financial perspective but also to ensure the best performance possible.

Need help or advice

OptimaData has already helped several customers with, but also out of, a DBaaS situation. We know better than anyone the intricacies of databases. We always know how to find the best options and optimal setup. From experience, because we do it every day. Would you like to discuss ideas? Feel free to contact us, no strings attached.


CockroachDB/GigaOm radar report