# Shared Database

> Multiple services share one DB — easy joins, tight coupling. An anti-pattern at scale.

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

---

## Description
Clean, reusable architecture pattern.


## Use Cases
Legacy system has 5 "microservices" all hitting the same MySQL schema. Order table is referenced by 4 services. Changing a column requires coordinating all 4 teams. This is the shared database anti-pattern in the wild.





## Trade-offs


### Advantages

- Simple to implement initially

- Easy cross-service JOINs — data consistency is trivial

- ACID transactions across all services

- No need for Saga or eventual consistency patterns




### Considerations & Drawbacks

- Schema changes require coordinating all services simultaneously

- One service can degrade DB performance for all others

- Tight coupling — services can't be deployed independently if schema changes

- Prevents polyglot persistence — all services locked to same DB tech

- Kills true microservice independence







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