Should Every Microservice Have Its Own Database? Pros, Cons, and Real‑World Lessons

Database Isolation in Microservice Architecture

When designing microservices, a key architectural decision is whether each service should own its own database or share a common database and middleware to reduce hardware and maintenance costs. Some argue that logical independence is sufficient and physical separation is unnecessary.

Author stance : every microservice should have an independent database. Whether the database runs on a dedicated server depends on the service’s criticality and business requirements.

Case Study – Online Education Platform

The original system was a monolithic backend with a single large database. As the team grew, the monolith was split into four domain services: student , teacher , admin , and sales . The student service was further divided into three finer‑grained services:

Schedule service (P0 – highest priority, directly affects class attendance)

Points‑mall service (P1 – affects user experience but not revenue)

Activity service (non‑critical, generates promotional events)

All three services continued to use the same student‑side database. During a peak period the database load exceeded 200 % and CPU reached 100 %. Monitoring showed that the activity service generated a massive surge of traffic without proper rate‑limiting, overwhelming the shared database and causing the schedule service to become unavailable.

Mitigation steps:

Temporarily disabled all activity‑service endpoints – schedule service recovered immediately.

Collaborated with the DBA to extract the schedule‑service tables into a new, dedicated database server.

This isolation restored system availability for the critical schedule service.

Benefits of Independent Databases

Availability : Isolating high‑priority services prevents cascading failures when one service overloads the database.

Schema evolution : Only the owning service needs to modify its tables, eliminating coordinated schema changes across multiple services.

Development efficiency : Read/write entry points converge on a single database per service, reducing the need for cross‑service joins. For example, splitting a product table into product and product_detail allows only the product service to change its schema without impacting others.

Risks of a Shared Database

When multiple services share a database, developers are tempted to bypass RPC calls and perform multi‑table joins directly. This creates a “broken‑window” effect that turns a microservice architecture into a distributed monolith. The resulting problems include:

Coordinated schema changes across all write‑entry services.

Difficulty tracing data inconsistencies because many services write to the same tables.

Significant refactoring effort if the architecture needs to be split later.

Practical Guidelines

Assign an independent database to every microservice.

For services with high availability requirements (e.g., P0), deploy the database on a dedicated server to achieve link isolation.

For lower‑priority services (P1‑P2), a shared database server can be used to save hardware costs.

Architectural Example – RPC vs Direct Join

In a typical e‑commerce scenario, the Order service calls the Product service via RPC to obtain product details, then merges the data before returning to the client. If both services share the same database, developers may replace the RPC call with a direct SQL join between order and product tables. This shortcut erodes service boundaries and leads to the “distributed monolith” problem.

Impact on Development Efficiency

Vertical table splitting (e.g., product → product + product_detail) combined with independent databases means only the product service needs to adjust its schema when requirements change. All other services remain unaffected, whereas a shared‑database approach forces every service that queries the product table to modify its code.

Write‑Entry Convergence Issues

When multiple services write to the same table, the following challenges arise:

Adding a non‑null column requires changes in every service that performs writes, increasing the risk of missed updates.

Data corruption in a shared table forces a full audit of all write‑entry services, which is time‑consuming and error‑prone.

If the system has already degenerated into a distributed monolith, refactoring becomes a massive undertaking.

Conclusion

For a true microservice architecture, independent databases per service are essential to ensure reliability, scalability, and maintainable development. Deploying each database on a dedicated server is optional but recommended for services with strict availability requirements.