Shared Database vs Database per Service: Data Ownership in Microservices
Overview A shared database lets multiple services read and write the same tables through one common schema, while database per service gives each service its own private data store that only it can touch directly. The choice determines how tightly services are coupled at the data layer, how independently teams can deploy, and how much work cross-service queries and transactions require. Comparison Diagram Shared DatabaseDatabase per ServiceService AService BService CShared DBone schema, every service reads/writes it directlyService XService YService ZDB XDB YDB Zeach service owns a private schema, accessed only via its API Comparison Table Aspect Shared Database Database per Service Data ownership No single owner — all services see and can modify the same tables Each service exclusively owns its schema; no one else can touch it directly Access path Services query the database directly, often with raw SQL against shared tables Other services only get data through the owning service’s API or published events Cross-service transactions Native ACID transactions and joins span all the data in one commit No shared transaction; consistency across services needs sagas or eventual consistency Cross-service queries Simple SQL joins pull data from any table in one query Requires API composition, data replication, or a separate CQRS read model Schema changes A column or table change can silently break unrelated services Schema changes are internal; only the public API contract must stay stable Technology choice All services are locked into one database engine and schema Each service can pick the storage engine that fits its data (polyglot persistence) Failure isolation A database outage or lock contention affects every service at once An outage in one service’s database doesn’t directly take down the others Operational overhead One database to provision, back up, and tune N databases to provision, monitor, back up, and scale independently Key Differences Shared database gives every service direct access to the same tables, so a change in one place can silently break another service’s queries — a form of tight coupling. Database per service forces all cross-service data access through an API, giving each service true encapsulation of its data. Cross-entity consistency is a native ACID transaction in a shared database, but needs a saga pattern or eventual consistency once data is split per service. Reporting and ad-hoc joins are trivial with a shared database’s SQL, while database per service usually needs a separate CQRS read model to answer cross-service queries. Database per service allows polyglot persistence — each service picks its own database engine — whereas shared database locks every service to one engine and schema. When to Use Each Shared Database ...