I don't love the microservices model for lots of database stuff. You lose the power of the database to combine data together. If it is truly separate and isn't aggregated, then fine, but otherwise, many of the big microservices places (like Uber), suck all this data into a DW, often a relational db, to combine and report on data.
That being said, do you need synchronization of the data? Are you assuming your microservices somehow have the data in sync? If you recovered the data for application and documents at different times, is there an issue here?If there is, use 1 db and schemas. If not, separate ones work.
You have to really think about the data model and consistency here. I would look at how the services work if one of the dbs is down. If you're really down, then you aren't really working with microservices per se, you would end up with splitting the app, but unable to us it if something breaks.
From the scalability standpoint, you can get a really large database server to handle a load, so from that standpoint, I might plan for 3 instances, each with their own db. That gives you a future plan. However, if you set up the services well, going from 3 schemas to 3 dbs to 3 instances shouldn't be hard.