Microservices are the latest software development craze. All the kids are doing it. When I started hearing about the concept, the first advantage that came to mind was the single responsibility principle. If you take the principle from other aspects of the software engineering principle, it seems to follow than a service - like a class, or library should only do one thing, and do it well. I'll give Microservices that.

However, performance, and scalability were not things that sprang to mind. Without getting in to a huge discussion, there will probably always be cross-talk amongst services which will mean that not only could performance degrade because servers are weighed down with load, but network latency can and probably will degrade performance.

Then, someone told me that they had broken their service up in to 20+ Microservices for the purpose of scalability. This has perplexed me somewhat. I had to probe them by what they meant. Surely, Cloud computing on Azure and so on had solved this problem? When I probed a little further, I was told that a database can not scale up, so no matter how many computers you have in the cluster, the database will always be the bottleneck. The monolith database must be broken down in to smaller chunks for each service. Excuse me? A database can not scale up? Have Microsoft, Amazon, and Google just been lying about their scaling database platforms?

Azure Cosmos

Cloud SQL

Amazon Relational Database Service

Literally, that's my question. Have Microsoft, Amazon, and Google just been lying about their scaling database platforms? Don't they work? I mean, if these platforms do scale up in the sense that more resources are added with replication and so on, then why would breaking a monolith database up in to smaller chunks make it perform better?

Have you tried out these platforms? Are you running very large databases with lots of tables, rows, columns with thousands of transactions per second? What's the consensus on this? Is there some reason that using these scalable database platforms is not as good as breaking the databases down in to smaller chunks?

For the purpose of this question, assume that sharding can not be used as the primary scaling technique. The database must scale with millions of rows, lots of columns and tables.

PS: This isn't a question of whether or not Microservices are a good idea. The question is very simple. Can a database scale up?

  • 1
    Possible duplicate of How to scale horizontally a microservice that holds a database
    – Doc Brown
    Mar 2, 2019 at 9:38
  • 1
    ,,, and don't get me wrong, but on this site, questions have a way better chance to survive when written in a focussed manner. The community here usually does not need to know the whole discussion going back and forth in ones head to understand what they are asking.
    – Doc Brown
    Mar 2, 2019 at 9:44
  • It's a simple question. Does database scaling work? It's not about how to scale microservices. Mar 2, 2019 at 9:45
  • Exactly my point - the whole discussion about what you think about Microservices in the first half of your question makes it hard to understand what you really want to know. And the top answer to that other question holds already a simple answer: learn about sharding
    – Doc Brown
    Mar 2, 2019 at 9:48
  • I can delete the background about microservices if that helps. I'm not interested in sharding. My whole question is about whether or not a single , large database can scale up. Obviously, that's going to involve replication etc. and the question was about whether or not people had actually managed to get it working. Mar 2, 2019 at 10:20

1 Answer 1


Of course you can scale databases.

Also, with a strict interpretation of monolith and microservice there generally shouldnt be this kind of performance scaling advantage to microservices. A monolith can be just all the microservices in one big package.

It sounds to me like this person is using the term 'monolith' to imply a solution which is very tied to the database and probably has business logic in sprocs, views, triggers etc

When they say 'microservice' they really mean their new solution which has broken those ties.

Although a db can be scalled, its expensive and harder to do than scalling a well programmed microservice. You can simply deploy more of them on cheap boxes behind a load balancer.

When people run into scalling problems 90% of the time its because of the way they interact with large, centralised databases which have reached the limits they were initially expected to consume.

If you can take chunks of your monolith out of that pattern, move them away from the db and implement them is a way designed to scale. Then "moving to microservices has helped us scale" is true. Even though in theory you could have refactored the entire monolith for the same result.

  • Out of curiosity, why is it more expensive to scale up? I thought the point of these scaling databases were that you only pay for what you use... Mar 2, 2019 at 18:38
  • I think you've answered my question more or less. But can you provide any studies or empirical evidence to show that scalable databases are a proven technology? I believe you're right but how can others be convinced? Mar 2, 2019 at 18:44
  • these kinds of databases are intrisincally resource intensive. plus they a central point that all the apps use. They need the most cpu power, storage, fail over, etc etc. You can run most microservices on hardware less powerful than a calculator. Any processes that can be taken out of the db means the db has more resource available for returning and storing data
    – Ewan
    Mar 2, 2019 at 18:52
  • Why are they intrinsically resource intensive? Because of replication? Mar 2, 2019 at 18:54
  • because of the volume of data they have to store
    – Ewan
    Mar 2, 2019 at 18:54

Not the answer you're looking for? Browse other questions tagged or ask your own question.