Glad you like the analogy. It's not perfect, but neither are microservices. I think it fits, and it helps to explain to dev teams the challenges of database development and coordinating their efforts.
I think there are problem domains where this works. Using separate data stores allows for scalability and it can work well when the data is disparate.
Where I think this fails is that in a lot of common applications, we want to use this data together. We need to relate customer data with shipping data, or something else. If we do this as singletons, i.e., I look up my order(s), this can work well with separate data stores. If I need to do this at any scale, like all orders for a store or a region, the microservices traffic can be problematic. It's also highly inefficient. It's row-by-row work.
What many places need that use microservices with separate data stores is strong ETL work to get the data from these stores into a warehouse of some sort. Spotify does this. Their data moves quickly into warehouses, because the problem domain supports microservices for the most part (we all listen individually in our accounts), but for lots of the add-ons, the mixes, the reporting, they need to have a way to consolidate data.
It's not good or bad, but something you need to consider.