FFastero

Connect any database. Ask in plain English.

Try free
Back to blog

Blog article

How to Build a Free Analytics Stack with Open-Source Tools

A practical guide to assembling a production analytics pipeline — storage, ingestion, transformation, visualization, and alerting — using only free, open-source tools. Total cost: $0-50/month in hosting.

Fastero Dev TeamFastero Dev Team
2026-08-20
analytics-stackopen-sourcedata-engineeringmetabasedbt
How to Build a Free Analytics Stack with Open-Source Tools

You can build a production-grade analytics stack for $0-50/month using only open-source tools. PostgreSQL for storage, Airbyte for ingestion, dbt Core for transformations, Metabase or Superset for dashboards, and Grafana for alerts. The tools are free. The cost is a $5/month VPS and your time maintaining it. I've run this exact stack at two companies, and it handled everything we threw at it -- until we ran out of engineering hours to keep it running.

The full pipeline architecture

  ┌─────────────┐   ┌─────────────┐   ┌─────────────┐
  │  Postgres    │   │  Stripe     │   │  HubSpot    │
  │  (prod DB)  │   │  (billing)  │   │  (CRM)      │
  └──────┬──────┘   └──────┬──────┘   └──────┬──────┘
         │                 │                  │
         ▼                 ▼                  ▼
  ┌──────────────────────────────────────────────────┐
  │         INGESTION — Airbyte / Singer taps        │
  └──────────────────────┬───────────────────────────┘

  ┌──────────────────────────────────────────────────┐
  │         WAREHOUSE — PostgreSQL / DuckDB          │
  └──────────────────────┬───────────────────────────┘

  ┌──────────────────────────────────────────────────┐
  │         TRANSFORM — dbt Core / SQL views         │
  └──────────────────────┬───────────────────────────┘
              ┌──────────┴──────────┐
              ▼                     ▼
  ┌─────────────────┐   ┌─────────────────┐
  │   DASHBOARDS    │   │    ALERTS       │
  │  Metabase /     │   │   Grafana /     │
  │  Superset /     │   │   Metabase      │
  │  Redash         │   │   alerts        │
  └─────────────────┘   └─────────────────┘

Each layer is independently replaceable. Start with Postgres + SQL views + Metabase and add layers when you actually need them. Don't deploy six tools on day one.

Layer 1: Storage -- PostgreSQL or DuckDB

PostgreSQL is the default. If your app already runs on Postgres, you can query it directly for analytics (with a read replica) or replicate into a separate analytics database. It handles tens of millions of rows, and every tool in this stack connects to it natively.

DuckDB is the alternative when your data lives in files -- CSVs, Parquet, JSON exports. It's an embedded columnar database with no server to manage. Analytical queries run 10-50x faster than Postgres because it's built for column scans, not row lookups. For a deeper comparison, see DuckDB vs Postgres for Analytics Workloads.

Start with Postgres. You probably already have one. Use DuckDB for file-based analytics or local prototyping.

# Analytics Postgres in 30 seconds
docker run -d --name analytics-pg \
  -e POSTGRES_DB=analytics -e POSTGRES_USER=analyst \
  -e POSTGRES_PASSWORD=changeme -p 5433:5432 postgres:16

Fastero

Connect your database. Ask questions. Get dashboards.

Postgres, BigQuery, Snowflake, and 10+ sources — live-connected, AI-powered, no dashboard builder learning curve.

Try free →

Layer 2: Ingestion -- Airbyte or Singer taps

Raw data lives in your SaaS tools -- Stripe, HubSpot, Google Analytics, Shopify. The ingestion layer moves it into your warehouse.

Airbyte (open-source, self-hosted) has 350+ connectors. It syncs on a schedule, handles schema changes, and gives you a web UI to configure everything. The tradeoff: it's heavy. Several Docker containers, at least 4GB RAM.

Singer taps are lighter -- individual Python scripts per data source, piped through a standard format (tap-stripe | target-postgres). Fine for 2-3 sources. At 10+ it becomes its own problem.

What to sync first: Your revenue source (Stripe, billing DB) and your CRM (HubSpot, Salesforce). Those two give you MRR, churn, and pipeline. Don't sync 15 sources on day one.

Layer 3: Transformation -- dbt Core or plain SQL views

Raw ingested data lands in staging tables that look like the source API's JSON flattened into columns. It's messy. The transformation layer turns stripe_raw.charges into analytics.monthly_revenue.

dbt Core is the industry standard -- free, SQL-based, with version control, testing, and documentation for your transforms.

pip install dbt-postgres
dbt init my_analytics && cd my_analytics
-- models/monthly_revenue.sql
select
  date_trunc('month', created_at) as month,
  sum(amount) / 100.0 as revenue,
  count(distinct customer_id) as paying_customers
from {{ source('stripe', 'charges') }}
where status = 'succeeded' and refunded = false
group by 1
dbt run && dbt test   # build models, run schema tests

Plain SQL views work too. If you have 5-10 transformations and one person writing SQL, creating views in Postgres is simpler than setting up dbt. Add dbt when transformations start depending on each other, when you need data quality tests, or when multiple people edit the SQL.

Layer 4: Visualization -- Metabase, Superset, or Redash

This is where your team sees the data. Pick one. Don't run two. For a detailed head-to-head, see Metabase vs Superset: Open Source BI Compared and our Best Open Source Dashboard Tools roundup.

Metabase -- easiest to deploy, best for non-technical users. Visual query builder means your ops manager can build dashboards without SQL. One Docker container. Limited on complex multi-dataset visualizations.

docker run -d -p 3000:3000 --name metabase metabase/metabase

Apache Superset -- most features. SQL Lab, dozens of chart types, row-level security, plugin system. The tradeoff: harder setup (Redis, Celery workers, metadata DB) and a steeper learning curve.

Redash -- lightest. Connect a database, write a query, get a chart. Community development has slowed since the Databricks acquisition, but it still works for quick SQL dashboards with minimal overhead.

  How technical is your team?

  ├── "We write SQL daily"
  │   ├── Need enterprise features (RLS, 50+ users)?
  │   │   └── Superset
  │   └── Just need dashboards fast?
  │       └── Redash

  └── "Mix of technical and non-technical"
      └── Metabase (visual query builder wins here)

Layer 5: Alerting -- Grafana or Metabase alerts

Dashboards nobody checks are dashboards that don't exist. Alerts make the data come to you.

Grafana is the better alerting engine. Connects to Postgres directly, evaluates queries on a schedule, sends alerts to Slack, PagerDuty, email, or webhooks. Supports thresholds, rate-of-change, and multi-condition logic. If you already run Grafana for infrastructure monitoring, add your business metrics here too.

Metabase alerts are simpler -- "email me when this number drops below X." Good for basic thresholds. Not enough for alert grouping, silencing, or escalation policies.

Layer 6: Orchestration -- Dagster, Airflow, or nothing

Orchestration ties the layers together: "run Airbyte sync, then dbt, then refresh Metabase." You might not need it.

Skip orchestration if you have fewer than 5 sources and Airbyte's built-in scheduler handles the timing. Add it when pipelines depend on each other -- when dbt must wait for Airbyte, or alerts need fresh data before evaluating.

Dagster is the modern choice -- asset-based modeling, native dbt integration, better local dev. Airflow is the established one -- more battle-tested, more community resources, but heavier to set up. For a detailed comparison, see Airflow vs Dagster: Data Orchestration Compared.

The full stack on one machine

Here's the minimum viable docker-compose -- Postgres, Metabase, and Grafana on a single $10/month VPS:

version: "3.8"
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: analytics
      POSTGRES_USER: analyst
      POSTGRES_PASSWORD: changeme
    ports: ["5433:5432"]
    volumes: [pg_data:/var/lib/postgresql/data]
  metabase:
    image: metabase/metabase
    ports: ["3000:3000"]
    environment:
      MB_DB_TYPE: postgres
      MB_DB_DBNAME: metabase
      MB_DB_PORT: 5432
      MB_DB_USER: analyst
      MB_DB_PASS: changeme
      MB_DB_HOST: postgres
    depends_on: [postgres]
  grafana:
    image: grafana/grafana
    ports: ["3001:3000"]
    volumes: [grafana_data:/var/lib/grafana]
volumes:
  pg_data:
  grafana_data:

Three containers, 2GB of RAM. Add Airbyte when you need SaaS connectors (budget another 4GB). Add dbt and Dagster when your transforms get complex. The whole stack runs comfortably on a $20-40/month machine.

When to stop building and just use a platform

This stack is free in licensing costs. It is not free in time.

Setting up Postgres + Metabase takes an afternoon. Adding Airbyte takes a day. Configuring dbt properly takes a week if you haven't used it before. Then there's the ongoing maintenance: Airbyte connector updates break schemas, Metabase upgrades need database migrations, Postgres needs vacuuming, and someone has to be on call when the sync fails at 3am on a Saturday.

If your team has a data engineer who enjoys this work, the DIY stack is great. Full control, no vendor lock-in, and you'll learn a lot about your data.

If your team is mostly analysts who want answers -- or if you're a small team where "the data person" is also the marketing lead, the ops manager, and half the engineering team -- maintaining six open-source tools is not a good use of your time.

That's the gap Fastero fills. Same pipeline -- databases, transforms, dashboards, alerts -- without the infrastructure. Connect your Postgres, ask questions in SQL or plain English, get dashboards that update themselves. No Docker, no YAML, no 3am pages.

FAQ

How much does this cost to host?

The minimum (Postgres + Metabase) runs on a $5-10/month VPS with 2GB RAM. Airbyte pushes you to 8GB+ ($20-40/month). The full stack with orchestration wants $40-50/month. All dramatically cheaper than a single Tableau or Looker license.

Do I need dbt?

Not immediately. Fewer than 10 transforms and one person writing SQL? Views are fine. Add dbt when transforms depend on each other, when you need data quality tests, or when multiple people edit the SQL.

Can this handle 100M rows?

Postgres handles 100M rows for analytics, but you'll need thoughtful indexing. At that scale, use materialized views or summary tables that dbt refreshes incrementally. DuckDB handles 100M+ rows in file workflows more naturally. North of 500M rows, you're in ClickHouse or BigQuery territory.

How long does this take to set up?

Postgres + Metabase: one afternoon. Airbyte with 2-3 connectors: half a day more. dbt with 5-10 models: 1-2 days (or a week if you're new to it). Total from zero to "dashboards my team uses daily": 1-2 weeks of part-time work.

When should I just pay for a platform?

When maintenance costs exceed licensing costs. If you're spending 5+ hours a week keeping the stack running, debugging broken syncs, and handling "the dashboard is down" tickets, it's time. If nobody on your team wants to be the infrastructure person, don't force it. Fastero gives you the same capabilities without the ops burden.


Try Fastero free -- the analytics stack in one platform. Connect your databases, ask questions in SQL or English, get dashboards and alerts. No infrastructure to maintain. No credit card required.

Ready to try it yourself?

Connect your database, ask questions in plain English, and get live dashboards — in under 2 minutes. No credit card required.