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

For years, we operated on the "Modern Data Stack," choosing data warehouse tools for each layer separately: 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.

Data warehouse vs database: what's the difference? #

The terms get used interchangeably, but they describe different things.

A database is the engine — the software that stores, indexes, and queries data. Some use OLTP engines optimised for transactional workloads (many small reads and writes). Others use OLAP engines optimised for analytical workloads (fewer queries, each scanning millions or billions of rows). The engine determines what kinds of queries run fast.

A data warehouse is how you apply a database to a specific problem: consolidating large volumes of historical data from across the business into one place for reporting and analysis. It's an architecture pattern, not a technology. You pick a database engine, load your data into it, and use it to answer questions like "how much revenue did we generate last quarter?" or "which products are trending across regions?"

The distinction matters because OLAP databases can do far more than warehousing. The same engine that powers a data warehouse can also serve sub-second queries in a customer-facing application, process real-time event streams, or act as the backend for an observability platform. A warehouse is one use case for an OLAP database — not the only one.

Where these five systems fit #

Most of the systems in this comparison market themselves as "cloud data warehouses," but they differ in how far beyond warehousing they can go.

Snowflake, Redshift and BigQuery are built for the classic warehouse use case: batch BI, scheduled dashboard refreshes, ad-hoc analysis by internal teams. Their OLAP engines are optimised for that pattern. You wouldn't embed either as the query backend for a user-facing application — the latency and concurrency models don't support it.

Databricks spans data engineering, data science, and warehousing. It's the best option if your primary workload is ML pipelines that also need SQL access.

ClickHouse Cloud is where the database-vs-warehouse distinction becomes most visible. The OLAP engine handles warehouse-scale workloads (petabytes, billions of rows) but also delivers the latency and concurrency you need outside of warehousing — sub-second responses at 1,000+ queries per second. This makes it the only system in this comparison that can power a BI dashboard and a customer-facing analytics feature from the same service.

For a deeper look at the OLAP side of this, see our guide to what OLAP is and how it works.

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, 2025, and 2026 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.

What makes a cloud-native data warehouse? #

"Cloud-native" gets used loosely. Every vendor in this comparison runs in the cloud. The meaningful question is how deeply the architecture depends on cloud infrastructure — and what that means for portability, scaling, and operational control.

Three properties separate a cloud-native data warehouse from a hosted one:

Separation of storage and compute. All five systems decouple storage (object storage like S3, GCS, or Azure Blob) from compute. This is table stakes. It means you can scale storage and compute independently, retain petabytes without paying for idle compute, and spin up fresh compute against existing data.

Elastic, granular scaling. Cloud-native systems scale compute up and down automatically in response to workload, without manual intervention or downtime. Snowflake and Databricks do this at the cluster level: you pick a warehouse size, or add multi-cluster replicas. BigQuery abstracts it entirely behind slot allocation. Redshift Serverless adjusts RPUs automatically, though cold starts can introduce latency spikes. ClickHouse Cloud scales both vertically (within a configured range) and horizontally, adding or removing nodes based on demand. ClickHouse Cloud has parallel replicas that can instantly scale stateless compute nodes up or down as needed.

No on-premise equivalent required. This is where the systems diverge sharply. Snowflake and BigQuery are cloud-only — the engine doesn't run anywhere else. For Databricks, Spark can locally, but the Photon engine and the platform experience is not reproducible. Redshift has a long history as a provisioned cluster that later added a serverless mode.

ClickHouse takes a different approach. The engine is fully open source and runs identically on a laptop, a bare-metal server, or ClickHouse Cloud. The cloud service adds elastic scaling, managed storage, and automated backups on top of the same engine. This means you can develop and test locally with production-identical SQL behaviour, then deploy to ClickHouse Cloud without code changes — something none of the other four support.

Open formats and portability #

Cloud-native doesn't have to mean cloud-locked. Snowflake stores data in a proprietary micro-partition format. BigQuery uses its proprietary Capacitor format. Your data goes in, but extracting it at scale means export jobs and format conversion.

Databricks uses open table formats (Delta Lake, with Iceberg support), which means other tools can read the underlying Parquet files directly. ClickHouse stores data in its native MergeTree format, but supports reading and writing Parquet, ORC, Avro, CSV, and dozens of other formats natively. ClickHouse Cloud also supports direct queries over data in S3 and GCS without ingestion, as well as popular open table formats like Iceberg and Delta, and data catalogs like AWS Glue, Iceberg REST and Unity.

How cloud data warehouses bill you #

Pricing pages tell you the per-unit rate. They don't tell you what you'll actually pay. Each of the five warehouses meters compute differently, and those differences compound as workloads scale. Understanding the billing model matters more than comparing sticker prices.

We published a deep dive into cloud data warehouse billing models that breaks this down system by system. Here's the summary.

Snowflake #

Snowflake bills by credit-hours. A warehouse runs, you pay — regardless of how busy it is. An XS warehouse costs 1 credit/hour ($2–$4 depending on edition). Vertical scaling means picking a bigger warehouse. Horizontal scaling means spinning up additional clusters via multi-cluster warehouses, each with its own credit burn. Extra clusters don't speed up individual queries — they absorb more concurrent ones.

Per-second granularity with a 1-minute minimum.

Databricks #

Databricks SQL Serverless bills by DBUs (Databricks Units). A 2X-Small warehouse burns 4 DBUs/hour; a 4X-Large burns considerably more. At ~$0.70/DBU, the cost is linear with warehouse size and uptime. Multi-cluster scaling works the same way as Snowflake — more clusters for concurrency, each billing independently.

Per-second granularity.

BigQuery #

BigQuery has two modes. On-demand charges $6.25/TB scanned — straightforward for light, ad-hoc use, but costs become unpredictable with complex queries or wide tables. Capacity mode sells slots (logical compute units) at $0.04–$0.10 per slot-hour depending on edition. A single query might consume 1,000 slots during a table scan and 4 during the final merge. You pay for the aggregate slot-time across all stages.

Redshift Serverless #

Redshift bills by RPU-hours (Redshift Processing Units) at $0.36/RPU-hour. RPU allocation adjusts automatically based on query complexity. Billing = RPUs allocated × wall-clock runtime, with a 60-second minimum charge.

ClickHouse Cloud #

ClickHouse Cloud bills by compute units (1 unit = 8 GiB RAM + 2 vCPU). Basic tier starts at $0.22/unit-hour. Unlike every other system here, additional nodes accelerate individual queries, not just concurrency. A single query can distribute work across every node in the service. This means you don't need to over-provision for peak concurrency — the same nodes handle both throughput and latency.

Per-minute granularity.

Billing model differences in practice #

A 30-second query can cost 10× more on one system than another. Snowflake and Databricks charge for the full warehouse uptime. BigQuery charges for data scanned or aggregate slot-seconds. ClickHouse Cloud charges for the compute units actually running. The gap gets wider with concurrency: Snowflake needs a new cluster for every ~8 additional concurrent queries, while ClickHouse Cloud handles 1,000+ queries per second per node on the same compute.

For the full methodology behind these comparisons, including how we normalise billing models into a single cost-performance metric, see Bench2Cost in our cost-performance comparison.

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.

Cost-performance at scale #

We benchmarked all five warehouses using ClickBench — 43 analytical queries derived from production workloads — across three dataset sizes: 1 billion, 10 billion, and 100 billion rows. Each system used its real billing model. The full results are in our cost-performance comparison.

At 1 billion rows, everyone looks similar #

All five systems clustered in the same "fast and low-cost" zone. ClickHouse Cloud on 9 nodes finished the suite in ~23s for ~$0.67. Snowflake Large took ~127s for ~$0.85. Databricks Large: ~80s for ~$0.62. The differences aren't dramatic enough to change a decision at this scale.

At 10 billion rows, gaps open #

ClickHouse Cloud (20 nodes): ~67s, ~$4.27. Databricks Large: ~604s, ~$4.70 — similar cost, 9x slower. Snowflake 4X-Large: ~135s, ~$14.41. BigQuery Enterprise: ~350s, ~$11.73. Cost-performance doesn't scale linearly across systems. The architectures that worked fine at 1B start to show strain.

At 100 billion rows, the picture is stark #

ClickHouse Cloud stayed under $20 and sub-300 seconds. Every other system moved to over $100 and over 1,000 seconds. Snowflake and Databricks were already at their maximum warehouse sizes — ClickHouse Cloud still had headroom.

ClickHouse Cloud also beat every other system on storage size and storage cost by orders of magnitude. The default compression in MergeTree is aggressive out of the box — no codec tuning required.

All configurations were out-of-the-box. No hand-tuning. Results are fully reproducible — see the methodology in the full benchmark post.

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 of data warehouse tools. 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.