As I described in the question, if I were to implement a microservices architecture, would the centralized read/write database become a bottleneck?
To expand with an example, let's say I have three microservices: users, teams, and team_members. Each has its own microservice, but they all rely on each other in the database, so exclusive, parallel databases wouldn't be appropriate. Since microservices is meant to distribute the work to several different servers, doesn't the central database ultimately defeat the purpose of these microservices, as they all end up calling to the same server?
...if I were to implement a microservices architecture, would the centralized read/write database become a bottleneck?
There is a assumption built-in to your question. The assumption is that the microservices must share the same master tables in the database.
In fact, further down your question you give voice to this concept directly:
...but they all rely on each other in the database, so exclusive, parallel databases wouldn't be appropriate.
If the microservices are sharing database tables then all you have effectively done is built one single "service" with multiple components which all happen to consume each other over some out-of-band transport rather than in-memory by direct binary reference.
One of the most important concepts behind service orientation is autonomy, which basically means each service should own its own data.
Extending your example, the users service will know about teams. How will it know? Well, the teams service will push team data to users service. Similarly, the team_members service will receive data from both services. Now, all services have all the data they need to do their jobs.
So by implementing your services as autonomous the potential for contention on the same set of base tables dissapears.