ADR-0009: Metabase OSS Self-Hosted on Railway¶
Status: Accepted Date: 2026-03-22 Session: --
Context¶
Curaway needs business intelligence dashboards to track key metrics: patient conversion funnels (register -> engage -> match -> consent), corridor volume (which specialties and geographies generate the most matches), LLM token costs per conversation, and document processing success rates. These dashboards serve the founding team for product decisions and will eventually serve provider partners.
The team already uses Grafana for system health monitoring (Railway resource usage, API latency, error rates), but Grafana is optimized for time-series infrastructure metrics, not business analytics with SQL queries over relational data.
Decision¶
Deploy Metabase OSS (open-source edition) as a self-hosted service on Railway, connecting directly to the production PostgreSQL database for analytics queries.
Rationale¶
- Zero recurring cost. Metabase OSS is free. Metabase Cloud starts at $85/month and scales with users. For a bootstrapped startup, eliminating a recurring SaaS cost matters.
- Same platform. Running Metabase on Railway keeps it on the same platform as the API and database. It can connect to PostgreSQL via Railway's internal network, avoiding cross-cloud latency and egress fees.
- SQL-native. Metabase speaks SQL natively and auto-discovers table schemas. The team can write raw SQL queries or use the visual query builder. This fits the existing workflow of querying the
eventstable for funnel analysis. - Shareable dashboards. Metabase supports public dashboard links and embedded iframes, which will be used to share corridor metrics with provider partners without giving them database access.
- Proven at scale. Metabase OSS is used by thousands of companies. The feature set (questions, dashboards, alerts, SQL runner) covers Curaway's current and near-future needs.
Alternatives Considered¶
| Alternative | Pros | Cons | Verdict |
|---|---|---|---|
| Metabase Cloud | Managed, automatic updates, no ops burden | $85/mo+ recurring cost, data leaves Railway network | Rejected on cost |
| Grafana | Already deployed for system monitoring | Poor UX for business analytics, SQL support is an afterthought, dashboards designed for time-series not tabular data | Rejected for BI use case |
| Looker (Google) | Enterprise-grade, LookML modeling | Expensive (enterprise contracts), massive overkill for a startup, slow to set up | Rejected |
| Apache Superset | Open source, powerful, good SQL Lab | Heavier resource requirements, more complex to deploy, steeper learning curve | Considered but Metabase won on simplicity |
| Custom dashboards (Next.js + Recharts) | Full control, integrated into the app | Significant engineering time to build and maintain, no SQL runner, reinventing the wheel | Rejected |
Consequences¶
- Positive: Business analytics available immediately with no SaaS cost. Dashboards can be iterated rapidly by writing SQL.
- Positive: Internal networking between Metabase and PostgreSQL ensures fast queries and no egress charges.
- Positive: Public dashboard links enable sharing metrics with stakeholders without managing user accounts.
- Negative: Self-hosted Metabase requires Railway resources (CPU, memory). The Metabase container uses approximately 512MB-1GB RAM.
- Negative: Upgrades must be managed manually (updating the Docker image tag and redeploying).
- Negative: Metabase queries hit the production database directly. Heavy dashboard queries could impact API performance. Mitigated by using read replicas or query timeouts if this becomes an issue.
- Accepted risk: Running analytics queries on the production database is acceptable at current scale (< 10K cases). A read replica will be introduced when query load justifies it.