Layerbase vs Tinybird: managed ClickHouse without usage billing

Q: Is it hard to leave either one?

Leaving Layerbase is a clickhouse-client dump and restore, because your queries are ordinary ClickHouse SQL and portable to any ClickHouse anywhere. Leaving Tinybird is harder in proportion to how much you built on Pipes and Endpoints, since that API surface has no equivalent elsewhere and has to be rebuilt against whatever you move to.

Short version: Tinybird sells you a managed pipeline on top of ClickHouse (ingestion connectors, SQL Pipes, and an auto-generated REST API) billed by compute usage, and Layerbase sells you the ClickHouse instance itself on a flat monthly price with the API layer left to you. Pick Tinybird if you want that pipeline handed to you and would rather pay by usage than build and run it. Pick Layerbase if you already have a backend, want a native ClickHouse connection string with nothing proprietary between your code and your data, and want a bill that does not move when a dashboard gets popular.

If you are evaluating Tinybird, you are almost certainly building something that needs fast analytical queries over a lot of rows: product analytics, real-time dashboards, usage metering, leaderboards, or an API that has to aggregate millions of events and answer in milliseconds. That is ClickHouse territory, and Tinybird is one of the best-known ways to get ClickHouse without running it yourself.

So where does Layerbase fit? Both can serve the same workload, but they are not the same kind of product, and the answer to "which should I use" depends less on features than on how you want to be billed and how much of the pipeline you want owned for you.

They are not the same shape

This is the part most comparison posts skip, so let us be direct about it.

Tinybird is an opinionated real-time analytics platform built on ClickHouse. You do not get a raw ClickHouse endpoint to point your BI tool at. You ingest into Data Sources, transform with chained SQL "Pipes", and publish those pipes as token-authenticated REST API Endpoints. The current iteration, Tinybird Forward, keeps that model and adds typed SDKs plus a tb CLI with a local dev container. The value is the whole managed pipeline: ingestion connectors, the query layer, and an instant API in front of it, with observability on top.

Layerbase gives you managed ClickHouse itself. You get a real ClickHouse instance with a native wire-protocol connection string and a TLS endpoint. You connect the ClickHouse client, clickhouse-connect, your BI tool, or anything that speaks the protocol. There is no Pipes abstraction and no auto-generated API layer. If you want an HTTP API in front of your queries, you build it, the same way you would in front of any database.

That difference is the whole decision. Tinybird sells you a pipeline. Layerbase sells you the engine and gets out of the way.

At a glance

	Tinybird	Layerbase Cloud
What you get	A managed real-time analytics platform on ClickHouse	A managed ClickHouse instance
How you query it	SQL Pipes published as token-authenticated REST endpoints	Native ClickHouse wire protocol over TLS, your own client
API layer	Auto-generated, with auth and rate limiting	You build it, or query from your backend
Ingestion	Managed connectors for Kafka, S3, GCS, DynamoDB, plus an HTTP Events API	ClickHouse's own tools: `INSERT`, the HTTP interface, materialized views, `s3()` and `url()`
Billing shape	Usage-based, metered on vCPU time plus storage per GB	Flat monthly, nothing metered per query or scan
Free tier	Yes, no card: 0.25 vCPU, 1k API requests a day, 10 GB storage	Yes, but ClickHouse is a Performance engine and is not on it
First paid price	Developer, $49/mo	Pro plan: $15/mo, plus $10/mo pool blocks for more always-on capacity
Branching	No equivalent	Copy-on-write branch of a running ClickHouse in seconds
Other engines	ClickHouse only	Postgres, Redis and the rest of an 18-engine catalog on the same login
Leaving	Rewrite the API layer you built on Pipes	`clickhouse-client` dump and restore

The pricing wedge

Tinybird's pricing is usage-based, and the meter these days is compute: your queries and ingestion burn vCPU time, bursts beyond your plan's base vCPUs are billed per vCPU-second, and storage is billed per GB on top (current pricing). The free tier is real and needs no card: 0.25 vCPU, a thousand API requests a day, 10 GB of storage. The first paid plan, Developer, is $49 a month. The downside of the metered model is the one every usage-billed analytics product shares: the bill scales with the exact thing a successful analytics product does more of. A dashboard that a lot of people load, or an endpoint that fans out across a large table, burns compute, and compute is the meter, so the bill moves with your traffic and is not easy to predict the month before it lands.

Layerbase is flat. ClickHouse is one of our Performance engines, which live on the Pro plan: $15/mo, up to 10 databases across the whole cloud engine catalog, and $10/mo pool blocks if you need more always-on capacity. There is no per-query charge, no vCPU-second meter, and no line item that grows because a query got popular. You size the instance, you pay the monthly price, and a viral dashboard changes your latency budget, not your invoice. Against a $49 entry point for Tinybird's first paid plan, flat $15 for the engine underneath it is a real gap.

Tinybird rates and free-tier limits verified 2026-08-25 from tinybird.co/pricing.

This is the same reason people move to Layerbase from any metered database, and I have run the fuller version of that math before: a predictable bill you can put in a budget beats a variable one you reconcile after the fact.

What you give up by choosing Layerbase

An honest comparison has to say this plainly, because for some teams it is disqualifying.

No managed ingestion connectors. Tinybird ships managed connectors for Kafka, S3, Google Cloud Storage, and DynamoDB, plus an HTTP Events API for streaming JSON in (warehouse sources like BigQuery and Snowflake flow through object storage staging). On Layerbase you load ClickHouse yourself, with the tools ClickHouse already has (INSERT, the HTTP interface, clickhouse-client, materialized views, table functions like s3() and url()).
No auto-generated API layer. Tinybird's headline feature is turning a SQL pipe into a production HTTP endpoint with auth and rate limiting in one step. Layerbase does not do that. You put your own API in front, or query ClickHouse directly from your backend.

If your team wants the managed pipeline and does not want to build or operate the API and ingestion layer, that is a real reason to pay Tinybird for it. Buying that pipeline is a legitimate choice.

What you gain

Real ClickHouse, not an abstraction over it. A native connection string means no proprietary API surface to design around and nothing to rewrite if you leave. Your queries are ClickHouse SQL, portable to any ClickHouse anywhere.
A bill you can predict. Flat monthly, no usage meter on queries or scans.
One account for everything else. ClickHouse for analytics sits next to Postgres, Redis, and the rest of an 18-engine catalog on the same login and the same predictable bill, so the operational-analytics half of your stack and the transactional half live in one place.
Copy-on-write branching, on ClickHouse itself. Fork a running ClickHouse into an isolated copy with its own connection string in seconds, rehearse a schema change or a backfill against real data, then throw the branch away. On branch-ready storage the fork shares blocks with its parent, so a branch of a large table costs only what you change. Tinybird has no equivalent, and until recently neither did we for this engine.
No lock-in. Because you hold a standard ClickHouse endpoint, moving on is a clickhouse-client dump and restore, not a rewrite of an API layer.

When Tinybird is still the right call

Use Tinybird when the pipeline is the point: you want managed ingestion, SQL-to-endpoint APIs, and analytics observability handed to you, and you would rather pay by usage than build and run that layer. A workload that fits inside the free tier's caps is genuinely free, and free beats any flat plan. Just know where the cliff is: the moment you outgrow those caps, the first paid dollar is $49 a month.

When Layerbase is the right call

Choose Layerbase when you want ClickHouse the engine, a flat and predictable bill, and no proprietary layer between your code and your data, and you are comfortable owning the API and ingestion yourself (which, if you have a backend already, you mostly do). It is also the obvious pick when ClickHouse is one engine in a larger stack you would rather run on one account than spread across a database provider plus a separate analytics vendor.

FAQ

Is Tinybird just managed ClickHouse?

No, and that is the most common misunderstanding about it. ClickHouse is the engine underneath, but what you buy is the pipeline around it: you ingest into Data Sources, transform with chained SQL Pipes, and publish those Pipes as token-authenticated REST endpoints. You do not get a raw ClickHouse endpoint to point a BI tool at. Layerbase is the thing people often assume Tinybird is.

How much does Tinybird cost?

The free tier is real and needs no card: 0.25 vCPU, a thousand API requests a day, and 10 GB of included storage. The first paid plan, Developer, is $49 a month for 0.5 vCPU, unlimited daily requests, and 25 GB. Past that the meter is compute, so bursts beyond your plan's base vCPUs bill per vCPU-second with storage per GB on top, and SaaS and Enterprise are quoted rather than listed.

What is the cheapest way to run managed ClickHouse?

On Layerbase, ClickHouse is a Performance engine and lives on the Pro plan at $15/mo, which also covers up to 10 databases across the rest of the cloud catalog. Nothing is metered per query or per scan, so the number does not move when a dashboard gets popular; if you need more always-on capacity you add $10/mo pool blocks. If your workload genuinely fits inside Tinybird's free tier, though, free beats any flat plan.

Can I use my own BI tool or ClickHouse client?

On Layerbase, yes, because you hold a real ClickHouse connection string over TLS. Anything that speaks the protocol works: clickhouse-client, clickhouse-connect, Metabase, Grafana, whatever you already run. On Tinybird the access path is the API endpoints you publish, which is the point of the product but does mean your tooling talks to Tinybird rather than to ClickHouse.

What do I give up by choosing Layerbase over Tinybird?

Two concrete things. There are no managed ingestion connectors, so loading data is on you with ClickHouse's own tooling. And there is no auto-generated API layer, so turning a query into a production HTTP endpoint with auth and rate limiting is work you do rather than a button you press. If you do not already have a backend to put in front of it, those are real reasons to pay Tinybird.

Is it hard to leave either one?

Leaving Layerbase is a clickhouse-client dump and restore, because your queries are ordinary ClickHouse SQL and portable to any ClickHouse anywhere. Leaving Tinybird is harder in proportion to how much you built on Pipes and Endpoints, since that API surface has no equivalent elsewhere and has to be rebuilt against whatever you move to.

Trying it

You can create a managed ClickHouse database on Layerbase, get a connection string, and point clickhouse-client at it. Provisioning takes a minute or two; ClickHouse is a large binary. If it fits, it stays $15/mo on Pro no matter how many dashboards hit it. If it does not, you leave with a standard ClickHouse dump and owe nothing to a proprietary format.

That is the whole pitch: the same engine Tinybird is built on, priced so success does not surprise you, with the pipeline left in your hands instead of theirs.