IMHO, the primary principle of microservices is that they should be independently deployable. That is I can make a change to a single service, and deploy that into production consistently, without having to change anything else.
When multiple services share the same data (Which is they read & write to the same schema), you have introduced a coupling point that makes independent deployability a real headache. Although this form of database integration is common, it is one of the biggest problems with 'traditional' SOA, and I strongly advocate against using this approach.
Jose's question raises an interesting point, IMO. OK, using same database introduce coupling, but would not be enough to separate each service using same database instance and keep data separated by assigning to each microservice a specific schema?
Hi Claude, that is OK in my book. Obviously you have a potential single point of failure in the DB instance itself, but if each schema for each service is isolated from each other, you do get the de-coupling we're looking for! Just make sure people aren't doing sneaky cross-schema magic :-)