# Database per Service

> Each service owns its data — no shared databases, no schema coupling.

- **Category**: Microservices
- **Subcategory**: Data Management
- **Canonical URL**: https://designpattern.fyi/patterns/database_per_service/

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Order Service uses Postgres, Product Service uses MongoDB, Search Service uses Elasticsearch. Each team deploys schema changes independently. No coordinated migrations across services.





## Trade-offs


### Advantages

- True loose coupling — services can change their schema freely

- DB tech can be chosen per use case (polyglot persistence)

- Failure isolation — one DB going down doesn't cascade

- Independent scaling per service's data access pattern




### Considerations & Drawbacks

- Cross-service queries require API Composition or CQRS

- Distributed transactions need Saga pattern (no ACID across services)

- Data duplication between services is unavoidable

- Harder to maintain global data consistency







---
**Reference**: [Original Source](https://microservices.io/patterns/data/database-per-service.html)