Since you haven't included a concrete example of a case where an inconsistency could appear, I'll imagine two situations.
First situation
Let's suppose that a service handles employees and another one handles payrolls. If you call the payroll service for a new employee that has yet to be created, you're afraid that the data could become inconsistent: a payroll would be created for a person who doesn't exist yet.
In this case, moving from a monolithic application with a single database to a bunch of services, each owning its data, would not be an issue, because the payroll service could always contact the employees service to ensure that the employee exists. If not, the payroll should not be created.
Of course, you don't have the security mechanism in terms of database constraints. Nevertheless, the similar control can exist at the application level.
Second situation
A service handles payrolls and another one handles insurance information. The payroll service owns a postal address of the person, used to send the payslip. Similarly, the insurance service also has the postal addresses of the employees for its own specific needs. When an address is modified in one of the services, what guarantees that it will also be modified in the other one?
In this case, you'll usually use a third service—such as an employee service—to which two other services will delegate the responsibility of keeping the postal addresses. This way, the information is stored only once, and cannot get inconsistent.
There can be situations which are not that clear. For instance, what if a person is at the same time your employee and your customer? Should you be creating another service to handle the persons in general? Or should you allow some inconsistency (most companies would chose the second solution, which leads to a lot of situations, some funny, some particularly annoying)? There is no right choice for that: it's up to your architect to decide.
Shared database
If you consider those two situations, the shared database brings absolutely no benefit. In both situations, since each of two services is (according to you) not allowed to write to the schema of the other service, there would be no other solutions that to call the other service (first situation) or to have a third service (second situation).
Best Answer
The fact that those different processes use separate connections is (mostly) irrelevant.
The usual concern is that opening and closing a connection is expensive in terms of time and CPU resources. With many databases, this concern is invalid because of connection pooling: there is an overhead the first time you connect to the database, but the next time you need to do a query within the same process, an existent connection is reused under the hood, even if in code, you explicitly closed the connection.
What will happen in your case is that you'll pay the cost of opening twenty connections the first time when twenty microservices start after, for instance, the server reboots. Once this is done, each service will reuse connections already opened before.
What would be a problem is if you have a lot of microservices accessing the database, or if the database, for a given reason, cannot accept too many connections. Since you are talking about twenty microservices, I won't be concerned; for instance, “SQL Server allows a maximum of 32,767 user connections.” (source) If you use a more exotic database or a database which has an exotic configuration or if each service needs, for some reason, to open many connections at once, this could indeed become an issue.