A general microservice definition is that each service "owns" its data/schema. If one makes a change to the underlying data/schema, only the micro-service that owns that data should be affected. Having the data in a separate instance or a separate server meets this definition.

One could even have just one database with different services updating different parts of the database schema, although there could be a greater temptation to cross data boundaries in that scenario. So, it's better to have some sort of physical or logical separation to avoid that when doing a micro-service approach.

Based on how many users or how the usage traffic pattern is will dictate which arrangement works best. For example, if I have an application with just a few thousand users, one database with multiple instances may suffice. If I have several million users, each service might have its own database that can independently scale up or down based load or usage.

A general microservice definition is that each service "owns" its data/schema. If one makes a change to the underlying data/schema, only the microservice that owns that data should be affected. Having the data in a separate instance or a separate server meets this definition.

One could even have just one database with different services updating different parts of the database schema, although there could be a greater temptation to cross data boundaries in that scenario. So, it's better to have some sort of physical or logical separation to avoid that when doing a micro-service approach.

Based on how many users or how the usage traffic pattern is will dictate which arrangement works best. For example, if I have an application with just a few thousand users, one database with multiple instances may suffice. If I have several million users, each service might have its own database that can independently scale up or down based load or usage.