Hey everyone,

Trifle.Stats is a library for tracking custom application metrics as time-series data. Orders, revenue, job counts, feature usage. The stuff you keep answering from iex until someone asks for a chart. No separate metrics service, no events table, no pipeline. It writes pre-aggregated rollups into Postgres, MySQL, SQLite, MongoDB or Redis (plus an in-memory Process driver for dev/tests).

It started as a Ruby gem and the Elixir library shares the key structure and storage layout, so a mixed Ruby/Elixir system can write into the same tables and read each other’s metrics.

Both sides are in production use. The Ruby version tracks around 100M background jobs a day at DropBot. The Elixir version runs inside Trifle App, which is an Elixir app itself. There it writes a small amount of usage stats but mostly sits on the read path, serving series for dashboards, alerts, the API and AI analysis. So the write path has been exercised hardest from Ruby, and the read/aggregation path hardest from Elixir.

How it works

You give it a key, a timestamp and a map of values. It increments those values into buckets for every granularity you configured. Setup with Postgres:

{:ok, conn} = Postgrex.start_link(
  hostname: "localhost",
  database: "myapp_stats"
)

# creates tables + indexes
Trifle.Stats.Driver.Postgres.setup!(conn)

Trifle.Stats.configure(
  driver: Trifle.Stats.Driver.Postgres.new(conn),
  time_zone: "UTC",
  track_granularities: ["1h", "1d", "1w", "1mo"],
  beginning_of_week: :monday
)

The interesting part: values is not a single counter. It is a map, and it can be nested. Every numeric leaf gets incremented:

Trifle.Stats.track("orders::completed", DateTime.utc_now(), %{
  count: 1,
  revenue_cents: order.total_cents,
  payment: %{
    order.payment_method => %{count: 1, revenue_cents: order.total_cents}
  },
  channel: %{
    order.channel => %{count: 1, revenue_cents: order.total_cents}
  }
})

One call increments the totals plus the per-payment-method and per-channel breakdowns, in the hourly, daily, weekly and monthly buckets. Lots of tools can count. Counting a whole tree of things in one write is the part I have not seen elsewhere.

On Postgres each bucket is one row (key + granularity + timestamp) with a JSONB payload, and the increment is a single INSERT ... ON CONFLICT DO UPDATE built from nested jsonb_set calls. No read-modify-write in the app.

Reading gives you parallel lists of timestamps and values:

now = DateTime.utc_now()
from = DateTime.add(now, -30, :day)

Trifle.Stats.values("orders::completed", from, now, "1d")
# => %{
#      at: [~U[2026-06-14 00:00:00Z], ...],
#      values: [%{"count" => 128, "revenue_cents" => 1034400,
#                 "payment" => %{"card" => %{"count" => 97, ...}, ...}}, ...]
#    }

Series pipelines

The part that fits Elixir nicely: wrap the result in a Series and everything is pipe-friendly. Aggregators and formatters are terminal operations, transponders derive new values inside the series:

use Trifle.Stats.Series.Fluent

series =
  Trifle.Stats.values("orders::completed", from, now, "1d")
  |> Trifle.Stats.series()

# Total revenue over 30 days
series |> aggregate_sum("revenue_cents")

# Card orders only, dot-path into the nested tree
series |> aggregate_sum("payment.card.count")

# Derive average order value per day, then find the best day
series
|> transpond_expression(["revenue_cents", "count"], "a / b", "aov")
|> aggregate_max("aov")

# Chart-ready output
series |> format_timeline("count")

Notice that “card orders per day” was never declared as a metric anywhere. It just falls out of the data model. Any branch you tracked can be queried later without defining it upfront.

Status pings

Besides time series there is a small status API. beam/3 overwrites the latest state for a key, scan/1 reads it back. Named after submarine sonar, because naming things is hard:

Trifle.Stats.beam("worker::sync", DateTime.utc_now(), %{count: 5, duration: 12})
                                                                                      Trifle.Stats.scan("worker::sync")                                                                                                                                     # => {:ok, %{...}}

Useful for “when did this worker last run and what did it do” without paying for a full time series.

What it is not

It stores pre-aggregated rollups, so you decide what to count at write time, not query time. If you need raw event replay, ad-hoc queries over dimensions you did not track, or user-level analytics, this is not that tool. It is deliberately simple. That is kind of the whole point.

Current version is 2.5.0, MIT licensed. Feedback very welcome, especially on the driver implementations and what you would want from the Series API.

Docs: Trifle.Stats | Trifle Docs
Hex: trifle_stats | Hex