Trifle – Open-source analytics that stores answers, not events

Trifle is an open-source time-series analytics library that aggregates nested counters instead of storing raw events. All in the database you already have. After rebuilding it twice over 10 years, it now tracks ~1B events a day at my day job.It started in 2015 as my own Rails APM. I plugged into ActiveSupport::Notifications, got a few small users, and one bigger one whose scraping app broke everything. That sparked the core idea: aggregate counters into pre-defined time buckets, so a single write increments multiple buckets at once. The APM eventually faded away without much traction.Later in 2021 I needed analytics at my day job. Instead of going for something out there I revised the idea of Trifle as a more generic analytics library, borrowing some data warehouse ideas. First used Redis, then Postgres, eventually MongoDB. Hence why Trifle::Stats comes with multiple drivers that keep the DSL unified while storage layer changes with your needs. In our case (huge write volume, some reads) PG read faster but slowed on large writes.The nested values are the whole trick here. Single: Trifle::Stats.track( key: 'requests::aws::s3_uploads', values: { count: 1, status: { request.response_code => 1 }, size: payload.bytes, duration: { sum: request.duration, count: 1 } } ) builds up counts for requests, success rate, result status codes, duration for multiple time buckets at once. Single bucket from 2am then looks like: { count: 14, status: { 200: 12, 500: 2 }, size: 5628341, duration: { sum: 43, count: 14 } } If request.duration is in seconds, then sum stored under duration would be in seconds as well.Success rate is never stored, but it is calculated by dividing 200s over total number of requests. Same with average duration: sum over count. You ask for a metrics key, granularity and timeframe and you get back aggregated values at each point. Ready for charts or to answer "Average response time over last 30 days&qu

Hacker NewsToolAISource
0Sign in to voteCopy link

FL score

62

out of 100

Verdict

VALIDATE

high confidence

Competition

No competitor data yet

Trend

No signal yet

Open-source analytics library that pre-aggregates metrics into time buckets instead of storing raw events, reducing storage and write load.

The pain

Companies with high-volume event streams (1B+ events/day) face three problems: (1) storage costs explode with raw event retention, (2) writing millions of events per second creates database bottlenecks, (3) most analytics tools force you into their proprietary stack or charge per event.

The gap

Existing solutions split into two camps. Data warehouses (Snowflake, BigQuery) handle scale but cost money and require data pipeline work. Open-source APM tools (Prometheus, StatsD) work but are narrowly focused on metrics, not flexible analytics. Nothing bridges the gap: a flexible, open-source analytics library that works with your existing database and handles nested aggregations at write time.

Build angle

Position as the 'write-time aggregation layer' for teams already using Postgres/MongoDB/Redis who need analytics but don't want another SaaS bill or data pipeline. Target engineering teams at mid-market companies (50-500 engineers) running high-traffic services. Lead with the concrete win: 'Track 1B events/day on Postgres without dedicated infrastructure.' Emphasize the nested counter pattern as the core differentiator, it's unintuitive but solves the write amplification problem that kills naive time-series approaches.

Strengths

  • Proven at scale: already handles 1B events/day in production, not theoretical
  • Works with existing infrastructure: Postgres, MongoDB, Redis drivers mean no new database to operate
  • Unified DSL across storage layers reduces lock-in and lets teams swap backends without code changes
  • Open-source removes pricing friction and appeals to engineering-driven buying decisions
  • Nested aggregations are genuinely clever: single write increments multiple time buckets and nested dimensions simultaneously, cutting write load by 10-100x vs raw events
  • Solves a real problem for a specific segment: high-volume, cost-conscious teams

Risks

  • Market size unclear: how many teams actually need 1B events/day analytics? Addressable market may be smaller than it appears (maybe 500-2000 companies globally)
  • Positioning confusion: is this an APM tool, a metrics library, or a data warehouse? The pitch jumps between use cases without a clear primary one
  • Adoption friction: requires teams to change how they instrument code (new tracking calls) and think about pre-defined buckets. Not a drop-in replacement for existing tools
  • Competitive pressure from established players: Datadog, New Relic, and Prometheus are entrenched. Open-source alone doesn't guarantee adoption if integration work is high
  • Monetization path is murky: open-source + no obvious SaaS angle means unclear how to build a sustainable business. Hosting/support model works but is low-margin
  • Documentation and community: library-only projects live or die on docs and examples. Current description suggests limited public examples or case studies
  • Pre-aggregation is a constraint: once you decide on time buckets and dimensions, you can't retroactively ask new questions. This is a feature for write efficiency but a limitation for exploratory analytics

Questions about this idea?

FlyBot reads the scoring and gives you a second opinion on “Trifle – Open-source analytics that stores answers, not events”.

Open FlyBot