Metabase Cloud

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the reporting I actually need instead of hosted Metabase — and note it is open source, so self-hosting the original is a real answer rather than a rewrite.

The reason to build something smaller is that a general query builder over a production database is a standing risk, and most companies need six numbers rather than a tool for inventing new ones.

STACK
- Node 20+ with Fastify, server-rendered HTML
- Your existing database through a read-only connection
- SQLite through better-sqlite3 for this tool's own state
- Charts as inline SVG drawn by hand. No charting library
- Caddy in front, behind whatever the company already uses for staff access

THE SHAPE THAT IS SAFE
- **Queries live in files, parameterised, reviewed like code.** Not a box where anybody types SQL against production
- Each one has a name, a description, its parameters, and the role that may run it
- A dashboard is a list of queries with a layout. Adding one is a small pull request, and that review is a feature rather than friction
- Non-technical people choose parameters and date ranges, not tables

QUERY SAFETY, WHICH IS NOT NEGOTIABLE
- **A read-only connection**, or a replica. A reporting tool should be incapable of writing, not merely disinclined
- A statement timeout on everything and a row cap on every result. One unbounded query on a large table takes production down and the reporting with it
- Every query parameterised. Never string-built, and never a value from a form reaching the database as text
- Results cached with a short lifetime, so twenty people opening the same dashboard is one query

THE DEFINITIONS, WHICH ARE THE REAL PRODUCT
- Every metric defined once, in a file, with its SQL, its unit, its owner and a sentence saying what it means
- Versioned and reviewed, so when 'active user' changes, the change has a date and an author
- A test per metric against a known dataset with a known answer, so a definition cannot drift silently
- **Recompute last quarter with today's definition.** If the number differs from what was reported at the time and nobody knows why, that is a definitions problem and no tool fixes it

WHAT TO SHOW
- Every number carries its definition and its window beside it, not in a tooltip
- A comparison against the previous period, always
- The row count and the query time on every result, so somebody can tell a slow dashboard from a broken one
- Export to CSV, and **every export recorded with who and how many rows** — reporting is how data walks out of a company

SCHEDULES
- A query on a schedule, emailed or posted to chat, with the result inline rather than a link nobody follows
- An alert when a number crosses a threshold, throttled so a bad day sends one message

OPERATIONS
- .env: DATABASE_PATH, REPORTING_DATABASE_URL, BASE_URL, SESSION_SECRET, OIDC_*
- Migrations on boot, each once; nightly backup of this tool's own database
- Health endpoint touching both databases

WHAT MATTERS MOST
A read-only connection and definitions in files. The first means this can never damage production; the second means two people in a meeting are quoting the same number.