[crmd]

Data separation in enterprise-land means customers don’t want components that touch their data to be shared with any other customers. So a shared but sharded database is no good. In practice you often run a standalone stack for each customer, including their own database. This pattern is a nightmare from an operational scaling perspective, but that’s part of why enterprises are asked to pay so much.

[kgeist]

I understand what it means, I'd like to know where the monolith architecture stands in this context. One of our projects was originally a monolith, and each tenant had their own dedicated DB the monolith connected to. Then they switched to the microservice architecture (back when it was the peak of the hype) and rejected the idea of database sharding because each microservice already requires their own DB, and if you also sharded by tenant, then you'd end up with M x N databases (where M is the number of tenants and N is the number of microservices) which sounds like a lot of complexity to manage. I think they once had a bug where one tenant could see data from another tenant because they don't have strong DB boundaries anymore.