Customer-Managed Data Stores (Bring-Your-Own-Database)

In the ordinary shape of a hosted software product, the vendor runs everything: the application and the database that stores the customer's data both live inside the vendor's own environment, and the customer just uses the product. A customer-managed data store — often called bring-your-own-database (BYODB) — inverts one half of that. The customer provisions and operates the database themselves, inside their environment (their own cloud account, network, or data center), and the vendor's application reaches into it over a connection the customer grants. The vendor still builds and runs the product; it just no longer holds the data at rest.

The single thing that flips is ownership of the data plane — the part of the system where the customer's actual records live. Everything else about the product can stay the same, but that one move ripples into security, operations, and how you ship changes. A customer chooses this because data governance matters more to them than convenience: the data never leaves a boundary they control.

Read the two halves side by side: the only wire that crosses a boundary is the connection from the vendor's app into a database the customer stands up and operates. That single crossing is where all the interesting design lives — the rest of this day walks it, and the next day debates whether it's worth it.

The pattern only makes sense once you separate two responsibilities that a fully-hosted product usually blurs together. The control plane is the part that decides what should happen: the application logic, the orchestration, the schema definitions, the migration tooling, the product features. The data plane is the part that holds and serves the data: the database itself, its storage, its backups, its uptime. In BYODB, the vendor keeps the control plane and the customer takes the data plane.

This split is the same idea that separates a "brain" from a "warehouse." The brain (control plane) knows the shape the data should take and the operations to run; the warehouse (data plane) is where the goods physically sit. You can move the warehouse to someone else's property as long as the brain still has a key to the loading dock and an agreed floor plan.

Naming the two planes precisely matters because every hard question in this pattern is really "which plane owns this?" Who runs backups — data plane (customer). Who defines the tables — control plane (vendor). Who decides the database version — data plane, within a range the control plane supports. Keeping the line sharp is what stops the two sides from each assuming the other has it covered.

Because the database now sits inside the customer's environment, the vendor's application has to cross a trust boundary to reach it — a security perimeter the customer owns and the vendor does not. Three things have to be arranged across that boundary, and each is a place where the vendor's reach is deliberately limited rather than total.

First, connectivity: there must be a network path from the vendor's app to the customer's database, and the customer decides its shape. The safest common arrangement is a private connection that never traverses the public internet, with the customer allow-listing exactly the vendor's origin and nothing else — or, better still, an arrangement where the connection is initiated from inside the customer's boundary outward, so the customer never has to open an inbound hole at all. Second, credentials: the customer creates the database login the vendor uses and grants it the least privilege that still lets the product work — rights to the specific tables it needs, and no standing ability to read or alter anything else. Third, keys: the data is encrypted at rest with keys the customer holds, so even the storage layer isn't readable without the customer's cooperation, and encrypted in transit so the crossing itself is private.

The mental test for the boundary is: if the vendor were fully compromised, how much of the customer's data would be exposed? A well-designed BYODB boundary answers "only the specific tables the product uses, and only while the granted connection is live" — because the customer controls the network path, the privileges, and the keys. That limited blast radius is the entire point of the arrangement, and it's what the customer is buying.

Here is the puzzle that makes BYODB genuinely harder than a hosted database: the vendor owns the schema — the definition of the tables, columns, and indexes the product depends on — but the database that schema lives in sits on a box the vendor doesn't host and can't freely touch. When the product needs a new column, someone has to run that change inside the customer's environment, safely, without the vendor logging in by hand.

The standard answer is a migration runner: schema changes are written as ordered, versioned steps checked into the vendor's code, and a small tool applies any not-yet-applied steps to the database using the granted connection. Each customer's database records which version it's at, so the runner only ever applies the gap. Crucially, migrations must be backward and forward compatible for a window — the old app must keep working against the new schema and vice versa — because you can't guarantee the app and the database update in the same instant across every customer.

The discipline that keeps this honest is expand-then-contract: to change a column, first add the new shape and write to both old and new (expand), ship the app that reads the new shape, then remove the old shape in a later migration once nothing reads it (contract). This lets the schema evolve in small, reversible, compatible moves — which is the only kind of schema change that's safe when you can't see the box, can't take it down for maintenance, and can't assume every customer upgrades at the same time.

Standing up a customer-managed store is a handshake, not a button. Because the customer owns the database, onboarding is a defined sequence in which the customer does their part inside their boundary and the vendor validates that everything lines up before the product goes live. Getting this lifecycle right is what turns a fragile bespoke setup into a repeatable one.

The sequence is roughly: the customer provisions a database that meets the vendor's stated requirements (a supported version, enough capacity); the customer grants the least-privilege login and opens the private connection; the vendor validates — it connects, confirms the database version is within the supported range, and runs the migrations to bring the schema to the version the app expects; and only then does the product go live against that store. From then on, the connection is health-checked continuously so that a network change or a rotated credential on the customer's side surfaces as a clear, early alert rather than a mysterious outage.

The step people underestimate is version validation. Because the customer chose and operates the database, they might run a version older or newer than the vendor tested against — so the vendor must publish a supported version range and check it at onboarding and on every upgrade, refusing to proceed on an unsupported version rather than discovering the incompatibility as corrupt data later. A crisp compatibility contract, checked automatically, is what keeps a fleet of independently-operated databases from drifting into chaos.

The subtlest consequence of BYODB is that operational duties that were entirely the vendor's now split between the two parties — and unless that split is written down explicitly, both sides assume the other owns the gap. This is a shared-responsibility model, the same idea cloud providers use to draw the line between what they secure and what the customer secures, applied here to who keeps the database healthy.

The clean division follows the plane it lives in. The customer (data plane) owns the database's uptime, capacity, backups, high availability, patching, and the version it runs — because it's their box in their environment. The vendor (control plane) owns the schema, the migrations, the application's correct use of the database, and the product behavior on top. Some duties are genuinely shared: performance, for instance, depends on both the vendor's queries and the customer's hardware and tuning, so diagnosing a slow product requires both sides.

Rule of thumb: write the responsibility split down as an explicit contract before the first customer goes live, and make performance and incident-diagnosis explicitly shared rather than leaving them in the gap — because the failures that hurt most in this pattern are the ones where each side assumed the other was watching.

• A customer-managed data store (BYODB) keeps the vendor's application but moves the database into the customer's own environment, so the customer owns the data at rest and its operation while the vendor connects in over a granted link.
• The pattern works by splitting the control plane (vendor: app logic, schema, migrations) from the data plane (customer: the database, its uptime, backups, and keys); every hard question reduces to "which plane owns this?"
• The vendor crosses a customer-owned trust boundary with deliberately limited reach: a private, customer-allow-listed network path, a least-privilege login, and encryption with customer-held keys — so a vendor compromise exposes only the tables the product uses.
• The vendor owns the schema but can't host the box, so schema changes ship as versioned migrations applied by a runner, kept backward/forward compatible via expand-then-contract because the app and database can't update in the same instant everywhere.
• Onboarding is a handshake lifecycle: customer provisions and grants access, vendor validates the version is in a supported range and runs migrations, then the product goes live behind continuous health checks.
• Operations become a shared-responsibility model: the customer owns uptime/backups/version/keys, the vendor owns schema/migrations/app correctness, and performance and incident diagnosis are explicitly shared — write the split down or both sides will assume the other has the gap.

• [ ] I can explain what customer-managed / BYODB flips relative to a fully-hosted product, and why a customer would want it.
• [ ] I can define control plane vs data plane and assign backups, schema, version, and keys to the correct plane.
• [ ] I can describe the three things arranged across the trust boundary — connectivity, credentials, keys — and how each limits the vendor's reach.
• [ ] I can explain how versioned migrations apply schema changes to a database the vendor doesn't host, and why expand-then-contract is required.
• [ ] I can lay out the provisioning lifecycle and explain why version validation against a supported range is the step not to skip.
• [ ] I can fill in a shared-responsibility table and name the duties that are genuinely shared rather than owned by one side.