A short field note from recent work.
A decision guide for founders, not a package tutorial: cost, migration pain, and the GDPR/data-residency questions Nordic and EU enterprise buyers actually ask in procurement. Advocates the hybrid path โ shared schema for MVP, promoting enterprise tenants to dedicated databases โ with the trigger points for switching.
The short version
The honest answer depends on your context โ team size, existing stack, and how much of the problem is really technology versus process. But the pattern I see repeatedly: start from the business constraint, not the tool. If you are researching single database vs database per tenant, the framing below is the one I use with my own clients.
How I approach it
- Name the constraint first โ cost, speed, compliance, or maintainability โ and let it drive the architecture.
- Prefer boring, proven building blocks; spend novelty budget only where it buys a real advantage.
- Measure before and after. If a change cannot show up in a number, it is a matter of taste, not engineering.
You can see how this philosophy plays out across my technology stack.
A full write-up of this topic is in progress โ this is the working summary. Weighing your options here? Let's talk.