Running databases in a single, homogeneous environment is the exception rather than the rule. Gartner reports that 76% of enterprises use more than one public cloud provider, and the vast majority of large organizations maintain some combination of on-premises infrastructure and cloud-hosted systems. Databases end up distributed across environments for many reasons - some deliberate, some accidental - and managing them coherently across that distribution is one of the harder operational problems in modern data engineering.
This article covers why databases end up spread across clouds and hybrid environments, the architecture patterns that make it workable, and where the real complexity lies.
Why Databases End Up Multicloud
Vendor lock-in avoidance
The most cited reason is risk mitigation. Committing all data infrastructure to a single cloud provider creates leverage for that provider at contract renewal time and introduces a single point of failure for the entire business. Organizations negotiate better terms, preserve optionality, and reduce concentration risk by distributing workloads across AWS, Azure, and GCP.
Best-of-breed services
The three major providers have meaningfully different strengths. AWS has the broadest catalog and the most mature database portfolio. Azure integrates deeply with Microsoft-first organizations (Active Directory, SQL Server, Microsoft Fabric). GCP has distinctive offerings in analytics (BigQuery) and globally distributed OLTP (Spanner, AlloyDB). Organizations that want the best available tool for each workload type inevitably land on multiple providers.
Data residency and compliance
Regulatory requirements in the EU (GDPR), financial services, healthcare (HIPAA), and government often mandate that specific data remain within defined geographic boundaries. When a single cloud provider lacks a region in a required jurisdiction, or when different data categories are subject to different residency rules, running databases across providers - or keeping some on-premises - is not optional.
Acquisitions and organic growth
Many multicloud environments were not designed; they accumulated. A company acquires a business running on Azure while the acquirer is on AWS. A team standardizes on Google Cloud SQL while the rest of the organization is on RDS. Over time, the database landscape becomes heterogeneous, and the question becomes how to manage it rather than how to avoid it.
Cost optimization
Cloud database pricing is opaque and heavily workload-dependent. For large, steady-state transactional workloads, reserved capacity on a single provider may be cheaper than an alternative. For bursty analytical workloads, serverless offerings like BigQuery's per-scan pricing can undercut provisioned alternatives. Organizations running at sufficient scale often split workloads across providers for cost reasons, not just technical ones.
Why Databases Stay On-Premises
For organizations operating hybrid environments - part of their database infrastructure on-premises, part in the cloud - the on-premises side usually stays there for specific reasons, not inertia.
Compliance and data sovereignty
Regulated industries often cannot move certain data to public cloud infrastructure regardless of how mature the compliance programs of cloud providers have become. Financial regulators in some jurisdictions require physical control over hardware. Healthcare organizations may face contractual restrictions on third-party data processing. Government agencies may be restricted from public cloud entirely for certain classifications of data. In these cases, on-premises infrastructure is not a legacy concern - it is the requirement.
Latency-sensitive workloads
Network round-trip time to the nearest cloud region is typically 5-30ms for most enterprise locations. For high-frequency trading systems, industrial control applications, or low-latency APIs requiring sub-millisecond database responses, cloud-hosted databases are structurally unsuitable. The physical speed of light makes this a hard constraint rather than a configuration problem.
Data gravity
Large datasets are expensive and slow to move. An organization that has accumulated petabytes of historical data on-premises faces a migration that may take months, cost significant egress fees, and introduce risk. For many organizations, it is cheaper and safer to keep the historical data where it is and bring new analytical workloads to it (via cloud-based processing connected to on-prem storage) than to relocate the data.
Legacy system coupling
Existing on-premises applications may depend on database features, network topologies, or latency profiles that are difficult to replicate in cloud environments. Migrating the database without migrating the application is risky; migrating both simultaneously is a large project. Organizations frequently operate databases on-premises because refactoring the surrounding application is not yet justified.
Hardware economics at scale
At sufficient scale, owned hardware can be cheaper than cloud for stable, predictable workloads. This is well-documented: Dropbox, Basecamp, and others have published analyses showing substantial cost savings from moving high-volume, predictable workloads back to owned infrastructure. For database workloads with well-understood resource profiles running at large scale, the economics favor ownership.
Common Architecture Patterns
Active-passive across clouds (disaster recovery)
The most common multicloud database pattern: a primary database runs in one cloud (or on-premises), with continuous replication to a standby in a second cloud. The standby is not serving live traffic - it exists to enable failover if the primary environment becomes unavailable.
Standard database replication mechanisms handle this: PostgreSQL logical replication, MySQL binlog replication, or managed equivalents (RDS cross-region read replicas, Azure Database read replicas). The standby typically has replication lag of seconds to minutes depending on configuration and network conditions.
The primary challenge is failover automation. Detecting that the primary is unavailable, promoting the standby, and redirecting application connections requires either a managed service that handles it (Route53 failover, Azure Traffic Manager) or custom automation that can itself be a failure point.
Read replicas across regions
A primary database in one region or cloud handles all writes; read replicas in other regions or clouds serve read traffic for users in those geographies. This reduces read latency for globally distributed users without the complexity of multi-master replication.
This pattern is well-supported by managed services and is operationally straightforward. The constraints are the ones inherent to primary-replica setups: replicas may serve slightly stale data (typically milliseconds to seconds), and all writes still route to a single primary.
Active-active multi-master
The most complex and most sought-after pattern: multiple database nodes across different clouds or regions accept writes simultaneously, with bidirectional replication keeping them synchronized. Users are routed to the nearest node, minimizing latency; any node can accept writes.
Implementing this with standard relational databases (PostgreSQL, MySQL) requires careful conflict resolution handling - what happens when two nodes concurrently write conflicting values to the same row? Solutions range from last-write-wins (acceptable for some data types, wrong for others) to application-level conflict resolution logic.
Globally distributed SQL databases - CockroachDB, YugabyteDB, and Google Spanner - were built specifically for this problem. They use distributed consensus (Raft in CockroachDB and YugabyteDB; Paxos in Spanner) to maintain strong consistency across geographically distributed nodes, including across cloud providers. CockroachDB and YugabyteDB can deploy nodes across AWS, Azure, and GCP simultaneously, with automatic sharding and replication managed by the database layer. The tradeoff is write latency: a write must achieve consensus across a quorum of nodes before it commits, and if those nodes are geographically distributed, the speed-of-light constraint applies.
For workloads where strong global consistency is required across regions, these systems are the right answer. For workloads where some replication lag is acceptable, active-passive or read-replica patterns are simpler and often sufficient.
OLTP on-premises or primary cloud, OLAP in a second environment
A pattern that deserves specific attention because it is extremely common in hybrid and multicloud deployments: the operational (transactional) database lives on-premises or in a primary cloud, and analytical workloads run against a separate OLAP system in a different environment.
This is essentially the architecture described in our article on HTAP databases: rather than combining transactional and analytical workloads in one system, they run in separate, purpose-built systems connected by a replication pipeline. In a multicloud or hybrid context, those two systems often live in entirely different environments.
A typical setup: PostgreSQL or MySQL runs on-premises (often for the compliance and latency reasons described above), while ClickHouse or BigQuery runs in the cloud for analytical queries. Change Data Capture (CDC) via Debezium or a managed service streams row-level changes from the on-prem database to the cloud analytical system in near real time. The analytical team works entirely in the cloud; the application team's transactional database stays on-premises; neither workload affects the other.
This separation is often the most practical way to modernize analytical capabilities without migrating the operational database: you add the cloud component alongside the on-premises system rather than replacing it.
The Network Layer
Cross-cloud and hybrid database deployments depend on reliable, low-latency, secure network connectivity. Public internet is rarely acceptable for production database replication - latency is variable, bandwidth is unpredictable, and unencrypted replication streams expose data in transit.
Options in roughly increasing order of reliability and cost:
- Encrypted VPN tunnels over the public internet: cheapest, but variable latency and bandwidth constraints limit replication throughput
- Cloud provider interconnects: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect provide dedicated private circuits between on-premises locations and cloud providers with predictable latency and bandwidth
- Cross-cloud private connectivity: AWS Direct Connect plus Azure ExpressRoute connected through a colocation provider (Equinix, Digital Realty) gives a private path between two cloud providers, eliminating egress over the public internet
- SD-WAN overlays: software-defined networking products that abstract the underlying connectivity and provide traffic management, failover, and QoS across multiple network paths
Egress costs are a significant operational expense in multicloud database environments. Every gigabyte of data that moves from one cloud provider to another (or from cloud to on-premises) costs money. Replication streams, backup transfers, and query results all contribute. These costs are often underestimated at architecture design time and become a source of ongoing budget pressure.
Operations and Tooling
Managing databases across heterogeneous environments requires deliberately choosing where to standardize and where to accept divergence.
Infrastructure as Code is non-negotiable. Terraform is the dominant choice for multi-cloud provisioning - it supports AWS, Azure, GCP, and most managed database services through provider plugins, and its state management model enforces that infrastructure configuration is explicitly tracked. Applying the same IaC workflow across environments provides consistency in provisioning even when the underlying services differ.
Monitoring normalization is the operational challenge that catches organizations off guard. AWS RDS, Azure Database, and a self-managed PostgreSQL cluster on-premises expose different metrics through different mechanisms. Building a coherent view of database health across environments requires either aggregating into a single observability platform (Datadog, Grafana Cloud, New Relic) that has native integrations with all environments, or running a standardized database agent that normalizes metrics at the source. Alert fatigue and blind spots are common when this is left unsolved.
Backup and recovery needs explicit cross-environment strategy. Cloud provider managed backups (RDS automated backups, Azure point-in-time restore) do not cover self-managed on-premises databases. Backup retention policies, storage locations, and restore procedures need to be consistent and tested across all environments. A backup stored only in the cloud provider that just had an incident does not help.
Schema management across environments requires tooling that is environment-agnostic. Flyway and Liquibase handle migration tracking against any JDBC-compatible database, which makes them portable across cloud and on-premises environments. The risk in multicloud setups is schema drift: environments that were synchronized diverge over time because migrations were applied inconsistently.
Real Costs and Tradeoffs
The appeal of multicloud is genuine - vendor independence, geographic flexibility, best-of-breed services. The costs are also real:
Operational complexity scales with the number of environments. Every additional cloud provider or on-premises cluster adds distinct tooling, distinct failure modes, distinct expertise requirements. Teams that struggle to operate a single cloud environment consistently do not simplify their problems by adding a second or third.
Cross-cloud network egress fees accumulate. Database replication streams, analytical query result sets, and backup transfers all generate egress charges. In high-replication-volume environments, this can be a five-to-six-figure annual cost that was not in the original budget.
Cross-cloud latency constrains consistency guarantees. Round-trip time between AWS us-east-1 and GCP us-central1 is roughly 30-60ms. Synchronous replication across that path adds that latency to every write. For most OLTP workloads this is unacceptable; asynchronous replication is used instead, which means the secondary is always somewhat behind.
Skills are fragmented. An engineer expert in RDS PostgreSQL is not automatically expert in Cloud SQL PostgreSQL. Managed services diverge in configuration surface, monitoring, failover behavior, and upgrade procedures. In practice, multicloud database operations require either a larger team or deeper specialization.
The organizations that manage multicloud and hybrid database environments most successfully are those that define a narrow set of supported patterns - one or two replication topologies, a fixed set of approved database services - and invest in automation and tooling for exactly those patterns, rather than treating the full landscape as uniformly manageable.
