In-your-account deployments vs SaaS control planes: who really owns your data?
TL;DR: a SaaS control plane is simpler to buy and harder to leave. An in-your-account deployment is more work to set up and keeps ownership of the infrastructure, the data, and the exit with you. Neither is universally correct. The mistake is comparing their monthly prices without noticing they are not the same purchase.
Two providers can both call themselves a managed database service, quote a similar monthly figure, and commit to a similar SLA, while running architectures that differ on every question a CTO, CFO, or CISO will eventually have to answer. The difference is where the database physically runs and whose account it runs in.
One model puts the database on the vendor's infrastructure, behind the vendor's control plane. The other puts it inside your own cloud account and sends the vendor in to operate it. Everything else follows from that choice: where the data sits, who holds the keys, how the bill is assembled, what an auditor can be shown, and what leaving costs.
The two architectures
SaaS control plane. The provider runs the database on infrastructure it owns and controls. You get an endpoint, a console, and a bill. The provider handles provisioning, patching, scaling, and backup because it has to: you have no access to the underlying machines. Every hyperscaler DBaaS and every independent database-as-a-service platform works this way.
In-your-account deployment. The database runs in your AWS, Azure, Google Cloud, or Akamai Cloud account, on infrastructure you own and pay for directly. The provider is granted scoped access and operates the environment inside your boundary. You receive a cloud bill from your cloud provider and an operations fee from the operator. This is often labeled BYOC, bring your own cloud.
Everything below is a consequence of that single structural difference.
1. Where the data lives, and who can prove it
With a control plane, your production data sits in the vendor's account, in a region the vendor supports, under access controls the vendor administers. You are given an attestation that this is handled correctly. For most workloads that attestation is enough.
It stops being sufficient at three moments:
- when a regulator asks where a specific data set resides,
- when a customer contract commits you to a residency guarantee you now have to inherit from a supplier,
- when an auditor asks you to evidence a control rather than to point at somebody else's certificate.
With an in-your-account deployment, those questions are answered from your own console. The evidence is generated by infrastructure you own. That does not make compliance automatic. It makes the evidence yours to produce rather than yours to request.
2. Who holds the keys and the IAM policies
This is the question most buyers skip and most CISOs return to.
In a control plane model, encryption keys and identity policies are administered by the vendor, sometimes with a bring-your-own-key option layered on top. In an in-your-account model, the keys and the IAM policies are yours by default, and the provider operates under permissions you granted and can revoke without a support ticket.
The practical test is simple, and it is worth asking any provider before signing: if we terminated this agreement at 9 a.m. tomorrow, what exactly do we revoke, and how long until you no longer have access to production? A provider operating inside your account answers with a role name. A provider operating a control plane answers with a process.
3. How the bill is assembled
Control plane pricing bundles compute, storage, backup, data transfer, and operations into one usage-based meter. That is genuinely convenient, and it is also why database bills grow in ways nobody can explain in a quarterly review. Independent breakdowns of DBaaS pricing consistently identify data transfer and egress, not compute, as the most common cause of unexpected cost, with analyst write-ups documenting instances where transfer charges exceeded the compute line for the same cluster, and cost comparisons across MySQL, PostgreSQL, and MongoDB showing the same pattern.
In-your-account deployments split the bill in two: infrastructure billed to you by your cloud provider at your negotiated rates, and a separate operations fee. That split has three consequences
- Your existing cloud commitments, reserved capacity, and enterprise discounts apply to the database, because it is your account.
- Cost optimization work produces savings that land on your bill, not the vendor's margin, which changes what the vendor is incentivized to recommend.
- The operations fee stops moving when your traffic moves, which is what "predictable" should mean and rarely does.
The cost of the two models can still land in the same place. What differs is whether you can see which part is infrastructure and which part is service. For the fuller cost breakdown, see the hidden costs of DBaaS.
4. What leaving looks like
Every managed database relationship ends eventually, through acquisition, consolidation, or dissatisfaction. The architecture determines whether that ending is a project or a change of supplier.
Leaving a control plane means extracting production data across the vendor's network, at the vendor's egress rates, into infrastructure you now have to stand up. The egress charge is levied at exactly the moment you have the least leverage. Leaving an in-your-account deployment means revoking access. The database does not move, because it was never anywhere else. You need a new operator, which is a procurement problem, not a migration project.
This is the mechanism behind most database lock-in, and it is architectural rather than contractual. We covered it in full in vendor lock-in in managed databases.
The honest case against in-your-account
A comparison that only lists advantages is marketing. Three real costs come with keeping the database in your own account.
You keep the account, so you keep responsibility for it.
Cloud account hygiene, network design, quota management, and the security posture of the surrounding environment remain yours. A control plane genuinely removes that work.
Setup takes longer.
A control plane gives you an endpoint in minutes. An in-your-account deployment requires account structure, network paths, permission scoping, and an operating agreement before anything runs. That is days of work, front-loaded, before the first byte lands.
You have to grant a third party access to production.
That is a real risk decision and it deserves a real review: scoped roles, audited sessions, and revocation you control. Anyone who tells you it is nothing has not run the review.
If your database is small, stable, and not subject to residency or audit obligations, a control plane is very likely the correct purchase, and no argument in this article should talk you out of it.
What to ask any provider before signing
- In whose cloud account does the production database run, and whose name is on the infrastructure invoice?
- Who administers the encryption keys, and can we rotate them without your involvement?
- If we terminate, what do we revoke, and how long until your access to production ends?
- What is the total data volume we would have to move to leave, and what does egress cost at today's rates?
- Which layer do you actually operate: infrastructure only, the engine, or the workload including index and query tuning?
- When an auditor asks for evidence of a control, do we produce it or do you?
Question five separates providers more than any other. There are three layers, most contracts cover one or two, and almost none of them say which. For the longer version, see 25 questions to ask before signing a managed database contract.
How Maxima Consulting runs it
Maxima Consulting is a managed cloud operator and engineering partner that runs SRE, and Day-2 operations for software vendors and enterprises. Managed databases are deployed inside the client's own AWS, Azure, Google Cloud, or Akamai Cloud account rather or on our control plane, depending on the case.
That covers the relational and distributed spread, from PostgreSQL and MySQL to Apache Cassandra, operated as SRE rather than as a ticket queue, so repeat failures are treated as defects to remove. Where the surrounding platform needs the same treatment, Cloud Orbit provides the open-source tooling layer that keeps the environment portable.
The reason we operate this way is not a philosophy. It is that the exit door stays open, which means the engagement has to keep being worth renewing.
If you want to know which model your current setup actually is, schedule a discovery session. Thirty minutes, no obligation, and if a control plane is the right answer for your workload we will say so.
FAQ
What does BYOC mean for a managed database?
BYOC stands for bring your own cloud. The database runs inside your own cloud account on infrastructure you own and pay for, while an external provider is granted scoped access to operate it. You keep the data, the encryption keys, and the identity policies. The provider supplies the engineering: provisioning, tuning, patching, backup execution, restore rehearsal, and incident response.
Is an in-your-account deployment less secure than a SaaS control plane?
It is a different risk shape rather than a worse one. A control plane concentrates risk in a vendor you cannot inspect. An in-your-account deployment concentrates risk in the access you grant and the account hygiene you maintain. The second is auditable by you, which is why regulated buyers tend to prefer it, but only if the access review is done properly.
Can we move from a SaaS control plane to our own account?
Yes, and the technique is well established for the relational engines. PostgreSQL and MySQL both support near-zero-downtime cutovers using logical or binlog replication, so the cutover window is usually minutes. The dominant cost is data egress from the incumbent, which should be calculated before the project is approved rather than discovered during it.
Who pays the cloud bill in an in-your-account model?
You do, directly to your cloud provider, at whatever rates and commitments you have already negotiated. The operator charges a separate fee for the engineering. This is the main reason the two models are hard to compare on headline price: one number bundles infrastructure and service, the other separates them.
Does the provider need permanent access to production?
It should not be unconditional. Access should be scoped to named roles, logged per session, time-bound where the work allows it, and revocable by you without a support request. Ask for the role definitions during evaluation, not after signature.
