This isn’t really a SQL Persistence question, it’s an architecture/microservices question. SQL Persistence is just an implementation detail.
As far as SQL Persistence is concerned, all endpoints will make their own tables for stuff, which DBAs can put on different drives or mess around with if need be even if they’re in the same DB. The important part is business data.
If you need to access a business data table from Endpoint A and you ALSO need to access it from Endpoint B, then those endpoints better be on the same database or you’ll start to get into cross-database transactions. This is where proper service boundaries really come into play, because an endpoint != a service/microservice.
If you really want to have microservices, then separated databases are crucial, because otherwise you’re just reintroducing coupling at the database level. But you can’t do that without proper service boundaries.
I recommend you watch the following 2 talks by my awesome coworkers @adamralph and @mauroservienti, to find out more about how to figure out your service boundaries, and how to deal with UI/ViewModel aspects in a microservices system without reintroducing coupling by doing request/response between the services.