A reporting database for SaaS products
Better reporting
for your customers.
Customer reports get slow, expensive or out of date. They can also put too much load on the database running your product.
eddy keeps your reporting data updated in a separate database, ready for your app, agents and other systems.
When data changes
A correction should reach the report.
A customer changes plan. A refund adjusts last month's sales. eddy updates the reporting data as those records change, so your dashboards and agent tools can use the same numbers.
Sep 3–Oct 2 · Source changes through Oct 2, 10:00 UTC
| day | seats | events | Monthly spend |
|---|---|---|---|
| Oct 2 | 39 | 18,204 | $14,900 |
| Oct 1 | 39 | 21,560 | $12,400 |
| Sep 30 | 38 | 20,917 | $12,400 |
| Sep 29 | 38 | 12,044 | $12,400 |
1–4 of 30 · Next →
Same reporting data for your agent
“Northwind’s monthly spend is $14,900 on the Scale plan. Reporting period: Sep 3–Oct 2. Source changes included through Oct 2, 10:00 UTC.”
Example data and interfaces. Animation timing is illustrative.
Speed and cost
Reports need somewhere to run.
A query that works for one customer can struggle when hundreds open the report together. Running those queries against your application database adds load. Running them repeatedly in a warehouse can get expensive.
eddy keeps the reporting results updated as data changes. Customer requests read those results, instead of rebuilding the underlying report each time.
Recorded 2026-10-08: Six per-customer dashboard lookups over 30 active customers from a 1,000-customer demo dataset. Warm result caches, a quiet writer and a 20-second run. 4 proxies with 2 cores each on AWS m7g.8xlarge, 32 cores. Full setup and results.
The work behind the report
Keep reports current as your product grows.
New records are only part of the job. Refunds, corrections and deletes need to reach the report too. eddy keeps the results updated as your data and customer traffic grow.
SQL and dbt
Build on the reporting logic you already have.
Define your reporting models in SQL, or start with your existing dbt definitions. Already using Snowflake or Databricks? Start with one customer report. We'll work through its source data and SQL support with you, then compare the results with your current report.
Inside your product
Use the results wherever customers need them.
Your team builds the interface and decides what customers can see and what agents can do. eddy supplies the reporting data.
Your application
Query eddy through Postgres or HTTP. Connect your app.
Your agents
Use the same reporting models through MCP tools. Build customer tools.
Other systems
Push updated results to another database, a Kafka topic or a webhook. See delivery options.
Let's look at your report.
See eddy with a founder and talk through a report that's slow, expensive or out of date. You don't need to connect your data for the demo.
