Grafana with PostgreSQL

Grafana with a real database — for multi-user production.

Service #monitoring#dashboards#analytics#postgresql

Grafana paired with a dedicated PostgreSQL backend in one Pier stack. The PostgreSQL-backed deployment is what Grafana recommends for production — multi-user, HA-friendly, and avoids the SQLite write-lock issues that plague Grafana under load with multiple concurrent editors.

Deploy with Pier

1 Open the Pier dashboard and click Add service.
2 Pick Grafana with PostgreSQL from the template list.
3 Choose the version, set a service name, and Pier provisions the container, storage, and ports automatically.
4 Attach a domain if you want HTTPS. Traefik auto-provisions the Let's Encrypt certificate.

What is Grafana with PostgreSQL?

This template ships Grafana — the de-facto observability dashboard platform — wired to a dedicated PostgreSQL backend for its internal state (users, dashboards, organizations, alerts, annotations). Grafana documents PostgreSQL (or MySQL) as the recommended backend for any multi-user or production deployment; SQLite is fine only for single-admin homelab use.

The two services come up together in one Compose stack with the env vars already set so Grafana finds Postgres on the internal Docker network. No manual GF_DATABASE_* configuration. You log in and use Grafana exactly as you would the standalone template — the database backend is invisible.

How Pier deploys it

Pier uses the official grafana/grafana image and postgres:17-alpine for the backend. Grafana on port 3000 internally behind Traefik. PostgreSQL stays on the internal Docker network (not exposed). Each service has its own data volume — /var/lib/grafana for Grafana plugins and provisioning, /var/lib/postgresql/data for Postgres data.

Default admin user is admin with a Pier-generated password (shown on the service page). Change it on first login.

For HTTPS, attach a custom domain to the Grafana service in Pier — Traefik handles TLS termination and proxies to port 3000.

When NOT to use this template

If you’re a single user with a homelab and don’t expect concurrent editing, the standalone grafana template is simpler. If you already have a managed PostgreSQL (Pier or RDS or anywhere), use the standalone Grafana template and point it at the existing Postgres via env vars. For Grafana-as-a-service without ops overhead, Grafana Cloud’s free tier is worth considering. This template is the right answer for “I want production Grafana on my own VPS and I don’t want to wire two services together by hand.”

Key features

Production-ready persistence

Grafana's user database — dashboards, organizations, users, sessions, annotations — lives in PostgreSQL instead of SQLite. Handles concurrent writes cleanly.

Pre-wired env

Pier sets GF_DATABASE_TYPE=postgres, host/user/password env vars, and connection settings — Grafana boots straight into Postgres without manual provisioning.

Same Grafana UI

Dashboards, panels, alerting, plugins — identical to the SQLite Grafana. Only the backing store differs.

All Grafana plugins

Datasources (Prometheus, InfluxDB, ES, ClickHouse, MySQL, Postgres, Loki, Tempo, Mimir), panel plugins, app plugins — everything compatible.

Backup / restore via Postgres

pg_dump backs up the entire Grafana state. Restore is pg_restore on a fresh stack. Much easier than juggling Grafana SQLite + provisioning files.

Multi-org / team scale

Concurrent editing by many users on many dashboards works without write-lock contention.

Use cases

Multi-user analytics team

A handful or dozens of analysts editing dashboards concurrently. PostgreSQL avoids the SQLite write-lock errors that surface under team load.

HA / disaster-recovery scenarios

PG backups + standby replicas give you point-in-time recovery and warm-standby options that SQLite can't.

Large dashboard / annotation volume

Many thousands of dashboards and high-write annotation streams (e.g. CI alerts, deploy markers) — Postgres scales well past where SQLite degrades.

Centralized observability hub

One Grafana instance serving 100s of users across many teams — exactly the deployment Grafana recommends Postgres for.

Code examples

Postgres datasource (the same Grafana template's Postgres now serves as both backend AND a datasource) text

Configuration → Data sources → PostgreSQL
  Host: postgres:5432
  Database: grafana
  User: grafana
  Password: (from Pier env)
  TLS: disabled (internal Docker network)

Add an external Prometheus datasource text

Configuration → Data sources → Prometheus
  URL: https://prometheus.example.com
  Auth: Bearer Token or Basic

Export a dashboard as JSON bash

curl -H "Authorization: Bearer $API_KEY" \
  https://grafana.example.com/api/dashboards/uid/abc123 > dashboard.json

Provision dashboards via files (no UI clicks) yaml

# /etc/grafana/provisioning/dashboards/default.yaml
apiVersion: 1
providers:
  - name: default
    folder: ""
    type: file
    options:
      path: /var/lib/grafana/dashboards

How it compares

vs Grafana with SQLite (default standalone)	SQLite Grafana is simpler and fine for single-admin or small homelab use. Postgres-backed Grafana is required when multiple users edit concurrently, or for any HA setup.
vs Grafana Cloud	Grafana Cloud is hosted, includes free tier, autoscales. Self-host on Pier is free for data plane and gives you control. Choose by team budget and ops appetite.
vs Metabase / Superset	Metabase and Superset target BI analysts more than ops dashboards. Grafana is the default for ops/observability; the others for embedded analytics.

Frequently asked questions

What's wrong with SQLite Grafana?

Nothing for single-admin use. Under concurrent multi-user editing, Grafana's SQLite backend can throw "database locked" errors and dashboard corruption is harder to recover from. Postgres avoids both.

Can I migrate from SQLite Grafana to Postgres Grafana?

Yes — Grafana has migration scripts, or you can export dashboards as JSON, deploy this template, and re-import. The latter is usually simpler for small instances.

Does this PostgreSQL also serve as a datasource I can query?

Yes — add it as a PostgreSQL datasource pointing at the internal postgres:5432 service. Useful if you want to query Grafana's metadata (dashboards, users, etc.) via SQL.

How big can it scale?

Concurrent dashboard editors comfortably into the hundreds with a small Postgres instance. Annotation/event volume scales with Postgres performance.

Plugin compatibility?

All Grafana plugins work with Postgres-backed Grafana — the database backend is invisible to plugins.

Backup strategy?

pg_dump the grafana database — that's everything (dashboards, users, alerts, annotations). Restore is pg_restore on a fresh instance.

Can I share the Postgres with other services?

Discouraged in production. Grafana's database benefits from being isolated; share Postgres only if disk space is the binding constraint.

Related services

Deploy on your VPS

Deploy this service →