Should Each Microservice Have Its Own Database?

Ideally, each microservice should own its own data. This principle is commonly called Database per Service or, more precisely, data ownership per service.

For example:

Product Service
      ↓
Product Database

Order Service
      ↓
Order Database

Payment Service
      ↓
Payment Database

The important rule is:

A microservice should be the only service responsible for directly reading/writing its owned data. Other services should access that data through its API or events.

1. Why Does Each Microservice Own Its Data?

The main purpose is to maintain loose coupling and service independence.

Suppose the Order Service owns the Order database:

Order Service
     ↓
Order DB

Payment Service should not do this:

Payment Service
      ↓
Order DB
      ↓
UPDATE Orders ...

Now Payment Service knows the internal database structure of Order Service.

If the Order team changes:

Orders table
     ↓
OrderHeaders table

Payment Service could break.

Instead:

Payment Service
      ↓
Order API / Event
      ↓
Order Service
      ↓
Order DB

The Order Service remains responsible for its own data.

2. Can Multiple Microservices Share the Same Database?

Technically: Yes.

Architecturally: Directly sharing the same tables/data is generally discouraged.

For example:

Product Service ──┐
                  │
Order Service ────┼──→ ECommerceDB
                  │
Payment Service ──┘

This is technically possible.

However, if all services directly read and modify the same tables, the services become tightly coupled through the database.

This can reduce many benefits of microservices.

3. What Problems Does a Shared Database Cause?

Tight Coupling

Suppose:

Order Service
      ↓
Orders Table
      ↑
Payment Service

Both services depend on the same database schema.

Changing the schema can affect multiple services.

Independent Deployment Becomes Harder

Suppose Order Service changes:

Orders

to:

OrderHeaders

Now you may need to update:

Order Service
Payment Service
Reporting Service

at the same time.

The services are no longer truly independent.

Unclear Data Ownership

If multiple services can update the same table:

Order Service ─────┐
Payment Service ───┼──→ Orders
Shipping Service ──┘

Who actually owns Orders?

This makes business rules and responsibilities unclear.

Technology Independence Is Reduced

With independent data ownership:

Product Service → SQL Server

Search Service  → Elasticsearch

Cache           → Redis

Each service can select storage appropriate to its requirements.

A shared database can restrict that flexibility.

4. Does Database per Service Mean Separate SQL Servers?

No. This is an important interview point.

You don't necessarily need:

Product Service
      ↓
SQL Server 1

Order Service
      ↓
SQL Server 2

Payment Service
      ↓
SQL Server 3

That can be expensive and unnecessary.

You could use the same physical SQL Server while maintaining separate logical databases:

             SQL Server
                 |
       ┌─────────┼─────────┐
       ↓         ↓         ↓
 ProductDB    OrderDB   PaymentDB
    ↑            ↑         ↑
 Product       Order     Payment
 Service       Service    Service

This still gives clear logical ownership.

5. Can We Even Use the Same Physical Database?

Yes.

For example, one SQL Server instance could contain:

SQL Server
│
├── ProductDB
├── OrderDB
├── PaymentDB
└── InventoryDB

Each microservice uses only its database:

Product Service   → ProductDB
Order Service     → OrderDB
Payment Service   → PaymentDB
Inventory Service → InventoryDB

This is very different from all services freely sharing the same tables.

6. Another Option: Separate Schemas

Sometimes organizations initially use one physical database with separate schemas:

ECommerceDB
│
├── Product.Products
├── Product.Categories
│
├── Ordering.Orders
├── Ordering.OrderItems
│
├── Payment.Payments
└── Payment.Refunds

Then:

Product Service → Product schema
Order Service   → Ordering schema
Payment Service → Payment schema

This can provide logical separation, although separate databases generally provide stronger isolation.

The key requirement remains:

One service owns a particular set of data. Other services should not directly modify it.

7. How Does One Service Get Another Service's Data?

This is where many developers initially find database-per-service difficult.

Suppose Order Service needs Product information.

Don't do:

Order Service
      ↓
SELECT * FROM ProductDB.Products

Instead, there are several approaches.

Synchronous API

Order Service
      ↓
GET /api/products/100
      ↓
Product Service
      ↓
Product DB

Asynchronous Events

Product Service can publish:

ProductCreated
ProductPriceChanged
ProductDiscontinued

Other services consume the events and maintain the data they require.

Product Service
      ↓
ProductPriceChanged
      ↓
Message Broker
      ↓
Order Service

The correct approach depends on consistency and business requirements.

8. What About JOIN Between Databases?

In a monolith, we might easily write:

SELECT *
FROM Orders o
JOIN Products p
    ON o.ProductId = p.Id;

In proper microservice boundaries, cross-service database joins are generally avoided.

Instead, data can be combined through:

API Composition
Event-driven local read models
CQRS
Reporting/Data warehouse

This is one of the trade-offs of microservices.

9. Advantages of Database per Service

• Loose coupling
• Clear data ownership
• Independent deployment
• Independent schema changes
• Better fault isolation
• Independent scaling
• Technology flexibility
• Better bounded-context separation

10. Disadvantages

Database per service also creates challenges:

• Cross-service queries become difficult.
• Distributed transactions are harder.
• Data duplication may be required.
• Eventual consistency may be required.
• Reporting across services becomes more complex.
• Data synchronization becomes important.
• More databases need to be managed.

This is why patterns such as Saga, Outbox, CQRS and Event-Driven Architecture are common in larger microservice systems.

11. Key Points

• Each microservice should ideally own its data.
• Database per service does not mean one physical database server per service.
• Multiple services can technically use the same database server.
• Avoid multiple services directly modifying the same tables.
• Shared tables create tight coupling.
• Other services should access owned data through APIs or events.
• One SQL Server can host multiple service-specific databases.
• Separate schemas can provide logical separation, but require strict ownership.
• Cross-service database joins should generally be avoided.
• Database-per-service improves independence but makes distributed data management more complex.

Interview Questions & Answers

Q1. Should every microservice have its own database?

Ideally, every microservice should own its data. This provides loose coupling, clear ownership and independent evolution.

Q2. Can multiple microservices share the same database?

Technically yes, but allowing multiple services to directly access and modify the same tables is generally discouraged because it creates tight coupling.

Q3. Does database per service mean separate database servers?

No. Multiple service-specific databases can exist on the same physical database server.

SQL Server
 ├── ProductDB  → Product Service
 ├── OrderDB    → Order Service
 └── PaymentDB  → Payment Service

Q4. Can two services read the same table?

Technically yes, but it creates schema coupling. Prefer having one service own the table and expose required information through an API, event, or purpose-built read model.

Q5. How does one microservice access another service's data?

Normally through:

• REST/gRPC APIs
• Events/messages
• API composition
• Replicated/read models where appropriate

rather than directly querying another service's database.

Q6. What is the biggest disadvantage of database per service?

Managing cross-service queries, transactions and data consistency becomes more complex.

Interview One-Line Answer

Each microservice should ideally own its data. Multiple microservices may use the same physical database server, but they should avoid directly sharing and modifying the same tables because that creates tight coupling and reduces service independence.