ClickHouse Cloud alternatives: managed ClickHouse without the $67 floor

Short version: ClickHouse Cloud's cheapest tier is Basic, from $66.52 a month, and it buys you a real production service: one replica with 8 GiB of dedicated RAM, per-minute compute metering, idling when nobody is querying. That is good value for a company's analytics platform. It is a lot of money for the ClickHouse behind a staging environment, a side project's event pipeline, or the one dashboard your team looks at on Mondays. Layerbase runs ClickHouse 25.12 on a flat Pro plan, and Pro is $15/month, inside a shared pool that is smaller than a Basic replica and honest about it. Pick by workload size, not by logo.

I want to be careful with this one, because ClickHouse Cloud is not overpriced. The people who built the engine also run the best-operated hosted version of it, and the tier structure makes sense once you see what each rung is for. The problem is narrower than "too expensive." It is that the ladder starts at a rung most small workloads never need to stand on.

The price ladder

Verified 2026-09-06 from the ClickHouse Cloud billing overview:

Compute is metered per minute in 8 GiB RAM increments, so the smallest thing you can rent is one 8 GiB unit and the meter ticks while it is awake. Storage is billed on compressed size, and their own Basic example carries $25.30 a month of storage on top of the compute line. Basic can idle: the service pauses after a period of inactivity and wakes on the next query, which is on by default and is the main reason a lightly used Basic service lands near the floor rather than above it. New accounts get 30 days of trial credits.

Two things about that table deserve saying out loud. First, $66.52 is the floor, not the bill. Add storage, add a busy month where idling never kicks in, and my back-of-envelope is Basic settling somewhere around $90 to $110 for a service that is doing real work. Second, the jump from Basic to Scale is 7.5x. There is no $150 rung. If you need a second replica for availability, the next stop is $499.

Who owns this search result

If you search for ClickHouse Cloud alternatives, you get Tinybird. Three of their posts rank, and all three compare the same four names: ClickHouse Cloud, Tinybird, Altinity, and Instaclustr. Every one of those is a good option for a company with an analytics platform to run. Every one of them also prices like a platform. None of the lists includes a flat monthly plan where ClickHouse is one engine among several, because until recently nobody sold that. I wrote up how we compare to Tinybird specifically, and the short version is that Tinybird is a developer platform on top of ClickHouse with its own pipe abstraction, while what we sell is ClickHouse itself with a connection string.

Why the floor is the story

Count the ClickHouse services you actually run.

There is production, which deserves a Basic tier or better. Then there is the staging copy, because you learned not to test a schema migration on the one your dashboards read from. There is the local-ish one CI populates with a day of fixtures. Maybe a scratch one for the analyst who wants to try a materialized view without asking. On ClickHouse Cloud, that is four services and a floor of roughly $266 a month before storage, and three of those four services idle almost all the time.

Idling helps, but it does not change the shape. A service that wakes for a five-minute CI run still bills the 8 GiB unit for those minutes, and a staging service that a human pokes at throughout the day never idles long enough to matter. The price is built for one big service that earns its keep, and it punishes the small ones around it.

That is where a flat plan has a different shape. Pro is $15/month for up to 10 databases across every engine we host in the cloud, and a ClickHouse database is one of those ten. The staging ClickHouse, the CI ClickHouse, and the Postgres they sit next to cost nothing extra because they fit in the plan you already bought.

What Layerbase actually gives you

ClickHouse 25.12, current line. A new database on Layerbase Cloud runs 25.12. It is a Performance engine, which means it is always-on and draws from the Pro plan's 1.5 GB always-on pool rather than sleeping and waking like the Standard engines do.

Flat pricing. Pro is $15/month: up to 10 databases, 25 GB of storage, every one of the 18 engines on Layerbase Cloud, 10 branches per database, 30-day rolling backups, and a 7-day trial. There is no per-minute meter and no storage line item until you outgrow 25 GB. For context, Free is $0 and Solo is $5/month, but ClickHouse is a Pro-tier engine, so Pro is the rung it lives on.

Grow by blocks, not by tiers. When the pool is too small, add $10/month pool blocks for +1 GB RAM, +1 vCPU and +25 GB of storage each. They stack up to 20. That is a number you can say out loud and a slope you can predict, which is the thing a per-minute meter never lets you do.

Or take a whole box. If you want dedicated RAM the way Basic gives it to you, a Dedicated server starts at $35 a month for 4 GB (8 GB is $65, 16 GB is $120). It is a private single-tenant VM with every engine available on it, and a 4 GB box is a closer match to what a Basic replica gives you than the shared pool is.

One HTTPS endpoint, standard tools. Quick Connect hands you an https:// URL, a username, and a password. That is ClickHouse's HTTP interface over TLS, which is what the official Node, Python, Go, and Java clients, Grafana, Metabase, and plain curl speak, so those connect with a host and credential swap. What we do not expose is the native TCP port, so if your tooling is clickhouse-client on port 9000 or 9440, that is the one thing to check before you move. The copy below runs the native side against ClickHouse Cloud and the HTTP side against Layerbase.

The rest of the stack on the same bill. The Postgres your events came from, the Redis in front of it, the Meilisearch for the search box, all on the same account and the same $15. ClickHouse Cloud sells ClickHouse, and if you need the rest, that is other vendors and other invoices. The one exception is their managed Postgres, which is a different comparison and one I have already written up.

Being straight about what a pool is

ClickHouse Cloud Basic hands you 8 GiB of RAM that is yours and a replica on top of it. Our Pro plan hands you a 1.5 GB always-on pool that ClickHouse shares with whatever else you pinned to it. Those are not the same thing, and I would rather you hear it from me than discover it.

What the pool is good for: an events table in the tens of millions of rows, a dashboard that runs a few dozen aggregations an hour, a staging or CI copy of a bigger cluster, a side project that outgrew GROUP BY in Postgres. ClickHouse is astonishingly frugal with memory for that kind of work because it streams over compressed columns, and most queries at that scale finish before they need much RAM at all.

What the pool is not good for: a JOIN between two multi-billion-row tables, a 200-column-wide table with high-cardinality GROUP BYs across it, anything where ClickHouse Cloud's auto-scaler would already be reaching for a second unit. If you are running that, add pool blocks or take a Dedicated server, and if you are running it at company scale, Basic or Scale is honestly the right buy.

There is also a fair "do you need ClickHouse at all" question at the small end. If the dataset fits on one machine and the queries are ad hoc, DuckDB may be the better tool, and DuckDB is on our Free tier.

Moving a database

ClickHouse makes this easy, because the engine's own formats do the work.

1. Create the target. Make a ClickHouse database on Layerbase Cloud and copy the connection details from Quick Connect. Recreate your schema first, from SHOW CREATE TABLE on the source, with one change: ClickHouse Cloud tables use SharedMergeTree, and a self-contained server wants plain MergeTree (or ReplacingMergeTree and friends). Swap the engine name in each CREATE TABLE and the rest of the DDL carries over.

2. Stream the data across. The Native format is compressed, typed, and fast. clickhouse-client reads it out of ClickHouse Cloud over the native protocol, and the HTTP interface on the Layerbase side accepts it straight into an INSERT:

SRC='--host abc123.us-east-1.aws.clickhouse.cloud --secure --user default --password ...'
DST='https://<host>.cloud.layerbase.dev'

clickhouse-client $SRC --query "SELECT * FROM events FORMAT Native" \
  | curl -sS -u layerbase:<password> \
      "$DST/?query=INSERT%20INTO%20events%20FORMAT%20Native" \
      --data-binary @-

Run it once per table, or loop over system.tables. For a few hundred million rows this is a coffee break, not an afternoon. The receiving half of that pipe, Native in over HTTPS, is the part that is ours, and I ran it with 200,000 rows of a table carrying NULLs, a low-cardinality column, and strings with NUL bytes: identical count() and sum(cityHash64(*)) on both sides. The sending half is the standard clickhouse-client invocation from ClickHouse's own docs; I have not run it against a Cloud service, so check the first table before you loop. If you would rather not pipe through your laptop, run the same thing from a small VM in the same region as the source.

3. Or go through object storage. BACKUP TABLE events TO S3(...) on the source and RESTORE TABLE events FROM S3(...) on the destination is the right path for a large table you want to move without holding a connection open for an hour.

4. Verify, then cut over. SELECT count(), sum(cityHash64(*)) FROM events on both sides is a cheap equality check. Point your writers at the new host, let the old service idle, and delete it once the dashboards have been right for a week.

Where ClickHouse Cloud still wins

I would not move a production analytics platform off ClickHouse Cloud reflexively, and there are several cases where staying is clearly correct.

ClickPipes. Managed ingestion from Kafka, Kinesis, S3, and Postgres CDC, with no code. We have nothing like it; you bring your own pipeline.

SharedMergeTree and auto-scaling. Storage and compute are separated, replicas scale out under load, and you never think about disks. Our pool is a fixed allocation you grow by hand.

Availability. Scale and above give you multiple replicas and a real SLA. A single ClickHouse in a shared pool is one process, and if you need it to survive a node failure without a page, that is a Scale-tier feature.

The big workloads. If your queries want 32 GiB of RAM, ClickHouse Cloud sells you 32 GiB of RAM. Our largest self-serve Dedicated preset is 16 GB.

Postgres CDC into ClickHouse. If the whole point of the system is transactions in Postgres and analytics in ClickHouse with a managed pipe between them, that is the product they built and we do not have the pipe.

The case for moving is specific: you have more ClickHouse services than production ones, most of them are idle, the data is in the tens of millions of rows rather than billions, or you are paying a $67 floor to run a dashboard.

FAQ

How much does ClickHouse Cloud cost per month?

As of 2026-09-06, Basic starts at $66.52 a month for one replica with 8 GiB of RAM and 2 vCPU, Scale starts at $499.38 for two replicas with auto-scaling, and Enterprise examples on the pricing page run from $2,669 to $9,713. Compute is metered per minute in 8 GiB increments and storage is billed on compressed size, so the real bill for a busy Basic service sits above the floor.

Does ClickHouse Cloud have a free tier?

No. There is a 30-day trial with credits, and Basic can idle to keep a quiet service near its floor, but there is no permanent free plan. On Layerbase, ClickHouse is a Pro-tier engine, so it is not free here either; the difference is that the Pro plan is a flat $15 rather than a metered floor of $67, and the plan covers nine other databases.

Is a $15 plan really comparable to ClickHouse Cloud Basic?

Not feature for feature. Basic gives you 8 GiB of dedicated RAM and can be paired with a replica on Scale; Pro gives you a 1.5 GB always-on pool shared with your other databases, growable with $10/month pool blocks. For a small analytics workload, a staging copy, or a side project, the pool is plenty. For a company's analytics platform, Basic is the honest recommendation.

Can I connect to Layerbase ClickHouse with clickhouse-client and my existing drivers?

With the official drivers, yes: Layerbase exposes ClickHouse's HTTP interface over HTTPS, which is what @clickhouse/client, clickhouse-connect, the Go and Java HTTP clients, Grafana, Metabase, and curl use, so they connect by changing the URL, user, and password. clickhouse-client itself speaks the native TCP protocol, which is not exposed, so use it against the source and curl or a driver against the destination. Nothing in the query layer is different; it is the same ClickHouse.

How do I move data out of ClickHouse Cloud?

Pipe it with clickhouse-client --query "SELECT * FROM t FORMAT Native" into an INSERT ... FORMAT Native POSTed to the destination HTTPS endpoint with curl, or BACKUP to S3 and RESTORE on the other side. Recreate the schema first, swapping SharedMergeTree for MergeTree.

What does ClickHouse Cloud have that Layerbase does not?

ClickPipes managed ingestion, SharedMergeTree with separated storage and compute, auto-scaling, multi-replica availability with an SLA, RAM sizes above 16 GB, and the managed Postgres with CDC into ClickHouse. If any of those is why you are there, stay.

The wrap-up

ClickHouse Cloud is the reference way to run ClickHouse at scale, and Basic at $66.52 is a fair floor for a service that earns it. The trouble is that most teams have several ClickHouse services and only one of them earns it.

If your ClickHouse is your analytics platform, stay. If it is the staging copy, the CI copy, or the side project that outgrew Postgres aggregations, create a ClickHouse on Layerbase Cloud, pipe a table across in Native format, and see whether the floor was doing anything for you.