Dashboarding Tools: Grafana, Metabase, Evidence on One Dataset

Dashboarding tools turn a database into charts that other people can read without writing SQL. On September 12, 2026, I built the same three charts from one Postgres database in Grafana 13.2, Metabase 0.63 and Evidence 0.9, all open source. All three drew the same numbers. What separates them is what you edit afterwards, JSON files, a click interface or a markdown page, and how much memory the server takes.

The result, and which one to pick

The three charts were monthly revenue from paid invoices, weekly signups by source, and active customers by plan. The data was a made-up SaaS, described below. Each tool got the same read-only database user and the same three SQL queries.

• Grafana 13.2.1 took three files and no clicks: a data source YAML, a provider YAML and a dashboard JSON, 54 lines in total. Healthy 8 seconds after launch, 314 MB of memory idle, a 1.0 GB install. The open-source build produced an external share link that an anonymous browser could load.
• Metabase 0.63.17 took no files. Most people click through it; I used its API instead: setup, add the database, three questions, one dashboard, five calls in 1.6 seconds. Healthy 9 to 11 seconds after launch, 1.5 GB of memory idle, a 643 MB JAR plus a 181 MB Java runtime. Public links are on by default and loaded anonymously.
• Evidence 0.9.3, the 2026 CLI version, took two files: a connection file and one markdown page, 35 lines. Dev server up 1.2 seconds after launch, 226 MB of memory, an 81 MB binary. A direct Postgres connection needs no account. Sharing means hosting it yourself behind basic auth, or the hosted plan at $2,500 a month.

The rule I would apply: pick by who edits the dashboard next. If that is you or a coding agent, and the dashboard should live in a repository, Grafana wins because every panel is a file. If it is someone who will never write SQL and wants to click on a bar to see what is behind it, Metabase wins, and you budget a machine with at least 2 GB free for it alone. If the dashboard is really a report, a page you write with charts between paragraphs, Evidence is the shortest path and the lightest server. If you want no server at all, Looker Studio, covered below, is the free option I did not test.

What I ran

The dataset is fictional. A script generated 999 signups over eighteen months with a source (organic, newsletter, LinkedIn, referral), 278 paying customers on three plans and 1,708 monthly invoices, then loaded them into a local Postgres 16 with a read-only role. No number on the charts says anything about a real business.

I used the standalone builds each project documents: Grafana's macOS tarball, Metabase's JAR on the Temurin 25 runtime its docs now require, and the Evidence CLI binary. Startup time runs from launch to the health endpoint answering; memory is the resident size at idle, on a Mac. Success meant two checks per tool: the query API returned the expected rows (12 months, 13 weeks across four sources, 3 plans), and a browser screenshot showed the charts drawn.

Not measured: daily use over weeks, several people editing at once, tables with millions of rows, or a database on the other side of the internet.

“

All three drew the same numbers; the difference is what you edit afterwards and how much memory the server takes.

”

Grafana: the dashboard is three files

Two of the three files are short. The data source, following the provisioning docs, with your own host, user and password:

apiVersion: 1
datasources:
  - name: SaaS Postgres
    uid: saas-pg
    type: postgres
    url: 127.0.0.1:5432
    user: reader
    secureJsonData:
      password: "readerpass"
    jsonData:
      database: saas
      sslmode: "disable"

And the provider that tells Grafana which folder holds the dashboard JSON:

apiVersion: 1
providers:
  - name: finn
    type: file
    allowUiUpdates: false
    options:
      path: /var/lib/grafana/dashboards

The third file is the dashboard itself: three panels, each with a raw SQL target. With allowUiUpdates off, the docs say Grafana "always overwrites the database dashboard with the one from the provisioning file", which is what you want when the file is the source of truth. That makes Grafana the natural pick when a coding agent maintains the dashboard: it edits JSON, and the test you would apply to a code host, can you take it elsewhere, passes by construction.

One trap I fell into: the dashboard's time picker showed "Last 1 year" and did nothing, because my SQL used fixed windows. Grafana only filters a SQL panel by the picker when the query uses its time macros, $__timeFilter(paid_at) in the WHERE clause. Add it from the start.

Sharing worked on the open-source build through "Share externally", formerly public dashboards; the docs list what those links cannot do, notably template variables. If you would rather run nothing, Grafana Cloud's free tier allows 3 active users, but your database then has to be reachable from their servers.

Metabase: the click tool that also has an API

Metabase is built to be clicked: connect a database, it scans the tables, you build questions in a visual editor or in SQL, then drop them on a dashboard. My five API calls are the same work in the interface, and the docs warn that "the API is subject to change", so treat scripts against it as a convenience.

The cost of that interface is memory. At idle, with three questions and one dashboard, the process held 1.5 GB, roughly five times Grafana and seven times Evidence in this run. Two more lines from the docs matter: the default setup with the embedded H2 application database "is not meant for production", so you give Metabase its own Postgres for its settings, and public links can be turned off under Admin if you do not want anyone with a URL to see revenue. If you prefer not to host it, Metabase Cloud starts at $100 a month with five users included.

Evidence: a markdown page with SQL in it

The whole dashboard is one page, and this is the first chart on it:

```sql monthly_revenue
select date_trunc('month', paid_at)::date as month, sum(amount) as revenue
from invoices
where paid_at >= date_trunc('month', current_date) - interval '11 months'
group by 1 order by 1
```

{% line_chart data="monthly_revenue" x="month" y="sum(revenue)" y_fmt="usd" title="Monthly revenue (paid invoices)" /%}

Two more SQL blocks and two bar_chart tags cover the rest. The syntax changed in 2026: components are now Markdoc tags, and the project scaffold itself warns that recent AI models "aren't trained on the new syntax", so run evidence validate before trusting a generated page. The Postgres direct connector queries your database live from your machine with no account. Publishing is the catch: the self-host path is a Docker image behind HTTP basic auth, and the hosted product starts at $2,500 a month. For one person, Evidence is a report generator you host yourself.

What I did not test

Looker Studio is Google's free option: its page says it is "available at no charge for creators and report viewers", with a Pro tier at $9 per user per project per month. It has a PostgreSQL connector, but your database must accept connections from Google's published IP ranges and each query is capped at 150,000 rows, which rules out a laptop. Power BI Pro is $14 per user per month, paid yearly. Tableau and Domo fill the rest of the ranking pages; they are built for teams that share the clicking, and I did not test them. A per-seat price makes sense once there are seats.

A dashboard of invoices and signups will not tell you what users do inside the product. That is product analytics, events rather than tables, which is why PostHog sits next to these tools rather than among them. The first event worth charting is the one that means a user got value, and it usually lives in the product, not in the invoices table.

Limits of this run

One person, one fictional dataset, one afternoon. The numbers are for an idle Mac; a server under load will differ. I did not test a hosted database with every chart crossing the internet, nor review how safely each tool exposes data behind a public link. And a chart that renders is not a chart that is right: on each tool, I compared the three plan counts against a plain select count(*) in psql before believing the picture, the same check that catches code that only looks finished.

The Monday version of this: write your three SQL queries first, in a file. Point Grafana at them if the file is the product, Metabase if someone else will explore, Evidence if the page is. Whichever you pick, the queries move with you.