For much of the last decade, “cloud-first” was a policy declaration that meant one thing in practice: move your workloads to a hyperscaler, trust the platform, and optimize later. For many types of workloads, that approach worked out fine. For data, particularly the sensitive, regulated, strategically valuable data that runs the most important parts of most enterprises, the reckoning has arrived.
The regulatory landscape has tightened. The geopolitical environment has introduced new data residency requirements that didn’t exist five years ago. The cost structures of hyperscaler data warehouses have proven less predictable than their proponents promised. And the competitive implications of having your most valuable data assets sitting on infrastructure controlled by someone else are no longer abstract concerns, they’re board-level conversations.
Cloud-first doesn’t have to mean vendor-controlled. In 2026, enterprises have more options than the binary choice between legacy on-premises infrastructure and full public cloud dependency. The question is whether your data infrastructure is positioned to take advantage of them.
The Regulatory Backdrop
The compliance landscape for enterprise data has grown substantially more complex, and the trajectory is toward more requirements, not fewer.
In Europe, GDPR enforcement has matured from a theoretical threat to a practical reality, with meaningful fines and operational restrictions imposed on organizations that can’t demonstrate clear data residency and access controls. The Digital Operational Resilience Act (DORA), which came into full effect for EU financial services firms in early 2025, adds specific requirements around operational resilience and third-party risk that directly affect how organizations can rely on cloud vendors for critical data infrastructure.
In the United States, the picture is more fragmented but equally consequential. HIPAA has always imposed strict requirements on healthcare data. The emerging patchwork of state-level privacy laws — following in the footsteps of California’s CCPA — means that data residency and sovereignty are increasingly live compliance questions for any organization processing consumer data at scale. FedRAMP requirements for government contractors and agencies create a distinct set of constraints around where data can live and who can access it.
Globally, data sovereignty laws — requiring that data generated within a country’s borders be stored and processed within those borders — have proliferated across dozens of jurisdictions. India, Brazil, Saudi Arabia, Indonesia, China, and many others have enacted or are actively developing such requirements. For multinational enterprises, navigating this landscape while maintaining a coherent data architecture is a genuine operational challenge.
The common thread across all of these frameworks is control: the ability to demonstrate, with specificity, where data is stored, who has access to it, how it’s encrypted, and what happens to it under various scenarios including vendor relationships, law enforcement requests, and geopolitical events.
The Problem with Traditional Cloud Warehouses
Here is where traditional cloud data warehouses — the ones where your data lives in the vendor’s infrastructure, under the vendor’s control, subject to the vendor’s terms of service — create a structural compliance problem.
When your data is in Snowflake or Redshift, it is, in a meaningful sense, on Amazon’s or the vendor’s infrastructure. The vendor controls the physical hardware, the hypervisor layer, the network, the backup infrastructure, and significant portions of the software stack. You have contractual protections, but you don’t have operational control. You can’t independently verify where your data is stored at any given moment. You can’t control who within the vendor’s organization has access to your data under what circumstances. You can’t configure your own encryption key management in a way that genuinely prevents vendor access.
For many workloads, this is an acceptable trade-off. For the data that matters most — customer financial records, patient health information, intellectual property, strategic analytics — it increasingly is not.
This isn’t a criticism of cloud vendors. It’s a structural feature of a model where you’re consuming a managed service from a third party. The service is excellent, but control is not part of what you’re buying. If control is what you need, you need a different model.
What Data Sovereignty Actually Requires
Let’s be concrete about what it means to have genuine control over your data in a cloud-era analytics environment.
Physical location control. Your data should reside in specific, known locations that you have chosen — not wherever the vendor’s global infrastructure optimization algorithm has decided is most efficient. For regulated industries and multinational organizations, this means the ability to specify that data stays within a particular country, region, or even a specific data center.
Encryption key ownership. True data sovereignty requires that encryption keys be controlled by you, not the vendor. If the vendor holds the keys, the vendor can — under the right legal or operational circumstances — access your data. This is not hypothetical; it’s exactly the scenario that data residency laws are designed to address.
Access control transparency. You should be able to define and audit exactly who has access to your data, including vendor support personnel. The ability to require that any vendor access to your environment be conducted under your oversight, with a documented audit trail, is a baseline requirement for serious data governance.
Network isolation. Your data should be reachable only through network paths you control. This means deployment within your own VPC or private network, with network policies that you define and manage, not policies that are common across a multi-tenant vendor platform.
Contractual clarity. Your data should not be subject to terms of service that permit the vendor to use it for model training, product improvement, or any other purpose. The vendor should be a processor, not a controller, in GDPR terms — and your contract should make that unambiguous.
The Private Data Cloud Model
The architecture that addresses these requirements is what we call a private data cloud: a deployment model where the data warehouse software runs on infrastructure that you control — whether that’s your own cloud account, your own data center hardware, or both — with all the operational benefits of cloud-native software but none of the data sovereignty trade-offs of a managed service.
In a private data cloud, you provision your own compute and storage. The data warehouse software deploys into your environment, using your network, your encryption keys, your identity provider, and your access controls. The vendor ships software and provides support, but never has standing access to your data or infrastructure. Your data doesn’t leave your environment for any operational purpose — not for backup, not for telemetry, not for optimization.
This model used to require accepting significant operational trade-offs. Legacy on-premises data warehouses were expensive to manage, slow to upgrade, and difficult to scale. The appeal of managed cloud services was precisely that they took operational burden off enterprise teams.
Modern cloud-native architecture changes that calculus. A data warehouse built on Kubernetes, deployed in your own environment, can be as easy to operate as a managed service — because the operational automation that makes managed services convenient is built into the software itself, not into the vendor’s operations team. Upgrades, scaling, failover, monitoring — all of this can be automated within your own environment, with your own tooling, without requiring the vendor to have access to your infrastructure.
Multi-Cloud Without Multi-Sovereignty
One of the practical complications of a private data cloud strategy is multi-cloud. Most large enterprises operate across multiple cloud providers — AWS for some workloads, Azure for others, GCP for specific use cases, plus one or more on-premises environments. Managing data sovereignty across this landscape is a challenge.
The right answer is a data warehouse that can run consistently across all of these environments, with a unified operational model and a unified security posture. That means the same software, the same configuration, the same management interfaces, and the same access control framework regardless of which cloud or data center the instance is running in.
This sounds straightforward but is operationally significant. It means your security team can define data governance policies once and apply them everywhere. It means your compliance team can audit access controls across all environments using the same tooling. It means your platform team doesn’t need to maintain different operational runbooks for different cloud providers.
A unified, multi-environment data platform is not just a convenience — it’s a sovereignty requirement. Fragmented tooling creates fragmented governance, and fragmented governance is precisely what regulators are trying to eliminate.
The Financial Services Case Study
Financial services organizations face some of the most demanding data sovereignty requirements of any industry, and their experience illustrates both the stakes and the path forward.
A large bank operating across multiple European jurisdictions needs to ensure that customer data for German clients doesn’t leave Germany, French client data doesn’t leave France, and so on — while simultaneously needing to run analytics that draws on data from across its business to manage risk, detect fraud, and serve customers. The technical and operational challenge of meeting these requirements while maintaining analytical capability is significant.
Traditional cloud data warehouses require complex workarounds — separate instances per jurisdiction, complex data movement controls, manual governance processes — that are expensive to implement and difficult to audit. A private data cloud, running on the bank’s own infrastructure within each jurisdiction, with a unified management layer that respects the residency boundaries defined in policy, is the architecturally clean solution. Data stays where it’s supposed to be. The management layer provides a global view without moving data across boundaries. Compliance is demonstrable, not just asserted.
The same logic applies to healthcare, to government contractors, to media companies managing rights across territories, and to any multinational organization navigating an increasingly complex global regulatory landscape.
Making the Move
For organizations currently running on a traditional managed cloud data warehouse, the path toward data sovereignty doesn’t have to be a disruptive rip-and-replace project.
Start with a clear inventory of your data and its regulatory obligations. Not all data carries the same sovereignty requirements — some workloads can comfortably remain on public cloud infrastructure, while others need the tighter controls of a private deployment. Segmenting by sensitivity and regulatory obligation gives you a clear roadmap for what to move and what to leave.
Then evaluate platforms on the criteria that matter for sovereignty: deployment flexibility across cloud and on-premises environments, encryption key management, network isolation capabilities, access control granularity, and the clarity of the contractual relationship with the vendor. Technical capability matters, but so does the vendor’s operating model — you want a partner who is genuinely committed to the principle that your data is yours.
Finally, plan for operational continuity. A move to a private data cloud should not require rebuilding your analytics workflows from scratch. SQL compatibility with your existing warehouse, integration with your existing BI and ETL tooling, and a migration path that minimizes disruption are all prerequisites for a project that the business will support.
Cloud-First, Vendor-Independent
The cloud-first mindset has served enterprises well. The benefits of cloud-native architecture — elasticity, automation, operational simplicity — are real and substantial. The mistake was conflating “cloud-native” with “vendor-managed,” as though the only way to get those benefits was to hand over control of your data to someone else.
In 2026, that’s no longer true. Cloud-native software can run on your infrastructure. Kubernetes-based data platforms give you the operational benefits of the cloud without the sovereignty trade-offs of a managed service. The choice between operational convenience and data control is a false one — you can have both.
Cloud-first remains the right strategy. Vendor-controlled is an optional feature, not a requirement. And for the data that matters most to your business, it’s a feature you should opt out of.
Related Resources
- Data Residency: Keep Your Data Local
- Why Private Data Cloud?
- Enterprise Data Warehouse with Enterprise Scale and Ecosystem Support
- Why Hybrid and Multi-Cloud Are the New Normal for Data Warehouses
- The Evolution of Cloud Data Warehousing and the Role of Kubernetes
- Keeping Your Cloud Data Platforms Secure
- Minimizing Cloud Concentration Risk: A Multi-Cloud Approach
- Mission Critical Analytics for Public Sector
- Cloud Migration: Migrate to Cloud, At Your Speed
- Yellowbrick vs. Snowflake
- Yellowbrick vs. Redshift
- How Financial Services Companies Gain a Competitive Edge with Yellowbrick
