You are not likely to benefit from a Microservices architecture if all the services share the same database tables. This is because you are effectively tightly coupling the services. If a database table changes all the services will have to change.
You have to understand that the whole reason for a Microservices architecture is to reduce dependencies between development teams and allow them to move ahead independently with fast releases.
Here is a quote from Werner Vogels, the Amazon CTO (Amazon pioneered a lot of the Microservices style architecture):
For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.
For more information read this and this.
An update in 2021:
Some commenters pointed out that sharing a physical DB may be ok, for example by using separate tables or schemas for different services in the same DB. This is of course possible and still a useful separation of concerns for the service development. It is an architectural (and also organizational-) decision if you want the service teams being responsible for the whole service stack and deployment, including infrastructure, or if you want to separate that out into an infrastructure- or devops-team. Each approach can have its pros and cons depending on your organizational circumstances, scale, requirements, etc.
Another aspect is that newer, scalable DB technologies are becoming more popular. They generally abstract storage and compute for separate scalability and are used as a service (for example Snowflake, Teradata, BigQuery, etc.). They allow growing to very large sizes with millions of tables and petabytes of content using a single cluster. With those it would be the goal to have the microservice implementation teams not worry about the details of running a DB infrastructure, but just use the DB cluster endpoint as a service dependency. And it would be the normal case to have many services depend on that same DB cluster. However you would still want to pay attention to storage separation, e.g. separate logical tables, collections, or whatever makes sense in the specific DB technology.
This answer is patently false. You can still benefit immensely from using micro-services even if they share the same database. And no, the whole purpose of micro-services wasn't to reduce what you described. That is but one of many reasons. My company converted a monolithic application into 5 microservices and it dramatically improved both our workflow and the performance of the application....but it uses a monolithic database.
@gshauger: Glad to hear you could benefit from your refactoring. It sounds like you used this to more correctly componentize your application. And your application is probably running at a different scale in terms of complexity, staff size and horizontal scaling requirements than the scenarios that the Microservices architectural style was invented for (Amazon, Netflix, Google with 100s of services etc). Smaller scenarios are of course much easier to handle with the additional dependencies from sharing a DB. I recommend you read up on SOA (which existed before the Microservices term).
I'm fully familiar with SOA. I'm also familiar with the fact that the initial proposal for microservices didn't care about the size of a company and it made no mention of a shared database. In terms of "loose coupling" it merely suggested that you select things "depending on what fits best". You seem to have a very narrow definition of a microservice.
I agree with @gshauger. In some cases you can achieve a service's data privacy by implementing a private-table or private-schema per service in a single database. Of course, in some cases it could also be that some service must have its own db due to throughput requirements. But i don't think it is a MUST to have a db per server...
@jim : I don't disagree. And I don't exclude that in my answer. Another point is considering new DB technologies that abstract storage from compute. With those it is even less important and many services may use the same logical and/or physical DB as a service. You still want a separation of scope though, and you propose to do it through separate tables or schemas, which may work fine. Depending on the DB technology there may be other ways to cut out your service scope and avoid overlaps. And nothing is to be taken religiously. With good reasons you may deviate of course.