SQL and dbt for customer reporting
Bring your reporting models into the product.
Start with the SQL or dbt definitions behind your customer reports. eddy keeps their results updated as source records change. Your app can query the data, or eddy can send it to other systems.
01 · Your existing models
Keep the logic. Try one report.
Already using dbt with Snowflake or Databricks? Bring one report's compiled SQL and the tables it depends on. You can keep the rest of your analytics stack while trying eddy for that report.
Bring the definition
eddy reads compiled SQL and dependencies from a dbt manifest. A folder of SQL works too. Check warehouse-specific syntax and functions.
Connect the data
Work out how the underlying tables and their changes reach eddy. Check table names, column types and the keys that identify each customer.
Compare the results
Preview the model, compare it with your current report as records change, then connect your app.
Model reuse and source access are separate checks. For Snowflake or Databricks projects, we'll work through the supported data connection with you.
02 · Support
Check the SQL before building the model.
eddy supports familiar reporting SQL, including joins, aggregates and window functions. A preview explains unsupported SQL so you can decide whether a rewrite makes sense.
TPC-H query definitions
All definitions pass the recorded correctness checks through inserts, updates and deletes.
dbt Jaffle Shop models
Twelve models are maintained in the recorded run, with a deterministic tie-break added to ambiguous window ordering.
Preview before building
Check the SQL and output before committing to the model.
These are recorded correctness checks, not official TPC-H certification or a claim of full dbt compatibility.
03 · Updates and corrections
The report should change when the records do.
A refund changes revenue. An amended invoice changes a balance. A deleted record changes a count. eddy updates the model's result under those changes.
- Check the numbersCompare with your warehouse or source query as records are added, changed and deleted.
- Show which data is includedThe reporting period describes business dates. Show which changes saved in the source system have reached the result.
- Keep related numbers togetherAlign inputs when they need to agree, accepting that newer changes may have to wait.
04 · Changing a model
See the effect before applying a change.
Preview a model before building it. For a replacement, review which rows change and what needs rebuilding. Apply it alongside the running system, then inspect the result.
with revenue as (
select account_id, sum(mrr) as mrr
from subscriptions
where status = 'active'
group by account_id
), usage as (
select account_id, count(*) as events
from usage_events
group by account_id
)
select a.id, a.name, r.mrr, u.events
from accounts a
join revenue r on r.account_id = a.id
left join usage u on u.account_id = a.id- whereactive subscriptionssource
- group bysubscription accountper account
- group byusage accountper account
- joinaccounts and aggregatesper account
- resultone row per accountmaintained
05 · Using the results
Use the model throughout your product.
Query the results from your app, agents and MCP tools, or push them to other systems. Your app checks who can see each customer's data.
customer scope · acmeauthorizedrefunds_by_location · March12 locationsrevenue + refunds · alignedsame as-of time06 · Time and alignment
Choose when related data moves forward together.
A view or materialized view can wait for its inputs to reach the same point in time. Newer changes are held back until then. Where freshness matters more, let the inputs move forward independently.
Time travel and alignment use source persistence time by default: when a change was saved upstream. That timeline is configurable. We'll confirm available history and as-of behavior for your pilot.
Bring a reporting model you're working on.
Book a demo and show us the SQL, its source data and where customers use the results.
