hypequery vs Metabase for Embedded ClickHouse Analytics

Short answer: if you want a chart in front of people this week, Metabase is the faster path — it's a mature BI tool with a native ClickHouse connector and real embedding features. If you're building customer-facing product analytics that ships inside your app, with type-safe queries, per-tenant rules enforced in your own auth stack, and a UI that matches your product, that's code-first territory, and hypequery is built for it.

These aren't the same category, and pretending they are does nobody any favors. Metabase is a BI application. hypequery is a TypeScript library you point at the ClickHouse you already run. This page is about which shape fits the job, not a feature war.

What Metabase does well

Metabase is genuinely good, and for a large set of analytics jobs it's the right answer.

• Fast time-to-chart. Connect ClickHouse via the official connector, build a "question" in the UI, and you have a dashboard. No code, no deploy, no schema generation step.
• Non-engineers can self-serve. Analysts, PMs, and support staff can slice data, save questions, and build dashboards without waiting on the eng team. That's the whole point of a BI tool, and it's a real capability hypequery does not have.
• Embedding exists. Static iframe embeds are free. Interactive embedding — with SSO and row-level sandboxing so each customer sees only their data — is available on paid tiers, along with an embedding SDK for more control over the frame.
• Batteries included. Alerts, scheduled emails, a permissions model, a query editor with a visual and SQL mode. You don't build any of this.

If the job is "put an internal revenue dashboard in front of the leadership team," or "let ops explore event data without writing SQL," Metabase wins on almost every axis. Reaching for a library there would be over-engineering.

Where the BI-embed model gets expensive

The friction shows up when the dashboard is your product, shipped to your customers, rather than an internal tool.

The UI is Metabase's, not yours. Embedded Metabase looks like embedded Metabase. You can theme it, and the SDK gives you more room, but you're styling someone else's charts inside a frame rather than composing your own React components. For a polished, customer-facing surface that has to match your product's design system, that ceiling gets real.

Per-tenant governance lives in Metabase. Interactive embedding with sandboxing does enforce row-level rules — but those rules live in the BI tool's permission model, configured separately from the authentication and authorization your application already has. For a multi-tenant SaaS product, that's a second source of truth for "who can see what," and it's a paid-tier feature. When your app already knows the tenant from the request, injecting that scope in your own code is often simpler and easier to audit.

Queries aren't code. Questions authored in the Metabase UI don't live in your repo, don't go through code review, and aren't covered by your CI. There are no compile-time types tying a chart to your ClickHouse schema, so a column rename surfaces as a broken dashboard at runtime rather than a type error at build time.

Pricing scales with embedding. The free tier covers internal use and static embeds. The moment you need interactive embedding, SSO, and sandboxing for customer-facing analytics, you're on a paid plan — a line item that grows with the product.

None of these are bugs. They're the natural shape of a BI tool. They just point at a different set of jobs than product analytics.

What hypequery does instead

hypequery assumes you own the ClickHouse and you're building the analytics surface yourself, in TypeScript.

1. Run hypequery generate against your live ClickHouse. It introspects the schema and produces TypeScript types with correct runtime mappings — DateTime comes back as a string, UInt64 as a string, Nullable(T) as T | null.
2. Write queries with a fully typed builder. Runtime parameters — date ranges, tenant IDs, filters — are just function arguments.
3. Serve them as typed REST endpoints with input validation and generated OpenAPI docs via @hypequery/serve.
4. Build the dashboard from your own components, consuming the same typed contract through @hypequery/react hooks.

A tenant-scoped query looks like ordinary application code:

The tenant_id filter comes from your request context — the same auth you already trust for the rest of the app. There's no second permission system to keep in sync. And because the return type is generated from the real schema, renaming total in ClickHouse and re-running generate turns every stale query into a compile error, not a broken customer dashboard.

Serving it is a small step from there:

That endpoint is validated, documented, and consumed by typed React hooks in your own charts. The trade you're making: you build the UI and wire the auth, instead of getting them from a BI tool.

The honest comparison

How to actually decide

Is the audience internal? Metabase, almost every time. Self-serve exploration for non-engineers is exactly what it's for, and building that with a library would be wasted effort.

Is the dashboard a feature of your product, shipped to customers? This is hypequery's home turf. When the analytics surface has to match your design system, respect your existing auth, and ship through your normal review-and-deploy pipeline, owning it in code pays off. The ClickHouse dashboard guide walks through building one, and ClickHouse React covers the hooks side of the contract.

Do per-tenant rules already live in your app? If your backend already knows the tenant from the request, enforcing that scope in your own query code keeps one source of truth. Our write-up on multi-tenant embedded analytics covers the isolation patterns, and ClickHouse SaaS analytics covers the broader tenant story.

Do non-engineers need to build their own charts? Metabase — that's a job hypequery deliberately doesn't do.

Can you use both?

Yes, and it's a common, sensible split. Metabase for internal BI and ad-hoc exploration; hypequery for the customer-facing analytics baked into the product. Both point at the same ClickHouse, and they serve genuinely different audiences from it. Running both isn't redundant the way two application layers would be — one is for your team, one is for your users.

Getting started with hypequery

If the customer-facing, code-first side is the one you're weighing, the quick start takes you from schema introspection to a typed, served endpoint in a few minutes — enough to see whether owning the analytics layer in your repo fits how your team ships. From there, ClickHouse React shows the dashboard hooks, and the multi-tenant analytics write-up covers per-tenant governance in your own stack.