Shared Database vs Database per Service: Data Ownership in Microservices

Tue, 04 Aug 2026 05:14:24 +0900

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

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

Data-Ownership on IT Comparison

Shared Database vs Database per Service: Data Ownership in Microservices

Overview

Comparison Diagram

Comparison Table

Key Differences

When to Use Each