Dentolize · Regional DB Split Walkthrough
On this pageThe pitch, in one paragraphObjections this addressesWhat NOT to promiseCompetitive angle

For Sales

The pitch, in one paragraph

If a prospect (especially in Saudi Arabia, or any market with data-residency requirements) asks "where does my clinic's data live," this PR is the answer becoming true: Dentolize is moving from one shared global database to dedicated regional databases, so a Saudi clinic's patient and financial records can be hosted in a Saudi-serving region rather than commingled with clinics on the other side of the world. That's a real architectural change, not a policy promise.

Objections this addresses

  • "Is our data isolated from other countries' clinics?" Yes, architecturally, once a clinic is on the new regional architecture — the regional databases are physically and logically separate; a regional server can only read the small shared global catalog, and can never write to it. See Global vs. Regional Split.
  • "What happens to our data during a migration to a new region?" There's a purpose-built, auditable migration tool for exactly this (see Moving a Company Between Regions) — it requires an explicit dry run before any real move, refuses to run while the clinic has in-flight work (an open import, a pending payment, an e-invoice mid-submission), and keeps the old copy as a disabled backup until an operator explicitly deletes it. This is not a manual, ad hoc data-copy process.
  • "Will this cause downtime or disruption for our current setup?" Not for existing customers on this branch alone — the split runs alongside the existing system, and cutover follows a detailed, phased runbook (scripts/GO_LIVE_RUNBOOK.md) with a defined maintenance window and an explicit rollback plan.

What NOT to promise

  • Don't commit to specific go-live dates for any particular region — those aren't set in this PR.
  • Don't describe this as already live — it's unreleased. Frame it as "in development" or "part of our regional infrastructure roadmap," never "available now."
  • Don't claim performance or scale improvements — this work's stated goal is data residency and isolation, not speed. If a prospect asks about performance, redirect to product/engineering rather than improvising a number.
  • Don't over-promise on which regions exist — as of this PR, the only concrete regions referenced in configuration/docs are EU-1 and ME-1 (Saudi Arabia). Anything else is speculative.

Competitive angle

Most competitors in this space run a single shared multi-tenant database regardless of customer geography. Being able to say "your data is hosted in a dedicated regional database, not a global multi-tenant one" is a differentiator worth having in the back pocket for enterprise or compliance-sensitive prospects — once it's actually live for their region.