What is the Shared Database anti-pattern?
In a shared database, services that are deployed separately still use the same schema and often the same tables. They exchange data by reading what others have written, and they can use joins and transactions across what would otherwise be service boundaries. It is listed here as an anti-pattern because it undoes most of what you split services for.
Why does the Shared Database anti-pattern happen?
It shows up because it is the easiest path: no APIs to design, no events, no eventual consistency. Knowing why it hurts helps you recognise it early, and knowing the way out helps when you have inherited one.
How do you move away from the Shared Database anti-pattern?
- Recognise it: services deploying together for schema changes, or one team's query slowing down another team's service.
- Pick an owner for each table. Make every other service's access to it explicit and visible.
- Replace other services' reads with the owner's API, or with events they keep a local copy of.
- Replace other services' writes with commands or API calls to the owner.
- Move the owner's tables to a separate schema or database once nobody else touches them.
When is it acceptable?
- As a deliberate, temporary step during a migration, with a written plan to end it.
- Several services are really one deployable unit and one team. Then they are one service, so treat them as one.
When should you avoid it?
- Teams need to deploy and change their schemas independently.
- Services have very different load patterns or storage needs.
What do you gain?
- Fast to start
- Joins and ACID transactions across all data
- No eventual consistency to reason about
What does it cost?
- Schema changes need every team's agreement
- One service's load or locks affect all others
- Hidden coupling that makes later separation expensive
What are common mistakes with the Shared Database anti-pattern?
- Treating 'separate schemas on the same server' as solved while services still query each other's schemas.
- Database views shared across services, which are still a shared schema.
- Starting the split without knowing which service owns which table.
Shared Database in practice
Pennant Bank
To launch quickly, the first few services shared one PostgreSQL database. As the team grew, schema migrations needed sign-off from every team and one service's connection spike exhausted the pool for all of them.
The bank moved tables to their owning services one at a time, replacing cross-service joins with API calls and events. Migrations stopped needing cross-team sign-off once each schema had a single owner.
Example decision record
- Context
- Early services share one PostgreSQL database to speed up the initial launch.
- Decision
- Move each table to a single owning service and remove direct access from all others.
- Consequences
- Other services access the data through the owner's API or events.
- Schema migrations become a single team's decision.