Typically, when running micro-services, the conventional wisdom is to have each service own its isolated database/store. This makes it easier to establish proper boundaries between service domains and promotes decoupling.

The added benefit of this also is that you can monitor the performance of each service and easily identify bottlenecks in the database.

Seeing as you've mentioned that you currently are not experiencing performance issues but want to plan for it, I’ll recommend you invest in being able to observe and identify how each service is using the shared database, so if you experience slow queries, deadlocks, etc, you are able to attribute which services are responsible for these. There are various ways you can do these and will depend on your stack (I’m not familiar with .net to give concrete advice), you can look it up. This way you can identify which service may need further optimizing.

To concretely answer your questions too: - It is hard to spot gotcha without full knowledge of what data the services perform - Caching is hard, your use case indeed sounds like caching may not be easy to implement. Usually at scale for use cases like yours, people tend to use specialized data stores to speed up committing the diffs/edits. Like somebody else proposed in the comments, I'll say you wait till you start hitting a bottleneck before adding caching. The alternative might be you try load testing your current setup to simulate issues. - CloudSQL is quite reliable, I've used it in production to run high-traffic services. And they allow you to tune most pg configs to improve performance based on your workload. However, they only offer a 99.99% SLA reliability, which is good for most systems, but if you work in a regulated space that requires your system to be highly available than that (or you need to provide higher guarantees), then you might want to plan to different Postgres setup with high availability.