The Setup: One Mac Mini, Two Databases, 100 Million Rows

A developer ran a head-to-head benchmark on a Mac Mini M4 Pro, comparing ClickHouse and PostgreSQL for storing and querying LLM traces. The data: 100 million synthetic rows representing LLM API calls, with fields like model name, token count, cost, latency, and error status. Both databases received identical data via the same generation seed.

The test measured four metrics at 1M, 5M, 10M, 25M, 50M, and 100M rows: ingest speed, disk usage, RAM consumption, and query latency for three realistic workloads.

Ingest Performance: ClickHouse Widens the Gap

ClickHouse ingested at a steady ~78,000 rows/sec regardless of dataset size. PostgreSQL started at ~32,000 rows/sec but degraded to ~14,000 rows/sec by 100M rows. The culprit: Postgres's indexes, which slow writes as they grow. At 100M rows, ClickHouse was 5.6x faster for ingestion.

Disk Usage: Compression Is a Silent Win

ClickHouse compressed the 100M rows to 48 GB on disk, while PostgreSQL required 116 GB — a 2.4x difference. ClickHouse's internal columnar compression ratio was ~5.5x. On a 300 GB SSD, that's the difference between having room to spare and watching your free space shrink.

Query Performance: Not a Clean Sweep

The three benchmark queries were:

  1. Point lookup: Fetch one trace by ID.
  2. Dashboard aggregation: Cost and latency per model over the last 90 days.
  3. Metrics query: Aggregations across all history (p95 latency, total cost, error rate).

Point lookup: PostgreSQL won decisively — ~0.03 ms vs ClickHouse's ~3 ms (100x faster). Row stores excel at retrieving individual rows by primary key.

Dashboard query: At 1M rows, both were fast (Postgres ~228 ms, ClickHouse ~15 ms). At 100M rows, ClickHouse took 284 ms while PostgreSQL hit 49,085 ms (49 seconds). That's the difference between a snappy dashboard and a user walking away.

Metrics query: Similar story — ClickHouse stayed around 500 ms; PostgreSQL reached ~70 seconds at 100M rows.

Memory: Both Bored

Peak RAM usage was low: PostgreSQL ~134 MB, ClickHouse ~950 MB. The Mac Mini's 24 GB went largely untouched. The author notes that concurrent traffic would change this, but the single-query scenario showed neither database struggled.

Why This Matters for LLM Observability

This benchmark directly mirrors the real-world migration of Langfuse, an open-source LLM observability platform. Langfuse started on PostgreSQL but moved trace storage to ClickHouse in v3 because dashboard queries became too slow. In early 2026, ClickHouse acquired Langfuse. The numbers confirm the decision: for analytical queries over millions of rows, ClickHouse is orders of magnitude faster. PostgreSQL remains superior for transactional lookups.

Practical Takeaways

  • Use PostgreSQL for transactional data (user profiles, auth, point lookups).
  • Use ClickHouse for analytical workloads (aggregations, dashboards, time-series).
  • A Mac Mini M4 Pro can handle 100M rows for both databases — it's a viable prototyping machine.
  • Compression matters: ClickHouse's columnar storage saved 68 GB vs Postgres at 100M rows.
  • Indexes have a cost: Postgres's write degradation is a direct result of maintaining indexes for fast reads.

Next Steps

If you're building an LLM observability tool or any analytics-heavy app, consider a hybrid architecture: Postgres for operational data, ClickHouse for analytics. The author may open-source the benchmark scripts — watch his Twitter @kitarp29 for updates.