Microservices with shared database? using multiple ORM's?

I'm learning about microservices and I'm gonna build a project with a microservices architecture.

The thing is, one of my team mates want to use one database for all services, sharing all tables so "data doesn't get repeated", each service would be built with different frameworks and languages like django and rails which use very different ORM standards.

What would be the correct approach? Since I think working with one database would involve a lot of "hacking" the ORMs in order to make them work correctly.

You are not likely to benefit from a Microservices architecture if all the services share the same database tables. This is because you are effectively tightly coupling the services. If a database table changes all the services will have to change.

You have to understand that the whole reason for a Microservices architecture is to reduce dependencies between development teams and allow them to move ahead independently with fast releases.

Here is a quote from Werner Vogels, the Amazon CTO (Amazon pioneered a lot of the Microservices style architecture):

> For us service orientation means encapsulating the data with the > business logic that operates on the data, with the only access through > a published service interface. No direct database access is allowed > from outside the service, and there’s no data sharing among the > services.

For more information read this and this.

An update in 2021:

Some commenters pointed out that sharing a physical DB may be ok, for example by using separate tables or schemas for different services in the same DB. This is of course possible and still a useful separation of concerns for the service development. It is an architectural (and also organizational-) decision if you want the service teams being responsible for the whole service stack and deployment, including infrastructure, or if you want to separate that out into an infrastructure- or devops-team. Each approach can have its pros and cons depending on your organizational circumstances, scale, requirements, etc.

Another aspect is that newer, scalable DB technologies are becoming more popular. They generally abstract storage and compute for separate scalability and are used as a service (for example Snowflake, Teradata, BigQuery, etc.). They allow growing to very large sizes with millions of tables and petabytes of content using a single cluster. With those it would be the goal to have the microservice implementation teams not worry about the details of running a DB infrastructure, but just use the DB cluster endpoint as a service dependency. And it would be the normal case to have many services depend on that same DB cluster. However you would still want to pay attention to storage separation, e.g. separate logical tables, collections, or whatever makes sense in the specific DB technology.

In general a microservice should be responsible for it's own data. That's a perfect world scenario.

In practice some of the services may be highly related to each other. E.g. CustomerShippingDetails and CustomerShoppingCheckout services may both access the same data - customer address. How would you then solve a problem of providing customer address to the customer checkout service. If the checkout service queries the shopping details directly then you break loose coupling between services. Other option is to introduce a shared database.

There will always have to be some kind of compromise on the architecture. What is sacreficed is an architectural decision that highly depends on the big picture (the design of the whole system).

Not having too many details about your system I would go with a mixed approach. That is, having a shared database for services that take care of similar business logic. So CustomerShippingDetails and CustomerShoppingCheckout can share a database. But a StoreItemsDetails would have a separate database.

You can find more about shared database pattern for microservices at Microservice Architecture.