Database per service vs shared database — which approach did you use?

The "Database per service" approach assumes that each microservice has its own database. This provides data isolation, independence in development and deployment of services, and also reduces the risk of conflicts and data consistency issues. However, it complicates the implementation of cross-service transactions and requires additional mechanisms for data synchronization.

The "shared database" approach means that several services use a common database. This simplifies data exchange and transactions but reduces service isolation, increases coupling, and can lead to scalability and schema management issues.

In practice, "database per service" is more commonly used in microservice architecture to ensure independence and scalability. For example, in Golang services, each service can use its own database (PostgreSQL, MongoDB, etc.) and interact via API rather than directly through a shared database.