Navigating the ClickHouse DBaaS Landscape: Managed Offerings and Architectural Differences

Introduction

Real-time Online Analytical Processing (OLAP) has evolved from a niche application into a core component of modern data platforms. Analytical systems today are expected to ingest hundreds of thousands of events per second while simultaneously serving sub-second aggregation queries over billions of rows. In this domain, ClickHouse has emerged as one of the primary contenders due to its low-level performance optimizations and column-oriented execution model. ClickHouse is a powerful solution as it provides a lot of different configuration options in terms of distribution, replication, and storage. However, operating a distributed ClickHouse cluster in production entails non-trivial operational complexity: managing shard topologies, handling background data part merges, orchestrating ZooKeeper/ClickHouse Keeper consensus, and tuning local storage IOPS. To eliminate this operational overhead, a variety of Database-as-a-Service (DBaaS) providers for ClickHouse have emerged. These providers range from official first-party serverless clouds to specialized cloud-native disaggregated engines, managed open-source infrastructure providers, and high-level developer platforms. Understanding the structural differences between these DBaaS offerings requires looking beneath marketing claims at the underlying database architecture, storage engine implementations, and compute-storage coupling strategies.

Background

How Clickhouse Works

ClickHouse achieves its performance through a combination of (1) column-oriented data layouts, (2) sparse primary indexing, (3) an append-only, log-structured merge storage paradigm, and (4) vectorization:

1. Unlike row-oriented OLTP databases that store full records sequentially, ClickHouse stores each column in separate files grouped into data parts. This minimizes disk I/O during analytical queries, as only the columns referenced in a SELECT statement are fetched from persistent storage. Compression algorithms (such as LZ4 or ZSTD) perform exceptionally well on columnar data due to high type homogeneity.
2. ClickHouse does not maintain dense indexes for every row. Instead, data within each part is sorted according to the table's ORDER BY key. Primary indexes are sparse, containing one index mark per granule (typically 8,192 rows). This allows ClickHouse to perform rapid range scans while maintaining an extremely small memory footprint for indexes.
3. The foundational table engine family in ClickHouse is MergeTree. When data is inserted, immutable compressed parts are written sequentially to disk. In the background, ClickHouse asynchronously merges smaller parts into larger, optimized parts, resolving updates, deletions, or aggregations depending on the specific engine variant (e.g., ReplacingMergeTree, AggregatingMergeTree).
4. Queries are executed in a vectorized manner. Data is processed in blocks consisting of column arrays rather than individual values. This allows the query engine to leverage modern CPU SIMD (Single Instruction, Multiple Data) instructions maximizing instruction-level parallelism.

What is Disaggregated Storage?

Traditionally, distributed databases employ a shared-nothing architecture in which the logical database is split up between individual instances running on separate servers (nodes) while the nodes do not share state with each other. This architecture aims to prevent contention, unnecessary coordination, and single points of failure. Also, in this architecture, compute (CPU/RAM) and persistent storage (NVMe/SSD) are tightly coupled on individual nodes. This means that scaling either storage or compute will scale the other property as well.

A (re-)emerging alternative is compute-storage separation (also known as disaggregated storage) that decouples execution from persistence. Here, some nodes are part of the compute layer while other nodes are part of a storage layer. This separation allows compute nodes to become stateless, i.e. not storing persistent state. Query execution, in-memory aggregations, and query routing are handled by such ephemeral compute nodes and a shared object storage layer provides them the capacity to store and access the data. This storage layer is often implemented using a highly scalable cloud object storage such as S3-compatible stores. Such an architectural split yields several key benefits: First, it allows independent scaling of compute and storage. So when you scale your storage capacity, you don't need to pay for unused compute cores as well. Second, it facilitates elastic scaling of compute, as compute nodes can be added, removed, or resized dynamically without initiating expensive data re-sharding and network data movement across nodes. And third, it improves cost efficiency due to the fact that object storage is oftentimes cheaper than high-performance block or local NVMe storage. Yet, disaggregated storage introduces network latency bottlenecks during cold reads. To offset these read latencies, modern disaggregated query engines heavily rely on multi-tier local SSD caching, metadata prefetching, and parallel object requests.

The SharedMergeTree Engine

In open-source ClickHouse, even when configuring an S3 storage policy for disaggregated storage, metadata management and replica synchronization require every node to independently process replication queues and replicate metadata state. The SharedMergeTree is a proprietary MergeTree variant only available in ClickHouse Cloud that eliminates replica-to-replica communication entirely. Replicas interact strictly with shared object storage for data blocks and ClickHouse Keeper for central metadata coordination When a node performs an insert or a background merge, it writes the resulting part directly to the object storage and registers the new part state in Keeper. Other compute nodes fetch the updated metadata asynchronously and can immediately read the new parts from object storage.

Overview of ClickHouse DBaaS Offerings

ClickHouse Cloud

The official DBaaS platform built by ClickHouse Inc. It leverages SharedMergeTree on top of AWS, GCP, and Azure object storage. It provides automatic scaling and advanced compute resource handling, e.g., complete isolation of read/write compute resources and separation of different compute groups ("services") on the same data. There is also a Bring Your Own Cloud (BYOC) variant available with the same engine.

ObsessionDB

Built explicitly as a drop-in, API-compatible alternative to ClickHouse Cloud ObsessionDB addresses cloud object storage performance limits of the OSS variant of ClickHouse by implementing an API-compatible SharedMergeTree variant coupled with a custom distributed caching architecture. This design targets tail-latencies and cold-start latencies inherent in standard S3-backed setups, delivering sub-second execution across multi-terabyte datasets.

OVH Managed ClickHouse

Hosted on OVHcloud public cloud infrastructure, this service provides fully managed open-source ClickHouse nodes with strict European data sovereignty and compliance. Providing single node and triple-node setups, it focuses on fixed, predictable resource allocations (dedicated CPU/RAM and NVMe block storage) for organizations requiring deterministic cost models without public cloud egress surcharges.

Elest.io Managed ClickHouse

A managed service that deploys open-source ClickHouse onto dedicated, isolated virtual machines across various cloud environments, also beyond hyperscalers. The service also offers vendor-independent management features (e.g., automated OS/database updates, daily backups) and varying support levels.

Elest.io Managed ClickHouse S3: A specialized configuration of Elest.io's managed ClickHouse that pre-configures open-source ClickHouse S3 storage disks and policies. Hot data resides on fast local block storage for high-frequency ingestion, while historical cold data is offloaded to S3-compatible object storage, offering a hybrid storage architecture with the open source ClickHouse variant.

Aiven Managed ClickHouse

A multi-cloud DBaaS platform that runs open-source ClickHouse across AWS, GCP, Azure, and OVH. Aiven integrates ClickHouse into its broader data ecosystem, enabling features such as automated VPC peering or seamless streaming ingestion pipelines from Aiven for Apache Kafka and PostgreSQL sources. Larger plans allow cluster up to 30 nodes.

Altinity Managed Service for ClickHouse

Altinity provides managed open-source ClickHouse on the three hyperscalers, Hetzner or within a customer's private cloud (BYOC). It relies on the open-source Altinity Kubernetes Operator for cluster management, offering enterprise control, granular configuration tuning, and architectural support.

Instaclustr Managed ClickHouse

Part of NetApp's data infrastructure stack, Instaclustr offers fully managed open-source ClickHouse instances focused on operational SLAs, automated provisioning, and zero downtime scaling.

Scaleway Data Warehouse for ClickHouse

Scaleway's fully managed analytical offering provides managed ClickHouse instances hosted exclusively on European cloud infrastructure. Pricing is based on usage of storage and vCPU consumption.

several9s Managed ClickHouse

several9s supports managed ClickHouse as part of their DBaaS management platform ClusterControl. The platform automates management operations such as deployment, scaling, and backups in three possible environments: on-prem, BYOC, and Kubernetes-based infrastructures. The main offering is a service with monthly subscription that only covers access to the management platform, so costs for the actual infrastructure (on-prem/cloud) are not included.

Tinybird

Tinybird abstracts raw ClickHouse cluster administration behind an API-centric developer interface. Users stream data via HTTP or Kafka into managed ClickHouse tables and write SQL transformations that are instantly published as parameterized, low-latency REST APIs. It caters to application engineers building customer-facing analytics who prefer not to manage database infrastructure directly.

Comparison of ClickHouse DBaaS Offerings (as of July 2026)

Summary and Practical Considerations

The ClickHouse DBaaS landscape presents a diverse spectrum of offerings. Organizations choosing between these options face critical trade-offs:

1. Disaggregated Storage vs. Stateful Nodes: Platforms leveraging disaggregated storage (SharedMergeTree or custom engines like ObsessionDB) excel at elastic compute scaling, dynamic warehouse management, and isolating unpredictable query workloads. Conversely, managed open-source deployments running purely on dedicated NVMe block storage (e.g., Aiven, OVH) provide different latency profiles, as no external object storage is involved.
2. Level of Service Management: There is a broad variety, what different providers consider a "managed ClickHouse" service. Some providers focus on the automated deployment of a pre-configured ClickHouse cluster to a fixed number of cloud nodes, maybe with additional customer support. Others provide a much more abstract service in which the underlying infrastructure and scaling steps are almost entirely hidden ("serverless").
3. Pricing: Similar to the degrees of service management, also the pricing model differ. Most providers charge based on the number of required infrastructure nodes, plus some additional fee included for the management service. The more "serverless" offerings, especially ClickHosuse Cloud and ObessionDB, follow a usage-based approach instead, in which costs are derived from storage and compute capacities. several9s is a special case in terms of pricing, as their service only includes the monthly fees for the management platform, but not the required infrastructure.

The Imperative of Empirical Evaluations

While architectural documentation and feature checklists provide an essential starting point, they cannot accurately predict real-world database performance.

In analytics, synthetic vendor benchmarks rarely match actual production dynamics. A DBaaS solution that demonstrates exceptional throughput during batch insertions may exhibit high query latency under concurrent analytical loads. Similarly, disaggregated object storage architectures can suffer from significant tail-latency spikes depending on query access patterns, object storage provider limits, and internal caching mechanisms.

At benchANT, we specialize in objective, workload-tailored database benchmarking. We believe that selecting the optimal DBaaS requires evaluating solutions under realistic, reproducible write/read ratios, dataset scales, and concurrency profiles.

What is the true cost-per-query ratio across these ClickHouse offerings? How does SharedMergeTree on ClickHouse Cloud actually compare against an optimized, managed open-source ClickHouse cluster or ObsessionDB's shared table engine under heavy write pressure?

Stay tuned for our upcoming ClickHouse DBaaS Performance Benchmark Series, where benchANT will put some of these offerings to the test with rigorous empirical measurements.