Architecturally speaking, these days “that” is considered a bad idea. In service design this is part of service autonomy - i.e. an application should have full control over it’s own data (with no one else messing about in it) and data owned by other applications needs to be obtained via their service API.
Building Microservices - Chapter 4. Integration
Strong cohesion and loose coupling—with database integration, we lose both things. Database integration makes it easy for services to share data, but does nothing about sharing behavior. Our internal representation is exposed over the wire to our consumers, and it can be very difficult to avoid making breaking changes, which inevitably leads to a fear of any change at all. Avoid at (nearly) all costs.
Now we aren’t talking about services as such - but some of the wisdom is more broadly applicable. Basically by using the database as an integration point you are allowing more than one application to become tightly coupled with the database schema - this also increases the pressure to push more and more business logic into the database via triggers and stored procedures. Ultimately sharing a database is an easy solution that is often synonymous to embarking on the road to an unholy, complected mess.
If more than one application has to have access to the data then it may be time to wrap the persistent storage in a service - which in Elixir could just be another OTP application.
