Isolated datastores is really the thing that differentiates microservice architecture (datastores meant in the most broad sense possible - queues, caches, RDBMSs, nosql catalogs, S3 buckets, whatever).
If you share a datastore across multiple services, you have a service-oriented architecture, but it is not a microservice architecture.
Note that I'm saying this without any judgement as to the validity of either architectural choice, just making a definitional point. A non-microservice architecture might be valid for your usecase, but there is no such thing as 'microservices with a shared database'.
It's like, if you're making a cupcake recipe, saying 'but does each cake actually need its own tin? I was planning on just putting all the batter in one large caketin'.
It's fine, that's a perfectly valid way to make a cake, but... you're not making cupcakes any more.
If you share a datastore across multiple services, you have a service-oriented architecture, but it is not a microservice architecture.
Note that I'm saying this without any judgement as to the validity of either architectural choice, just making a definitional point. A non-microservice architecture might be valid for your usecase, but there is no such thing as 'microservices with a shared database'.
It's like, if you're making a cupcake recipe, saying 'but does each cake actually need its own tin? I was planning on just putting all the batter in one large caketin'.
It's fine, that's a perfectly valid way to make a cake, but... you're not making cupcakes any more.