AI agent execution traces increasingly function as application data rather than disposable telemetry, since developers and reviewers need durable, point-lookup access to individual runs while engineering teams need cohort-level analytical scans across thousands of runs. This dual read pattern strains primary transactional databases as ingestion volume grows, causing contention, analytical friction, and forced sampling. Langfuse's experience moving trace data from Postgres to ClickHouse illustrates the pattern: it hit Postgres IOPS exhaustion and multi-second query latency, then migrated tracing data to ClickHouse while keeping transactional data in Postgres, and later redesigned its data model into a wide, mostly immutable observations table, improving dashboard load times by over 10x. The guidance is to map point-lookup and cross-run scan requirements early and design storage architecture around both from the start rather than waiting for a fixed event-count threshold.
Table of contents
When a trace becomes product dataWhy one agent run produces so much dataWhy agent trace data behaves like telemetryOutgrowing the primary databaseHow to choose a storage patternStart with who reads the traceQuestions this post answers
Why did Langfuse move its tracing data from Postgres to ClickHouse?
Langfuse moved tracing data from Postgres to ClickHouse after hitting Postgres IOPS exhaustion during ingestion and prompt API latency reaching seven seconds under heavy load. It kept transactional and latency-sensitive paths isolated in Postgres while sending trace events to ClickHouse for analytical queries, addressing contention between ingestion workload and product reads. Teams weighing an analytical database migration for observability data can track real-world case studies like this on daily.dev.
What data model change improved Langfuse's dashboard performance for agent trace data?
Langfuse collapsed separate trace, observation, and score tables into a single wide, mostly immutable observations table with one row per model call, tool execution, or agent step. This eliminated deduplication and cross-table joins, cutting initial table loads for large datasets from seconds to milliseconds and improving dashboard load times for large projects by at least 10 times over longer time ranges. daily.dev surfaces data modeling patterns like this for engineers optimizing analytical storage.
How much event data can a single AI agent run generate?
A single browser-agent session can generate hundreds of thousands of DOM diff events and run for more than 30 minutes, with Laminar reporting more than 500,000 browser events per day in one case study. For coding agents, one task can trigger multiple model calls, file reads, searches, command executions, and retries, each producing its own span or event. Engineers sizing storage for agent observability workloads can follow findings like this on daily.dev.
164 Impressions1 Comment