- SaaS
- Systems Modernization
- Discovery Workshop
- Cybersecurity
One database per customer, and twenty customers
Giving each customer their own database is a reasonable decision at three customers and an operational problem at twenty. Moving to a hybrid model keeps isolation where it is genuinely required and stops every new deal from adding infrastructure.
Representative engagement. This describes a pattern we build rather than one named client: the situation that produces it, how we approach it, and the range of outcomes that kind of work lands in. Figures are stated as ranges or targets, never as a measured result for a specific customer. Our named client work is on the work index.
- Industry
- SaaS
- pooled by default, dedicated where contracts require it
- Hybrid
- one release for every customer, not one per customer
- 1 deployment
The problem
A dedicated stack per customer is simple until it is twenty of them. A migration has to run twenty times, a bug has to be verified twenty times, and a customer on an older version is a version somebody has to remember exists. Cost scales with customer count rather than with usage, so the smallest account costs roughly what the largest does. That relationship gets worse with every deal, which is an unusual thing for growth to do. The reason it was built this way is real and should not be dismissed. Some customers genuinely require dedicated infrastructure and will say so in procurement, so the answer is not simply to pool everything.
What we built
A hybrid model. Pooled infrastructure by default, with isolation enforced in the data layer rather than in application code somebody has to remember to write, and dedicated deployment available as a tier for the customers who contractually require it. Isolation is enforced at the database rather than by convention, so a missing filter in a query fails closed instead of leaking. That is the property that makes pooling safe, and it is the part worth spending time on. Migration runs one customer at a time, smallest first, with the old stack live until the new one is verified against real traffic. Nobody moves on a date; they move when their own verification passes.
What changed
Infrastructure cost decouples from customer count, which is the change that makes the smaller accounts profitable and the pricing model coherent. Operationally, one deployment replaces twenty. A fix ships once and reaches everybody, and the concept of a customer being on an old version disappears, which was quietly costing more than the servers were.
Built with
- Go
- PostgreSQL
- Terraform
- Kubernetes
- AWS