Top 5 cloud data warehouses in 2026: Architecture, cost, and open-source

For years, we operated on the "Modern Data Stack," a fragmented model where the Data Warehouse handled BI and batch reporting, separate from "speed layers" used for real-time analytics, dashboards, and operational data. Previous generations of tooling could not handle both batch and real-time workloads effectively, meaning the only viable choice was to have multiple, fragmented systems. This dual-system approach was a pain: data duplication, inconsistent definitions, and spiraling TCO from paying for redundant compute and storage.

Today, the goal is simple: unify these workloads. Modern tooling is now capable of delivering the elasticity of the cloud and the performance needed for sub-second applications in a single cloud architecture.

We're looking at the top five platforms used for Cloud Data Warehousing: Snowflake, Google BigQuery, Amazon Redshift, Databricks, and ClickHouse Cloud.

Data warehouse architecture #

The competitive landscape among top cloud data warehouse vendors is fundamentally shaped by their underlying architecture. The key defining characteristic of modern platforms in 2025 is the decoupling of storage and compute. This is a direct contrast to the older, monolithic architectures, like those found in early Vertica, Teradata, and original Amazon Redshift implementations, where storage capacity was inextricably linked to compute power in fixed-size, "shared-nothing" clusters. This coupling created significant economic inefficiency; to retain more data, organizations were forced to provision more compute, often regardless of their actual querying needs. This inefficiency is why coupled architectures are now generally obsolete for modern, general-purpose cloud warehousing.The competitive landscape among top cloud data warehouse vendors is fundamentally shaped by the specific problems their architectures were initially designed to solve. The first generation of cloud data warehouses emerged primarily to fix the operational nightmare of previous-generation systems like Hadoop and legacy data warehouses. These older systems were notoriously complex to build, required extensive time for installation and setup, and proved brittle to operate and difficult to scale.

The new wave of cloud data warehouses focused on solving this operational challenge: delivering the same core business needs of BI and reporting, but within a superior, user-friendly package. This design goal led to architectures that prioritized ease of use, instant provisioning, and simplified scalability, often by adopting the decoupled storage and compute model.

However, this foundational design choice, focused on operational simplicity for traditional batch analytics,means many current cloud data warehouse architectures now struggle to cope with the increasing demands of modern data applications. They face inherent limitations in supporting ultra-fast queries, real-time data ingestion, streaming workloads, and user-facing analytical applications that require low-latency performance at scale.

Separation of storage and compute #

Every major vendor has re-architected around object storage (Amazon S3, Google Cloud Storage, Azure Blob Storage) as the primary persistence layer. This shift leverages the fundamental economics of the cloud: storage is cheap and durable, while compute is expensive and ephemeral.

This architectural decoupling provides three non-negotiable advantages:

1. Elastic Scalability: Organizations can retain petabytes of historical event logs for compliance or long-term trend analysis without incurring linear compute costs. Conversely, they can spin up thousands of cores for a complex end-of-quarter transformation job and shut them down immediately after, aligning spend with utility.
2. Workload Isolation: Because the "truth" of the data resides in a shared object store, multiple independent compute clusters can access the same datasets simultaneously without contention. A data science team training a model on raw_events will not degrade the performance of the CFO’s executive dashboard querying the same table, as they utilize physically separate compute resources.
3. Statelessness and Resilience: Compute nodes can become stateless commodities. If a node fails, it can be replaced instantly without data loss or lengthy rebalancing operations, as the data persists safely in the object store layer.

However, while the high-level diagram looks similar across all five vendors, the implementation details create vast differences in performance, cost, and freedom.

Open-source vs. proprietary #

Snowflake and BigQuery take the closed platform approach. They offer a highly polished, fully managed experience where the underlying mechanics are entirely proprietary and obfuscated. The data is converted into closed formats, Snowflake's micro-partitions or BigQuery's Capacitor format, creating an inescapable "walled garden." Crucially, the entire system, from the storage format to the compute engine, is closed-source. Users cannot run the engine locally and are entirely dependent on the vendor's cloud platform. This lack of architectural transparency and the proprietary format mean data is computationally expensive to use anywhere else.

Databricks champions the "Lakehouse" architecture, utilizing open table formats (Delta Lake, Iceberg) to maintain data accessibility. Theoretically, this prevents elements of data lock-in because the data files are open. While Databricks utilizes open-source components like Apache Spark and Unity catalog, and users can run these independently of Databricks, it is not possible to self-host or reproduce the Databricks platform.

ClickHouse Cloud introduces an open platform architecture. The managed service is built upon the open-source ClickHouse database. The technology powering the multi-petabyte cloud warehouse is freely available, meaning that developers can run the same engine on their laptop, or self-host in their own cloud or bare-metal servers. The open-source nature of the ClickHouse Cloud platform extends to other components. For example, ClickPipes, the managed suite of ETL connectors, utilizes PeerDB, and the ClickStack observability product is powered by HyperDX. This architectural transparency and open-source foundation offer a level of portability and verifiable freedom that proprietary closed platform alternatives cannot match, allowing users to verify performance claims and maintain a credible exit strategy.

The Top 5 Cloud Data Warehouses #

Snowflake #

Snowflake is one of the most recognised and highly regarded cloud data warehouses on the market. It launched in 2015, several years after Google BigQuery and Amazon Redshift, yet it receives much of the credit for popularising the cloud data warehouse model. Snowflake delivered on the promise to take the power of Hadoop and make it simple to start, easy to operate and truly cloud-native. It offers one of the most comprehensive and well-crafted experiences for traditional warehousing workloads like business intelligence and reporting. Snowflake’s biggest criticism tends to be around cost, and it’s often seen as one of the most expensive cloud data warehouses.

• Architecture: Snowflake utilizes a central data repository in object storage, accessed by "Virtual Warehouses" (compute clusters). These warehouses utilize a local SSD cache to accelerate queries. When a warehouse is spun up, it is initially "cold" and must pull data from remote storage (S3) to populate its cache, a process that can introduce latency.
• Strengths: The platform excels in usability for analysts, with a well-crafted, web-based console. Performance for batch-based reporting is among the best of traditional cloud data warehouses. It offers fast and simple horizontal auto-scaling that makes it easy to handle spikes in dashboard usage or report generation.
• Weaknesses:
  • Cost: The architecture often leads to costly horizontal scaling; since each warehouse has a limited concurrency for queries, the platform scales 'wide,' and costs multiply because scaling only happens in large, fixed 't-shirt' size increments. While vertical scaling to a larger size can speed up individual large queries, it doesn't increase overall query capacity, and sizing up to accommodate outliers makes subsequent horizontal scaling even more expensive, regardless of how small most other queries are.
  • The Performance Ceiling: Snowflake is not optimized for sub-second, high-QPS workloads typical of real-time analytics. Its micro-partition architecture, while efficient for scanning large ranges, introduces overhead that prevents the millisecond-level response times required for user-facing applications.
  • Iceberg Performance Penalty: While Snowflake has introduced support for Iceberg to counter the "lock-in" narrative, benchmarks indicate a significant performance penalty. Native Snowflake tables often perform 2-5x faster than external Iceberg tables because the native format allows for proprietary metadata optimizations and caching strategies that open formats do not fully leverage within the Snowflake engine.
  • Local testing and self-hosting: Snowflake fails the "laptop test." It offers a Snowpark Local Testing Framework, but this is strictly an emulator for the Python DataFrame API. It does not run the SQL engine locally, meaning developers cannot test SQL logic, stored procedures, or performance characteristics offline. This creates a hard dependency on the cloud service for all development cycles.

Google BigQuery #

BigQuery was one of the first cloud data warehouses available. It operates on a model derived from Google's internal Dremel technology. It is "true serverless" in that users do not provision instances; they submit SQL queries to a massive, multi-tenant pool of compute slots.

• Architecture: BigQuery separates compute and storage, connected by the petabit-scale Jupiter network. It uses a tree architecture to dispatch query fragments across thousands of nodes.
• Strengths: The "no-ops" experience is unmatched for ad-hoc analysis. A data analyst can run a query over a petabyte of data without ever thinking about cluster sizing.
• Weaknesses:
  • The Slot Lottery: The "Slot" abstraction obfuscates the hardware. Users are subject to "Slot Contention," where query performance fluctuates based on the total load in the Google region or the user's reservation tier. This unpredictability makes it difficult to guarantee SLAs for user-facing applications.
  • Concurrency Limits: While scalable for massive data volumes, BigQuery struggles with high concurrency. It enforces hard limits on the number of concurrent queries (often 100 per project by default), and the latency for small, frequent queries is high due to the overhead of the job scheduling system. This makes it poor for operational dashboards that refresh every few seconds.
  • Emulator Limitations: Like Snowflake, BigQuery cannot be run locally. Developers must rely on third-party emulators or the BigQuery Sandbox, which do not replicate the performance characteristics or full feature set of the production engine.

Amazon Redshift #

Redshift also predates Snowflake and is one of the earliest cloud data warehouses. Redshift has implemented several modernizations, such as RA3 nodes (decoupled storage) and a Serverless offering that help it to remain competitive with Snowflake and BigQuery.

• Architecture: Redshift's roots lie in a ParAccel/Postgres fork. While RA3 nodes separate storage, the system relies on "AQUA" (Advanced Query Accelerator) hardware caches to mitigate the latency of S3.
• Strengths: Deep integration with the AWS ecosystem (Glue, Kinesis, DynamoDB Zero-ETL) makes it the "path of least resistance" for AWS-native shops. It offers competitive price-performance for predictable, steady-state reporting workloads.
• Weaknesses:
  • Operational Complexity: Despite "Serverless" branding, Redshift requires significant tuning. Users often must manage sort keys, distribution keys, and workload management (WLM) queues to achieve acceptable performance.
  • The Serverless "Cold Start": User reports and technical analyses of Redshift Serverless highlight its cold start latency. When a workload pauses, the backend infrastructure spins down. The subsequent query can take seconds or even minutes to initialize as resources are re-provisioned, a behavior unacceptable for real-time analytics.
  • The Zero-ETL Trap: While "Zero-ETL" integration with Aurora has some integration benefits, it can prevent a Serverless warehouse from ever auto-pausing, as the continuous replication stream keeps the cluster active. This leads to unexpectedly high bills, forcing users back to provisioned clusters.

Databricks #

Databricks' origins lie in data engineering and data science. Databricks excels for users who prefer to write code (e.g., Python, Scala) over pure SQL. It is arguably the most capable platform for data science and machine learning workflows, offering significant built-in tooling for heavy data transformations and model work right out of the box. However, Databricks has higher operational complexity than most alternatives and is the least focused on the typical data analyst user.

• Architecture: Built on Apache Spark and the Delta Lake format. The "Databricks SQL" offering utilizes Photon, a vectorized query engine written in C++ to accelerate SQL performance.
• Strengths: The unification of Data Science and Warehousing reduces data movement. Using open formats (Delta/Parquet) theoretically reduces storage lock-in. It is the superior choice for heavy ETL transformations and complex machine learning workflows.
• Weaknesses:
  • Complexity: Databricks provides a comprehensive and tightly-integrated platform covering ETL, data warehousing, machine learning, and BI. While powerful, the sheer breadth of tools, services and configurations can introduce a steep learning curve and operational complexity for teams only focused on core data warehousing needs.
  • Photon Lock-In: The Photon engine is proprietary. Benchmarks show that standard Spark clusters are significantly slower than Photon-enabled clusters for SQL. Therefore, to get competitive performance, users are effectively locked into Databricks' proprietary runtime. You cannot simply take your Delta Lake data and query it with open-source Spark elsewhere and expect the same results.
  • Local Development Friction: While Spark can run locally, Databricks’ Photon engine cannot. Moreover, while Databricks uses other open tools, such as the Unity Catalog, the full suite of integrations, workflows, and operational methods are not possible to replicate locally.

ClickHouse Cloud #

ClickHouse Cloud represents the convergence of "Cloud Native" elasticity with "Real-Time" performance and "Open Source" freedom.

• Architecture: ClickHouse Cloud builds upon the open-source ClickHouse database, adding compute-storage separation, compute-compute separation, and fully stateless compute nodes for instant horizontal scaling. ClickHouse Cloud also includes ClickPipes, a managed service offering ETL connectors, including Change Data Capture (CDC) for operational databases such as PostgreSQL, MySQL, and MongoDB. ClickPipes is built on the open-source PeerDB. Additionally, ClickStack is available as an open-source observability product.
• Strengths:
  • Performance: It provides best-in-class performance for aggregations and filtering, often delivering queries 100-1000x faster than row-oriented systems and 2-10x faster than other cloud data warehouses for comparable workloads.
  • Portability: It is the only platform where all core components are open source. Users can self-host large scale deployments in their own cloud, or easily run local binaries on their laptops during development. The ClickHouse database is the most flexible of all warehouse engines, being able to run on a cluster of servers, a single server, in containers, as a process on a laptop, serverless on the CLI and in-process within a Python application. This offers unrivaled flexibility to fit ClickHouse into any workflow, while remaining compatible with the managed Cloud service.
  • Cost: Its extreme compression and efficient C++ engine often result in 4x lower TCO compared to Snowflake.
• Weaknesses:
  • JOINs have had significant improvement: Historically, ClickHouse has been less competitive when queries include many, or large, JOINs. However, updates throughout 2024 and 2025 have largely mitigated this. Benchmarks now show ClickHouse outperforming both Snowflake and Databricks in various join-heavy workloads. JOINs in ClickHouse are one of the fastest developing areas of the database, with new features and optimisations landing every month.
  • Recent support for Updates and Deletes: ClickHouse is an append-heavy system. Prior to 2025, UPDATE and DELETE statements were sub-optimal, requiring more care to use without impacting system performance. In 2025, the architecture behind these statements was rearchitected, fundamentally changing how they perform. ClickHouse now fully supports SQL-standard UPDATE and DELETE statements, with performance that rivals Postgres for single-row and batch UPDATE/DELETE operations.

Cost efficiency #

Most businesses have passed the “Modernisation” phase, having fully embraced the cloud data warehouse. While this modernisation has had many benefits, it has often brought with it an ever-increasing cloud operational spend. Many businesses now find themselves in an “Optimisation” phase.

How Much Does it Cost to Scale "Always-On" Workloads? #

For traditional data warehousing needs like batch processing or periodic reporting, the pricing models of Snowflake, ClickHouse Cloud, and even BigQuery are relatively comparable. In these scenarios, where queries are infrequent and predictable, users pay for compute time or data scanned, and resources can be suspended during inactivity.

However, a significant economic divergence emerges when transitioning to real-time, user-facing analytics. In this "always-on" environment, the inefficiency of legacy architectures creates a massive cost multiplier.

When serving high-concurrency workloads, such as embedded analytics for thousands of users, traditional warehouses are forced to scale in ways that are economically punishing:

Snowflake #

The "Scale-Out" Penalty Snowflake’s architecture typically limits a single warehouse to approximately 8 concurrent queries before performance degrades and queuing begins. To handle higher concurrency, it relies on "Multi-Cluster Warehouses," which auto-scale by spinning up entire, redundant clusters.

Serving 1,000 concurrent users effectively forces a customer to pay for dozens of duplicate warehouses running simultaneously. You are not paying for the utility of the query; you are paying for the availability of the slots, leading to linear cost multiplication.

Google BigQuery #

BigQuery’s default "on-demand" model charges per Terabyte scanned ($5/TB). While efficient for ad-hoc queries, this is fatal for high-concurrency apps. If a dashboard refreshes every 30 seconds for 1,000 users, the bill multiplies by the number of executions.

Users are forced to "Capacity Pricing" (Slots) to cap costs, but this introduces the "Slot Lottery". If the reserved slot capacity is insufficient for the concurrency spike, queries are throttled or queued. To avoid latency, teams must over-provision slots, paying for peak load 24/7.

Amazon Redshift #

Redshift Serverless markets itself as a consumption-based model, but technical limitations often prevent true cost savings.

Cold starts can cause delays of seconds or minutes when scaling up. Furthermore, features like "Zero-ETL" integration can prevent the warehouse from ever auto-pausing, keeping the meter running continuously even during low usage periods.

ClickHouse Cloud #

ClickHouse Cloud is inherently architected for high concurrency, capable of handling thousands of queries per second (QPS) on a single compute unit without the need to spawn redundant clusters.

Because ClickHouse processes analytical queries significantly faster, often with sub-second latency, it holds onto compute resources for a fraction of the time compared to alternatives. A workload that requires a massive Multi-Cluster Snowflake environment or a large BigQuery Slot reservation can often be served by a single, moderately sized ClickHouse service.

Ultimately, for user-facing applications, ClickHouse Cloud reduces the infrastructure footprint necessary to meet SLAs. By removing the need to pay for "redundant" compute (Snowflake) or "data scanned" penalties (BigQuery), it results in a Total Cost of Ownership (TCO) that is frequently a fraction of the cost.

Portability, openness, and the "Laptop Test" #

Perhaps the biggest differentiator among cloud data warehouses is freedom, portability and openness. Most cloud data warehouses have been built as proprietary black boxes. While some platforms like Databricks use open components, most cloud data warehouses have no ability to be self-hosted or replicated for local development workflows.

The "Laptop Test": Can I run my warehouse locally? #

Vendor lock-in is often technical before it is contractual. If a developer cannot run the database locally, development cycles are slowed by network latency, cloud costs, and the inability to work offline.

• ClickHouse: Passes the "Laptop Test" unequivocally. A developer can download the clickhouse binary (a single ~100MB file) or use the clickhouse-local tool to run the same SQL engine on a MacBook Pro that runs in the multi-petabyte production cloud. This enables rapid prototyping, zero-cost unit testing in CI/CD pipelines, and the ability to analyze local files (Parquet, CSV, JSON) using the full power of the engine without spinning up infrastructure. This parity between dev and prod is unique in the market. This extends to other ClickHouse Cloud features, such as ClickPipes (ETL connectors) with PeerDB, and ClickStack for observability.
• Snowflake: Fails the test. There is no "local Snowflake." The Snowpark Local Testing Framework is a Python library that emulates DataFrame operations; it does not run the SQL engine, cannot execute stored procedures, and does not replicate the performance characteristics of the cloud. It is a simulation, not a replica.
• BigQuery & Redshift: Fail the test. BigQuery relies on emulators or the "Sandbox" (free tier cloud usage), while Redshift offers no official local version. Community Docker images exist but are often outdated Postgres forks that do not reflect Redshift's actual behavior or feature set.
• Databricks: Partially passes. While Apache Spark can run locally, the proprietary Photon engine, which provides the performance necessary for modern warehousing, cannot. Developing locally on open-source Spark and deploying to Photon-powered Databricks creates a "performance gap" where query plans and execution speeds differ significantly.

Use cases: finding the right tool for the job #

ClickHouse Cloud offers the convergence of speed, efficiency and freedom that makes it highly adaptable for varied workloads.

Batch-based BI & reporting #

• Winner: Snowflake
• Reasoning: For static, internal dashboards and scheduled reporting, Snowflake remains highly compelling. Its ease of use, robust semantic layer, and deep integration with common BI tools (Tableau, PowerBI) make it a low friction path. Snowflake's "set and forget" nature is optimized for low-concurrency, high-complexity SQL reporting where query speed is unimportant. Snowflake offers good capabilities for suspending resources to manage costs when workloads are scheduled and highly predictable.
• Why ClickHouse Cloud is a compelling alternative: ClickHouse Cloud offers first-class support for batch-based BI & reporting, having seamless integrations with Business Intelligence tools, and can dramatically accelerate reporting. This speed helps businesses achieve greater agility in their decision-making and responsiveness. ClickHouse Cloud is adaptable for evolving needs: it's not limited to just scheduled reports. If your requirements grow from simple reporting to supporting automated workflows (like real-time fraud detection), powering user-facing, real-time applications, or handling high-velocity streaming ingestion sources, ClickHouse Cloud is the ideal choice.

Real-time user-facing analytics (data apps) #

• Winner: ClickHouse Cloud
• Reasoning: When analytics are embedded into a product (e.g., "Show 50,000 users their personal usage stats simultaneously"), the requirements shift from "complex joins" to "high concurrency" and "low latency." Snowflake, Redshift, BigQuery and Databricks falter under this load, often hitting concurrency limits and incurring massive costs. ClickHouse's architecture is purpose-built to serve thousands of concurrent queries with millisecond latency, making it the undisputed leader for "Data Apps" and Observability backends.

Spark, custom ETL and data science #

• Winner: Databricks
• Reasoning: For workflows that involve heavy programmatic transformations (Python, Scala) or training machine learning models, Databricks' Spark heritage provides the richest environment.
• Why ClickHouse Cloud is a compelling alternative: ClickHouse Cloud has the ability to define custom User-Defined Functions (UDFs) allowing for extending database functionality with custom logic. ClickHouse can be seamlessly embedded directly within Python processes by using chDB. This unique in-process capability allows data scientists and data engineers to leverage the extremely fast ClickHouse engine and its SQL capabilities directly on data frames or other in-memory data structures within a Python environment, creating a highly efficient, unified data processing flow for tasks like feature engineering, fast-lookup tables, or complex custom ETL steps.

AdTech, FinTech, and high-volume events #

• Winner: ClickHouse Cloud
• Reasoning: These verticals generate massive streams of immutable event data (clicks, trades, logs). They require specialized analytical functions that are native to ClickHouse. The ability to ingest millions of events per second, while simultaneously serving highly-concurrent queries, makes ClickHouse the standard for high-throughput telemetry.

Conclusion #

Snowflake and BigQuery represent the pinnacle of the "Managed Convenience" era. They are powerful, polished, and capable, but they operate as "Walled Gardens" where data gravity and proprietary engines create a high barrier to exit and a high floor for costs.

ClickHouse Cloud represents the open platform era. It validates the cloud-native architectural standard, but rejects the lock-in of its predecessors. By offering an engine that is open-source, fundamentally faster for modern workloads, and portable from the developer's laptop to the serverless cloud, it empowers engineering leaders to build their data strategy on a foundation they control.