I’ve been part of a number of “monolith to microservice” transitions and something that I’ve seen a few times is engineering orgs creating separate database servers per-team or even per-service.
Please don’t do this. Please start with a production server, and an “everything else” server, until you outgrow one large server.
Separate servers, as opposed to different databases on the same server, is purely engineering overhead, and comes with no practical advantages. From an application perspective, connection info is just connection info, so it makes no difference where the DBs are hosted.
From an ops/infrastructure perspective, it’s managing
(number of services) * (number of environments) servers, and managing more servers will always be harder than managing fewer (without a PaaS-like investment).
And because it doesn’t matter to the application, adding database servers upfront is over-engineering.
For any benefit you think you’ll get for having a server per-team or per-service, start doing it on one server, and see how useful and productive it is. My experience and guess is, most teams who talk about hypothetical benefits aren’t doing them on the servers they currently have, and better tools are available. In many cases the teams don’t understand the tools that already exist in their database ecosystem of choice.
There are two times you may want to break stuff out early. One would be for a high-use, critical path service, like sessions and auth. The other would be for a constant high-load service, like analytics.
I’d be curious if anyone has an argument or experience that goes against this advice. Most of what I’ve seen runs into fundamental misattribution problems, where the choice is unrelated to the benefits (this is true of most rewrites I’ve been a part of or have heard about). Let me know in the comments!