Product analytics is where agents look most useful and disappoint most often. The problem is rarely the model; it is the layer. A funnel chart, a SQL warehouse, and a local parquet file are three different answers to the same question, and an agent told to 'check the numbers' will produce whichever one it is connected to.
This page compares the four analytics servers in the directory — PostHog, Amplitude, ClickHouse, and DuckDB — by the layer they expose.
The short answer
Dashboard APIs answer a question that already has a chart. Warehouses answer follow-up questions, at the cost of needing someone to write a correct query. Local engines answer questions about a file on the machine. Match the tool to the question, not to the vendor.
The four layers
| Layer | Server | Question it answers |
|---|---|---|
| Product analytics chart | PostHog, Amplitude | "How did this funnel perform last week?" |
| Analytical warehouse | ClickHouse | "Which segment has the worst retention?" |
| Local data file | DuckDB | "What is in this export?" |
| Raw event stream | none of these | "Why?" |
The last row is the honest gap. None of these servers explains a number; they report it. The explanation lives in session recordings, interviews, and support tickets.
PostHog and Amplitude: the curated layer
PostHog and Amplitude both expose a dashboard product's API. The answers are fast because the events and funnels are already defined. The limitation follows from the same fact: if nobody defined the event, the agent cannot invent it reliably.
The practical rule is that these servers work as well as the tracking plan. A team that names events carefully gets useful answers; a team with `button_click` everywhere gets an aggregate that means nothing.
ClickHouse: the warehouse layer
ClickHouse is where an agent stops asking for a chart and starts writing SQL. That is a meaningfully different capability — the question can be new — and a meaningfully different risk: an unconstrained query can scan a month of events and take the cluster with it.
A read-only user, a row limit, and a schema the agent can read are the three settings that make this workable. Without the schema, the model guesses column names and fails; without the limit, one exploratory question becomes an incident.
DuckDB: the local layer
DuckDB is for the export someone downloaded: a folder of parquet files, a CSV of support tickets, a sample from a data warehouse. It runs locally, needs no credentials, and cannot reach production.
That makes it the best on-ramp for an analyst who wants to ask questions of a dataset before building a pipeline. It also makes it useless for a live dashboard, which is the right boundary.
What an agent actually does well here
Three patterns hold up in practice. A metric lookup: pull one number from an existing definition. A segmented comparison: the same query across two cohorts. A data check: is this export complete, are these dates parsed correctly, does the join drop rows.
What does not hold up is causal explanation. An agent can show that retention fell after a release; it cannot tell you why, and a confident sentence about the cause is the most damaging output this category produces.
The guardrails
| Risk | Mitigation |
|---|---|
| Query cost | Read-only user plus cluster quotas |
| Wrong event meaning | Documented taxonomy in the prompt |
| Silent wrong join | A data check before the analysis |
| Causal claims | Prohibit them; report the number only |
The last row is a prompt rule, not a technical control — but it is the one that changes output most.
Frequently asked questions
Do I need all four? No. Start with the layer your team already trusts, and add the warehouse only when follow-up questions are routine.
Can an agent replace an analyst? It replaces the query writing for known questions, not the judgement about which question matters. See SQL Analyst.
What about cost? Warehouse queries cost money; local queries do not. That asymmetry is a good reason to prototype on a local file. See MCP servers.
Last checked: 12 November 2026.
Related: data quality checks, MCP servers for deploys and data, and MCP servers.
