Should I use a single MySQL database (as in schema) for microservices?

Question

I'm developing a microservice system, and I was wondering whether or not all services should share the same database under a single MySQL instance. I can't think of any meaningful disadvantages of doing so, and it would make backups simpler while also allowing foreign keys between services, making things easier. What's the norm here, should each service have its own database, or share a single database?

Answer 1

The key driving forces for implementing microservices are:

1. De-coupling the development and release processes of the distinct major components of the overall system.
2. De-coupling scaling and deployment choices of the major components.

In my opinion, if maintaining your two microservices on a common database is a reasonable choice, you should consider the question of whether you would be better off combining some of your microservices back into a larger unit (not necessarily a monolith). This is because, even though microservices have advantages, they also have costs. By combining microservices, you can make efficiency gains:

1. In schema management (e.g. you don't have to worry any more about schema skew between two microservices)
2. In release artifact management, release processes, reduction in combinatorial effects. No need to release two things, no need to test (or even consider) an exponential number of component combinations.
3. (Probably but not certainly) reduced number of ways that things can go wrong when performing a production rollback.

To phrase my point a different way, if you don't already have forces that clearly motivate you to have separate databases, perhaps the key criteria that would have motivated refactoring a monolith into those microservices are missing.