Metabase eller Grafana? Dashboards på företagets egen data jämförda

Det korta svaret

Välj Metabase om de som ställer frågorna inte skriver SQL: frågebyggaren kopplade ihop kunder och ordrar av sig själv, och ett sälj- eller ekonomiteam kan svara på nya frågor utan att gå via dig. Välj Grafana om du redan kör den för dina servrar, tänker i tidsintervall och SQL, eller vill ha larm på din data varje minut. Den använde en fjärdedel av Metabases minne eller mindre, men varje diagram på affärsdatan var en SQL-fråga som vi skrev själva.

Det här testade vi

Vi installerade båda på samma nya Melonslab VC-P Alloy (2 vCPU, 8 GB) med Debian 13, den ena efter den andra, och följde våra guider Metabase med rootless Podman och Prometheus och Grafana steg för steg. Båda läste samma databas i PostgreSQL 18, uppsatt som i PostgreSQL-guiden, med var sin inloggning som bara kan läsa.

Databasen innehöll tolv månader av en påhittad svensk grossist, oktober 2025 till september 2026: 20 000 kunder, 275 000 ordrar och 265 000 fakturor, 64 MB totalt. I båda apparna byggde vi samma tre saker:

• intäkter per månad under året;
• en tabell med de 20 kunder som gett mest intäkter, med stad och antal ordrar;
• en dashboard Orders med ett datumfilter, med de två och fyra diagram till: totala intäkter, ordrar per status, intäkter per stad och ordrar per vecka.

Båda gav samma siffror på öret, för hela året och för bara mars 2026. Sedan jämförde vi delning, behörigheter och larm, tog tid på samma frågor i båda, körde säkerhetskopieringen och återställningen från varje guide och mätte minnet efter en omstart.

Siffrorna

Minnet är appens containrar, mätt med podman stats fem minuter efter en omstart, när vi hade öppnat varje dashboard en gång. Den gemensamma PostgreSQL använde omkring 165 MB till, för båda.

Installation

Båda guiderna fungerade som de stod skrivna. Metabase-guiden ansluter din databas i steg 7, med inloggningen från steg 1 som bara kan läsa. Vår Grafana-guide är skriven för att övervaka servrar, så en affärsdatabas är ett tillägg. Vi skapade inloggningen grafana_ro precis som metabase_ro i steg 1 i Metabase-guiden, och sparade dess lösenord som en hemlighet, som monitoring:

printf %s 'the-grafana_ro-password' | podman secret create grafana-shop-password -

Sedan tre tillägg i Grafana-guidens filer. I monitoring.pod, under PublishPort=, raden från Metabase-guiden som låter podden nå PostgreSQL på serverns 127.0.0.1 via 169.254.1.3:

Network=pasta:--map-host-loopback,169.254.1.3

I grafana.container, under den andra raden Secret=:

Secret=grafana-shop-password

Och sist i ~/monitoring/datasources.yml:

  - name: Shop
    type: grafana-postgresql-datasource
    uid: shop
    url: 169.254.1.3:5432
    user: grafana_ro
    jsonData:
      database: appdb
      sslmode: disable
      postgresVersion: 1500
    secureJsonData:
      password: $__file{/run/secrets/grafana-shop-password}

Efter systemctl --user daemon-reload och systemctl --user restart monitoring-pod svarade datakällan Database Connection OK, och Prometheus nådde fortfarande node_exporter. Vill du bara använda Grafana för affärsdata behöver du varken Prometheus, Alertmanager eller node_exporter.

Så byggde vi dashboards

Här ligger den verkliga skillnaden.

I Metabase var alla sex diagrammen frågor i frågebyggaren: välj tabellen Orders, Sum of Total, grupperat på Created At: Month, filtrerat på att Status är paid. För de största kunderna grupperade vi på kundens namn och stad, som Metabase erbjöd direkt från tabellen Orders eftersom den hade läst främmande nyckeln till customers. Den skrev kopplingen själv. Dashboardens filter Date kopplas till Created At i varje kort, och tar ett intervall, en månad eller till exempel de senaste 30 dagarna. En användare som inte får skriva SQL kan ändå bygga nya frågor på det här sättet: vi satte All Users till Query builder only, som Metabase-guiden visar, och en sådan användare kunde gruppera kunderna per segment men fick SQL nekad.

I Grafana var varje panel en SQL-fråga. PostgreSQL-editorn har ett läge Builder, men det arbetar med en tabell i taget, så de största kunderna, som kräver en koppling mellan tabeller, blir SQL hur som helst. Datumfiltret är Grafanas tidsväljare, som varje dashboard har, men den filtrerar bara en panel vars SQL använder makrot $__timeFilter(created_at), så du lägger till det i varje fråga. Två saker överraskade oss:

• Veckor med $__timeGroup(created_at, 1w) började på torsdagar, eftersom Grafana räknar veckor från 1 januari 1970, en torsdag. Metabases veckor började på söndagar, och det kan du ändra under Localization. I Grafana ger date_trunc('week', created_at) i din SQL veckor som börjar på måndag.
• Intäkter per månad som staplar med en etikett per månad krävde månaden som text, to_char(date_trunc('month', created_at), 'YYYY-MM'). Som tidsserie ritar Grafana den på en löpande tidsaxel.

När panelerna väl är skrivna har Grafana fler inställningar än Metabases diagram, till exempel tröskelvärden, enheter och inställningar per fält. Metabase är å andra sidan byggd för att du ska klicka dig från ett diagram vidare till raderna bakom, vilket Grafana inte är. Det testade vi inte för hand.

Fart

Båda skickar SQL till samma PostgreSQL, så databasen gör det mesta av jobbet. Vi körde var och en av de sex frågorna sju gånger över hela året, via varje apps eget API, och tog medianen:

Metabase tog omkring 0,1 till 0,4 sekunder längre på varje fråga. Ingen av dem kändes långsam. På en större databas spelar ett index eller en summerad tabell mycket större roll än valet av app.

Delning och inbäddning

Båda gav en publik länk som öppnades utan inloggning, och båda behöll ett filter på den: Metabases publika dashboard tog filtret Date, och Grafanas delade dashboard lät besökarna ändra tidsintervallet när vi hade valt Enable time range. Grafanas delade dashboards stöder inte variabler, enligt dess dokumentation. Gör bara dashboards publika om de inte innehåller något privat: alla som har länken ser dem.

Metabases öppna utgåva kan också bädda in en dashboard på din egen webbplats eller kundportal med en signerad länk, som Metabase numera kallar guest embeds. Vi bäddade in dashboarden Orders på det sättet. Enligt Metabases dokumentation visar sådana inbäddningar en banner med "Powered by Metabase" i den fria utgåvan, och går inte att klicka sig vidare i. För att ta bort bannern, och för inbäddningar där användarna loggar in, krävs Pro. Inbäddning av Grafana på en annan webbplats testade vi inte.

Behörigheter

Metabase har grupper, och för varje databas väljer du om en grupp får använda frågebyggaren, skriva SQL eller ingetdera, och vilka samlingar av frågor den får se. Att dölja rader eller kolumner per användare, så att varje säljare bara ser sina egna kunder, kräver Pro.

Grafana har rollerna Viewer, Editor och Admin, och behörigheter på mappar och dashboards. Men i Grafanas öppna utgåva kan varje inloggad användare skicka vilken fråga som helst till vilken datakälla som helst, oavsett vilka dashboards de får se. Vi kontrollerade det: en användare med bara rollen Viewer läste kundernas e-postadresser med en SQL-fråga via Grafanas API. Grafanas dokumentation säger samma sak, och att behörigheter på datakällor kräver Grafana Enterprise eller Cloud. I Grafana är alltså databasinloggningen din verkliga behörighet: ge grafana_ro bara de tabeller eller vyer som alla Grafana-användare får se, i stället för SELECT ON ALL TABLES som i steg 1.

I båda höll inloggningen som bara kan läsa: en DELETE stoppades med cannot execute DELETE in a read-only transaction.

Larm

Båda skickade ett larm om vår data till en webhook för test, utan att e-post var uppsatt.

• Metabase larmar på en sparad fråga: när den ger resultat, eller när ett värde går över eller under ett mål, kontrollerat enligt ett schema, till exempel varje timme eller varje morgon. Larmet hade frågans diagram med som bild. Det kan också skickas via e-post eller Slack. Metabase vägrade en webhook-adress på 169.254.1.3 eftersom den räknas som intern, så peka den mot en riktig adress utanför podden.
• Grafana kontrollerar larmregler varje minut: vår regel, "betalda intäkter under 1 000 det senaste dygnet", utlöstes inom en minut och skickade värdena med. Den har många fler kanaler, och tystnad, gruppering och upprepning, som du väntar dig av ett övervakningsverktyg.

Metabase kan också mejla en dashboard till en lista med personer enligt ett schema, som den kallar subscriptions. Grafanas dokumentation beskriver schemalagda PDF-rapporter för Grafana Enterprise och Cloud.

Resurser

Metabase körs i Java och tog 1,6 GB efter en omstart. Java låter den växa till en fjärdedel av serverns minne, 2 GB här, så ge den en server med minst 4 GB. Grafana är ett Go-program och använde 260 till 390 MB. Grafana sparar sina dashboards i en liten SQLite-databas i sin volym, Metabase i en egen PostgreSQL.

Metabase tog mer disk än sina 1,39 GB avbilder: varje gång den startar kopierar containern Metabases programfil på 0,69 GB, eftersom avbilden byter ägare på den. Utrymmet frigörs och tas igen vid varje omstart, så räkna med omkring 2,2 GB.

Uppdateringar och säkerhetskopior

Metabase-guiden följer taggen v0.64.x, så podman-auto-update.timer installerar Metabases rättningar för 0.64 av sig själv: när vi testade var den redan på 0.64.2.2, en nyare rättning än guidens 0.64.2.1. En ny version som 0.65 ändrar dess databas, så den byter du till för hand efter en säkerhetskopia. Grafana-guiden följer latest, som också tar in nya huvudversioner av sig själv. Använd en tagg som 13.2 om du vill bestämma när de kommer.

Metabases säkerhetskopia är en pg_dump som körs medan den arbetar, plus krypteringsnyckeln för de sparade databaslösenorden. Grafanas säkerhetskopiering stoppar den en kort stund för att kopiera dess volym. Vi återställde båda till tomma volymer och fick tillbaka våra dashboards och frågor, och båda startade av sig själva efter en omstart. Din affärsdata finns inte i någon av dem: den ligger kvar i din egen databas, som PostgreSQL-guiden säkerhetskopierar.

Språk

Båda finns på svenska. I Metabase väljer du Admin > Settings > Localization för alla, eller Language i dina kontoinställningar. I Grafana väljer du svenska under Language i din profil, eller för alla i standardinställningarna under Administration. Namnen på tabeller och kolumner står kvar som i din databas i båda.

Licens och kostnad

Vi kontrollerade projektens egna sidor den 14 oktober 2026.

• Metabase är öppen källkod under AGPL 3.0 och görs av Metabase, Inc. i San Francisco. Att köra den öppna utgåvan själv är gratis, för hur många användare som helst. Starter kostar 100 US-dollar i månaden för fem användare, och Pro 575 US-dollar i månaden för tio användare plus 12 dollar för varje ytterligare. Pro lägger till single sign-on, behörigheter på rader och kolumner, inställningar för cache, granskning av användningen och inbäddningar utan Metabases banner. Enterprise börjar på 20 000 dollar om året.
• Grafana är öppen källkod under AGPL 3.0 och görs av Grafana Labs i New York. Att köra den själv är gratis. Grafana Enterprise lägger bland annat till behörigheter på datakällor och rapporter, från 25 000 dollar om året. Grafana Cloud är gratis för tre användare, och nivån Pro kostar 19 dollar i månaden plus 8 dollar för varje ytterligare användare.

Båda de öppna utgåvorna klarade allt vi testade utan licens. Båda skickar användningsdata och letar efter uppdateringar som standard. Varje guide visar hur du stänger av det.

Vilken ska du välja

Metabase passar ett team som vill ha svar ur företagets data utan att behöva en utvecklare för varje ny fråga: försäljning per region, största kunderna, obetalda fakturor, allt byggt genom att klicka, med prenumerationer via e-post och inbäddning i din egen portal. Dess svagheter är minnet, 1,6 GB Java, disken som containern tar vid varje start, larm som går enligt schema i stället för varje minut, och behörigheter på radnivå som kostar pengar. Följ Metabase-guiden. Den går gott och väl på en VC-P Alloy, bredvid PostgreSQL.

Grafana passar dig om dina dashboards mest handlar om tid: ordrar per timme, registreringar i dag mot förra veckan, larm samma minut som något sjunker, bredvid servergraferna som du kanske redan har. Dess svagheter för affärsfrågor är att varje diagram är SQL som du skriver, att den inte kan begränsa vilken data en inloggad användare kan fråga efter, och att den inte är byggd för att klicka sig vidare till raderna bakom ett diagram. Följ guiden för Prometheus och Grafana med datakällan ovan. Grafana ensam klarar sig på en mindre server, och hela guiden på en VC-P Alloy.

Båda tillsammans, med den gemensamma PostgreSQL, använde omkring 2,7 GB av serverns 8 GB, så en VC-P Alloy kör dem sida vid sida, som på vår testserver.