Trifle: Analytics Open-Source yang Simpan Jawaban, Bukan Events

Masalah Analytics Modern: Data Terlalu Banyak, Jawaban Terlalu Sedikit

Kalau lo pernah setup analytics untuk aplikasi production, pola ini pasti familiar: database grows dari 10GB ke 100GB ke 1TB dalam hitungan bulan, query untuk dashboard eksekutif yang tadinya 2 detik jadi 30 detik, tim engineering spending setengah waktu untuk optimize index dan partitioning. Dan setelah semua effort itu, jawabannya tetap sama: grafik naik terus, conversion rate flat, retention turun.

Ini bukan masalah tools — ini masalah paradigma. Kebanyakan analytics platform modern (Mixpanel, Amplitude, PostHog, dan self-hosted seperti PostHog/Umami/Matomo) menyimpan events: setiap click, setiap page view, setiap API call. Storage strategy-nya event-based, query model-nya SQL-like dengan aggregation. Masalahnya, untuk jawab pertanyaan bisnis seperti "berapa conversion rate minggu ini?" atau "channel mana yang paling efisien untuk acquired user?", Anda harus aggregate dari jutaan events setiap kali query dijalankan.

Biaya operasionalnya jadi besar. Latency jadi tinggi. Dan worst of all, business stakeholder tidak sabar — mereka mau jawabannya sekarang, bukan 30 detik dari sekarang.

Trifle: Paradigma Berbeda — Simpan Jawaban, Bukan Events

Trifle adalah analytics platform open-source yang mengambil pendekatan berbeda: alih-alih menyimpan events, Trifle menyimpan jawaban. Setiap metric yang Anda define (conversion rate, retention cohort, revenue per channel) di-compute sekali waktu dan disimpan sebagai materialized result. Query berikutnya tinggal read result — tanpa aggregation, tanpa SQL parsing, tanpa iterasi ke jutaan rows.

Konsepnya mirip dengan materialized view di database, tapi dirancang khusus untuk analytics use case dengan fokus pada pre-computation dan incremental update. Trifle ditulis dalam Go, menggunakan PostgreSQL sebagai primary store (untuk metadata) dan ClickHouse atau DuckDB sebagai query engine. Lisensi: AGPL v3.

Versi 0.6 (rilis Mei 2026) sudah digunakan oleh beberapa startup YC dan satu unicorn fintech di Eropa untuk internal analytics mereka. Repo di GitHub punya 800+ star dan 40+ contributor.

Cara Kerja: Definisi Metric, Auto-Update, dan Instant Query

Workflow di Trifle berbeda dari event-based analytics. Alih-alih push events ke API, Anda define metric yang punya formula dan update schedule. Contoh definisi metric untuk daily active user:

# metric.yml
metrics:
  - name: dau
    type: count_distinct
    source: events
    column: user_id
    filter: "event_type = 'session_start' AND timestamp >= now() - interval '24 hours'"
    refresh: every_5_minutes
    
  - name: conversion_rate
    type: ratio
    numerator: conversions
    denominator: sessions
    refresh: every_15_minutes
    
  - name: revenue_per_channel
    type: aggregation
    source: events
    value: amount
    group_by: channel
    filter: "event_type = 'purchase'"
    refresh: every_1_hour

Trifle background worker akan eval setiap metric sesuai schedule, simpan hasilnya ke result table, dan invalidate cache. Saat dashboard load, query ke Trifle API langsung return pre-computed result — biasanya di bawah 10ms.

Untuk metric baru yang belum di-define, Trifle menyediakan exploration mode yang fallback ke query engine (DuckDB atau ClickHouse) dengan aggregation on-the-fly. Mode ini lebih lambat (~100ms-1s) tapi memungkinkan discovery tanpa harus define metric dulu.

Arsitektur: Empat Komponen Inti

Trifle terdiri dari empat komponen yang berjalan sebagai service terpisah:

1. trifle-ingest — API endpoint untuk terima events dari aplikasi (HTTP, gRPC, atau Kafka consumer). Mendukung batching, schema validation, dan dead-letter queue untuk event yang invalid.
2. trifle-store — PostgreSQL database (atau S3-compatible object storage) untuk raw events. Retention policy configurable (default 90 hari untuk raw events, unlimited untuk materialized result).
3. trifle-eval — background worker yang eval metric definitions dan update result table. Bisa di-scale horizontal dengan partitioning per metric.
4. trifle-api — HTTP API untuk query metrics dari dashboard atau application. Endpoint: GET /v1/metrics/{name}?from=...&to=...&group_by=....

Deployment standard: empat service di atas single PostgreSQL instance + satu ClickHouse node. Untuk high-traffic, ClickHouse cluster dengan 3+ node sudah cukup untuk handle sampai 100k events/detik.

Perbandingan dengan Event-Based Analytics

Aspek	Trifle	PostHog (self-host)	Mixpanel	ClickHouse murni
Pendekatan	Store answers	Store events	Store events	Store events
Query latency (metric)	~5ms (pre-computed)	~500ms-5s (SQL)	~200ms-2s	~100ms-30s
Storage growth	Lambatan (mostly answers)	Cepat (raw events)	Sangat cepat	Sangat cepat
Schema flexibility	Rigid (defined metrics)	Fleksibel (any event)	Fleksibel	Fleksibel
Onboarding effort	Sedang (define metrics)	Rendah (just track events)	Rendah	Tinggi (SQL expert)
Exploratory analysis	Limited (need define)	Full SQL/UI	Full UI	Full SQL
Self-host	Ya (Go + PostgreSQL + CH)	Ya (Django + ClickHouse)	Tidak	Ya (C++)
Open source	AGPL v3	MIT	Tidak	Apache 2.0
Biaya operasional	Rendah (small infra)	Sedang	Tinggi (per event)	Sedang-Tinggi

Trifle unggul di use case di mana Anda sudah tahu metric apa yang penting dan ingin latency rendah. Untuk use case eksplorasi data yang masih banyak discovery, event-based platforms lebih fleksibel. Banyak tim yang pakai hybrid: Trifle untuk metric inti dashboard, dan event-based platform untuk deep-dive analysis.

Integrasi dengan Stack DevOps Lainnya

Trifle dirancang untuk plug-in ke stack monitoring dan observability yang sudah ada:

• Prometheus — export Trifle metrics ke Prometheus format untuk alerting via Alertmanager. Setup: trifle-export prometheus --port 9090 jalan sebagai sidecar, scrape dari Prometheus server.
• Grafana — Trifle punya datasource plugin resmi. Dashboard Trifle bisa di-import ke Grafana untuk visualisasi yang lebih kaya. Query language mirip SQL tapi simplified.
• Slack/Discord — built-in alerting ke Slack/Discord untuk threshold breach. Format pesan customizable dengan Markdown.
• Airflow/Dagster — Trifle metric evaluation bisa di-trigger dari Airflow DAG untuk scheduling yang lebih kompleks (misalnya eval metric hanya di weekday).

Untuk monitoring infrastructure sendiri (CPU, memory, network), Trifle complement tools seperti Netdata + Grafana + Prometheus. Bedanya, Netdata fokus pada time-series metric real-time untuk ops, sementara Trifle fokus pada business metric untuk product/finance team.

Self-Host Setup: Docker Compose di VPS 4GB

Setup minimum Trifle self-host di VPS 4GB RAM (seperti Hetzner CX22 atau Contabo VPS M):

# docker-compose.yml
version: '3.8'
services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_DB: trifle
      POSTGRES_USER: trifle
      POSTGRES_PASSWORD: {DB_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: unless-stopped
    
  clickhouse:
    image: clickhouse/clickhouse-server:24.6
    ulimits:
      nofile: 262144
    volumes:
      - chdata:/var/lib/clickhouse
    restart: unless-stopped
    
  trifle-ingest:
    image: trifle/ingest:0.6
    environment:
      DATABASE_URL: postgres://trifle:{DB_PASSWORD}@postgres/trifle
      CLICKHOUSE_URL: clickhouse://clickhouse:9000
    ports:
      - "127.0.0.1:8080:8080"
    depends_on: [postgres, clickhouse]
    restart: unless-stopped
    
  trifle-eval:
    image: trifle/eval:0.6
    environment:
      DATABASE_URL: postgres://trifle:{DB_PASSWORD}@postgres/trifle
      CLICKHOUSE_URL: clickhouse://clickhouse:9000
      WORKER_CONCURRENCY: 2
    depends_on: [postgres, clickhouse]
    restart: unless-stopped
    
  trifle-api:
    image: trifle/api:0.6
    environment:
      DATABASE_URL: postgres://trifle:{DB_PASSWORD}@postgres/trifle
    ports:
      - "127.0.0.1:8081:8081"
    depends_on: [postgres, trifle-eval]
    restart: unless-stopped

volumes:
  pgdata:
  chdata:

Setelah docker-compose up, inisialisasi schema dengan trifle-cli init, lalu start defining metrics di file YAML. Trifle CLI juga menyediakan trifle-cli dashboard untuk web UI sederhana yang auto-generate dari metric definitions.

Use Case Praktis untuk Startup Kecil

Untuk startup dengan tim kecil (3-10 developer) dan user base di bawah 1 juta, Trifle menawarkan beberapa use case yang sering di-underestimate:

1. Investor dashboard — startup yang perlu laporan bulanan ke investor bisa generate otomatis dari Trifle. Metric: MAU, retention cohort, revenue run rate, burn rate. Update setiap jam, query latency di bawah 100ms untuk grafik 12 bulan.
2. A/B test result — jalankan eksperimen, define metric "experiment_X_conversion" yang di-eval per 30 menit, dan dashboard internal langsung update. Tidak perlu tunggu data analyst pull manual dari database.
3. Internal OKR tracking — untuk tim yang pakai Objectives and Key Results, Trifle bisa jadi source of truth otomatis. Key Result seperti "reduce churn dari 8% ke 5%" di-track real-time tanpa spreadsheet manual.
4. Revenue forecasting — untuk business yang mau predict MRR bulan depan, Trifle bisa eval metric "forecasted_mrr" yang pakai simple moving average atau integration dengan time-series forecasting model eksternal.

Biaya operasional Trifle self-host di VPS 4GB: sekitar $5-10 per bulan (tergantung provider), plus engineer time untuk maintenance awal. Dibandingkan Mixpanel (~$800/bulan untuk 1M events) atau PostHog cloud (~$450/bulan), self-host Trifle hemat 80-95% di tahun pertama.

Limitasi yang Perlu Diketahui

Trifle bukan solusi sempurna untuk semua use case. Limitasi yang jelas:

• Schema rigidity — kalau Anda sering add new event type atau ubah schema, overhead define metric di YAML bisa terasa lambat. Untuk tim yang sangat eksperimental, event-based platforms lebih cocok.
• Exploration cost — untuk pertanyaan ad-hoc seperti "gue penasaran, user dari kota mana yang paling banyak convert kemarin?", Anda harus define metric baru dulu. Tidak bisa langsung query.
• Community size — dengan 800+ star dan 40 contributor, komunitas Trifle lebih kecil dari PostHog (20k+ star) atau ClickHouse (35k+ star). Untuk troubleshooting edge case, mungkin perlu baca source code langsung.
• No mobile SDK — saat ini SDK hanya untuk web (JavaScript) dan server (Go, Python, Node). SDK untuk iOS/Android masih di roadmap (ETA Q4 2026).

Untuk tim yang kebanyakan eksplorasi, PostHog atau Mixpanel masih lebih cocok. Untuk tim yang sudah punya product-market fit dan fokus pada eksploitasi (optimize funnel, track OKR, monitor trend), Trifle menawarkan sweet spot yang menarik.

Roadmap dan Ekosistem

Tim Trifle aktif ship release setiap 2-3 minggu. Beberapa item di public roadmap yang menarik:

• Q3 2026 — SQL query interface untuk ad-hoc analysis (dengan caching layer)
• Q3 2026 — dbt integration untuk metric definition sebagai code
• Q4 2026 — Mobile SDK (iOS, Android) dan React Native
• Q1 2027 — Distributed eval (Apache Flink integration) untuk high-throughput

Ekosistem di sekitar Trifle mulai tumbuh: ada beberapa BI tool yang integrate Trifle sebagai datasource, dan satu startup di Berlin sudah build managed Trifle service (mirip seperti PostHog cloud vs self-host). Untuk deploy di Kubernetes, ada Helm chart resmi di artifacthub.io.

Rekomendasi untuk Tim DevOps

Untuk tim DevOps Indonesia yang sudah jalankan stack ArgoCD atau Flux untuk deployment, Trifle adalah tambahan yang natural untuk monitoring business outcome dari aplikasi — bukan cuma uptime. Setup minimum: 1 hari kerja untuk install dan define 5-10 metric pertama, 1 minggu untuk onboard tim product/finance ke dashboard, dan 1 bulan untuk mature ke setup production.

Sumber

• Trifle GitHub Repository
• Trifle Documentation
• Trifle Engineering Blog: Why Store Answers
• ClickHouse Documentation