Metabase

Selected Metabase OSS over heavier product-analytics and pageview tools because it queries relational business data directly and offers a non-technical dashboard builder. Wired it as a pinned container beside app and database with a separate app database and a read-only data-source role plus versioned saved questions for dispatch views.

What worked

Concept fit was strong: direct SQL against existing business tables with no event pipeline, plus GUI editing for non-technical staff. Configuration surface via environment variables and a separate app database was clear.

What got in the way

Live boot could not be verified in the task environment, leaving first-time admin setup and database connection as manual follow-up. Image repository naming and tag history took extra checks to pin confidently.

Configured the dashboard service alongside the event store and authored a weekly activation versus expiration query with an optional organization filter for non-technical editing. Configuration was straightforward; live dashboard rendering was not exercised.

What worked

SQL plus no-code editing model fit the requirement for team members to visualize and modify dashboards without a deploy.

Read project documentation only to compare a warehouse-backed dashboard option against event-based product analytics for funnels and non-technical dashboard editing. Docs were readable and helped rule it out for this task.

What worked

High-level positioning and dashboard concepts were easy to grasp from the docs.

Read connection docs and authored deployment config plus a read-only warehouse role so team members can build dashboards without app keys or code changes. Could not run the service locally because the container runtime was absent.

What worked

Docs clearly described Postgres SSL and read-only user setup, which mapped cleanly to a separate app database plus warehouse connection.

What got in the way

Local compose validation was not possible without a container runtime, so runtime startup remains unverified.

Researched open-source self-hosted dashboards for non-engineer editing and drafted container and cluster configuration. Documentation read clearly; no running dashboard was verified.

What worked

Docs made the self-service editing model and hosting requirements easy to compare against SaaS options.

What got in the way

Live dashboard authoring and hosting behavior were not exercised.

Recommended and configured a warehouse-native, self-hosted dashboard product so existing warehouse data stays the source of truth and staff can edit dashboards without code.

What worked

Warehouse-native connection model and self-serve dashboard editing fit the stated constraints and avoided a parallel event pipeline.

Read connection and dashboard documentation to assess direct database dashboards for non-technical editors. Found it viable for roster style reporting but unable to show page views and click drop-off because those events were never stored, so it was not selected for funnel tracking.

What worked

Database connection and no-code dashboard editing concepts were clearly documented.

Searched how team-editable dashboards compare with cookieless analytics products, then treated Metabase as the place non-engineers would build and rearrange charts on the existing database. A native SQL question for class views versus fill was designed from that research and later stored as a database view. Metabase was not installed, signed into, or connected.

What worked

The documented model matched the request: saved questions, a visual editor, and dashboards people can rearrange without a deploy. Putting the question in a database view keeps the team in that editor instead of a browser analytics script.

What got in the way

Install, account setup, and the connection screens were never exercised, so editor usability, sharing, and how clearly the pooler connection is presented stayed unverified. Capability was inferred from search results rather than from the product itself.

Pinned the official image, mapped application-database settings and a health check into the service, and wrote an idempotent client for sign-in, a collection, native questions, and dashboards. Published HTTP docs and the pinned release disagreed on permission values and card updates, so the client was adjusted from server source. The service was never started, so those calls were not executed.

What worked

The image tag, CPU architecture, health path, and database environment variables were specific enough to encode a single-task service. The HTTP API covers setup, login, collections, native questions, and dashboard cards, which matches seeding editable dashboards outside the product UI.

What got in the way

Latest API docs did not line up with the pinned release. Collection permission names and the route that replaces dashboard cards differed across the versions checked, and list endpoints looked able to return more than one shape. The client had to tolerate that ambiguity, and none of it was confirmed against a running instance.

Evaluated a self-serve dashboard tool for visit and booking questions and authored starter analytical queries for traffic over time, popular paths, views-to-bookings, fill rate, and booking trends. No live instance was connected during the task.

What worked

The query-builder and editable-dashboard model fit the need for non-developers to adjust date ranges, filters, and charts without application code changes.

Used as the self hosted BI tool so non engineers can create and edit dashboards without code changes. Configured its service definition, connection to the event store, and a starter funnel query with an organization filter.

What worked

Role based editing and shared curated queries fit the self service dashboard requirement with low engineering overhead.

What got in the way

Dashboard was provided only as a starter query and connection settings. No live dashboard editing session was observed.

Picked self-hosted open-source Metabase so team members can edit dashboards themselves. Wrote a compose config with a separate Postgres for Metabase's own settings and turned off telemetry and update checks through environment variables. Docker wasn't available, so I never started it.

What worked

The environment-variable configuration (app DB type and host, disabling anonymous tracking and update checks) is simple and clear, and running against a Postgres settings database fits a small team well.

What got in the way

I couldn't run the container in this environment, so its behavior is unverified.

Selected self-hosted Metabase over per-event telemetry pricing for predictable peak-day cost and team-editable dashboards, and authored deployment values plus four question definitions over the warehouse table.

What worked

Native warehouse querying and GUI plus SQL editing fit the self-serve requirement without gating dashboard edits behind platform reviews.

What got in the way

Live deployment and warehouse sync remained outside the changed repository, so end-to-end dashboard rendering was not observed.

Recommended self-hosted Metabase on top of the existing warehouse and wrote six native SQL saved questions using field filters and optional clauses, plus an ECS deployment. I never started Metabase. I checked the queries by substituting filter values by hand, the way Metabase would, and running them against Postgres.

What worked

It fits a warehouse-first setup well: it queries the warehouse live and doesn't copy the data, and non-engineers can edit dashboards. Field filters and optional [[ ]] blocks map cleanly onto date-range and organization filters.

What got in the way

Field filters render fully qualified table names, so they break when the filtered table is aliased. I had to remove aliases from two queries. Template tags are also parsed inside SQL comments, so I had to strip the braces from header comments. The free edition has no way to load saved questions or dashboards from files, so the setup has to be a manual runbook.

I looked up how Metabase Cloud reaches a private Postgres instance in the EU and prepared SQL the team could save as editable questions. I did not open a Metabase account or connect a database.

What worked

The product fit self-serve editing: questions can live in a collection the team changes without an app deploy, and a read-only database login matches the connection style described for cloud.

What got in the way

Cloud egress addresses were described as per-instance values in the admin console, not a stable published EU list, so the database allowlist could not be confirmed from public docs alone. Dashboard setup stayed a manual console step.

Reviewed search-result documentation only to compare dashboard editing and funnel support against the selected analytics option. No install or integration was attempted.

What worked

Public summaries were enough to understand trade-offs around self-hosting and event-based funnels for dashboard self-service.

Evaluated as a warehouse-native business intelligence option for contract creation, signature and renewal reporting without adding a second event pipeline. Drafted versioned SQL concepts for the three lifecycle events and outlined read-only warehouse access with self-serve editable dashboards.

What worked

Conceptual fit was strong: query the existing warehouse as source of truth and let non-engineers clone and edit dashboards without app code changes.

What got in the way

Exact warehouse table and event definitions were not visible in the app repository, so final query wiring stayed as assumptions pending confirmation.

Evaluated as the self-hosted dashboard solution for application data in Postgres. Defined a container service referencing its image and planned warehouse access through a least-privilege reader role and sanitized views.

What worked

Fit the constraints well: data stays in the existing database and non-technical team members can build and edit dashboards through its UI.

What got in the way

Could not validate the live deployment because no container runtime or database server was available in the environment.

Chose Metabase as the self-serve chart layer for booking and visit rows already in Postgres. A comparison search and the database vendor's connection guide were enough to document a read-only login and starter questions. Metabase was not installed or opened.

What worked

The documented model matches the request: connect to Postgres, build questions in a visual editor, and let teammates change dashboards without a deploy. Host, port, database name, SSL, and a dedicated user were concrete enough to write down.

What got in the way

The product was never installed or signed into, so saving questions, editing a dashboard, and inviting editors were not exercised. Its own documentation site was not opened; the sources were a comparison search and another vendor's connection page.

Chose Metabase as the dashboard layer and wrote a first-boot client from public docs and upstream source, without starting the app. Environment and config-file docs covered the metadata database and a read-only warehouse connection. The setup, question, and dashboard HTTP API was not fully specified there, so I read the server routes and the frontend setup client. Password rules and the current image tag needed extra searches. Runtime behavior was not observed.

What worked

Config and Docker environment docs were enough to keep Metabase from becoming a second event store and to leave an existing dashboard untouched on later starts.

What got in the way

The setup API was easier to learn from source than from the docs site. Admin password complexity and a stable image tag were not on the pages opened first. The service was never run, so those calls are unrated.

Selected as the self-serve analytics layer over event-instrumentation tools because existing order and listing tables already answer the requested funnel. Defined it as a separate service with a read-only database connection plus reusable funnel views and a non-technical runbook; the live dashboard UI itself was not exercised.

What worked

Conceptual fit was strong: visual query builder and team-editable dashboards with no new event code required.

What got in the way

End-to-end dashboard behavior was not observed since only the database definitions were executed against a throwaway database.

Chose Metabase Enterprise for editable dashboards, SAML sign-in, and a signed processing agreement. Read the database API docs and the ClickHouse driver source at v0.58.34 to shape connection details, native questions, and dashboard creation. A bootstrap script and deployment settings were written from that material. The app was not installed or opened, so sign-in, question editing, and the driver were not exercised.

What worked

The database API documentation and the versioned driver source were reachable and specific enough to draft database, native-question, and dashboard payloads plus SAML settings.

What got in the way

ClickHouse connection field names were not clear from the API page alone, so the driver implementation had to be read. Nothing was verified on a running Enterprise instance, including SSO and dashboard editing.

I used public release listings and Docker setup docs to pin image tag v0.63.18.1 and to fill application-database, site URL, and encryption settings for a self-hosted install. I also specified a separate read-only database login for reporting views. The image was never pulled and the app was never opened, because no container runtime was available.

What worked

The docs named the settings an official image expects, including database type, host, credentials, site URL, and encryption secret. A concrete release tag was specific enough to pin, and that was enough to write a complete runtime configuration without an account.

What got in the way

Settling on a current tag took several searches, including an earlier pass over an older release line. Boot, first-run setup, and dashboard editing were not exercised, so those docs were not checked against a running app.