ReportsHQ compared with Metabase
Metabase is a service you run beside your application, with its own login and its own connection into production. This is a package inside it, reading the models you already have.
| What you are comparing | ReportsHQ | Metabase |
|---|---|---|
| Where it runs | A package inside your application. Nothing else to deploy. | A service beside it, with its own deployment and upgrades. |
| Your database connection | Queried in process through your own ORM. No new credential. | Needs credentials into production, to rotate and firewall. |
| Who can see what | The routes and middleware your application already has. | Its own users, groups and permissions to keep in step. |
| Ad hoc questions | Only what the compiler can express. It refuses the rest. | Any SQL you can write. This is where it wins outright. |
| Reports as code | A report lives in your repository and ships with the feature. | A dashboard built in a browser, reviewed by nobody. |
| Business rules | Reads the columns you declare, at the grain you declare. | Reads whole tables, so any column is one click away. |
| Sharing outside the team | A private link from your own domain, revocable and expiring. | A public link from a service you also keep running. |
| Cost shape | Per installed application. | Free to self-host, paid cloud tiers. |
Metabase is a service you run beside your application
It is a separate deployment with its own database, its own login, its own upgrades and its own connection into production. That separation is what makes it powerful: it will answer questions in SQL that no packaged tool can express, against any database you point it at, for anyone you give an account to.
This is a package inside the application
It installs as a package in the application, reads the models you already have, and renders through the routes you already guard. There is nothing else to deploy, nothing else to upgrade, and no second copy of who is allowed to see what. A report is code in your repository, reviewed in a pull request and deployed with everything else.
Your database connection stays where it is
Metabase needs credentials into production, which is a decision worth taking seriously and a thing to rotate, audit and firewall. This queries in process, on the database connection the application already holds, so there is no new connection, no new credential and no new host holding one.
Where Metabase wins
Anything ad hoc. A question nobody anticipated, a join across three schemas, a window function, an analyst who wants to explore rather than read. Metabase is a tool for asking; this is a tool for answering the same questions repeatedly and well.
Where this wins
Reports that ship with the feature they describe. The set of things a report can ask is an allowlist in your repository, so a column nobody meant to expose is not one click away, and a question the description cannot answer correctly is refused rather than answered approximately.
And for the people who are not staff
A share link serves one published report to somebody with no account and no database access, from your own domain. In Metabase that is a public link from a service you also have to keep running.
Most teams want both
Metabase for the question nobody saw coming, this for the fifteen reports everyone reads every week. They are not really the same tool, and the second one should not need a server.
Start free