Is modularizing data storage a good idea?

[breun]

I'm investigating Spring Modulith and so far I think it's a great fit for our needs. I've been wondering how to deal with data storage in a modulith and I'm looking for best practices, recommendations and potential pitfalls.

If each Modulith module would have its own database, that would automatically enforce a proper boundary between the database tables owned by the different modules, and would be the easiest when the time comes to move a module out of a modulith for any reason, so that feels like The Best Solution when it comes to modularity guarantees. It wouldn't even be possible for module A to mess with data owned by module B directly without going through the proper public API provided by module B! But, I also foresee quite a bit of complexity with dealing with separate databases per module. How would you set this up? Would each module have its own configuration code and properties for a DataSource bean with a @Qualifier annotation or something? And then next to those also a database for the application as a whole, for instance for the application-wide Spring Boot event registry?

The other end of the spectrum would be having a single database, a single database user and thus a single DataSource for everything in a modulith, which would allow any module to do anything with any data owned by any module. You could say that developers just shouldn't violate module boundaries by accessing data that does not belong to a module, but it would be very nice to have this enforced.

I guess there are also some options in between these two extremes, like using a schema per module and having a database user per module/schema? What are best practices, recommendations and pitfalls when it comes to dealing with data in a modulith? What are you doing, and why?