Product facts
Eddy product reference
The facts behind eddy's customer reporting story, with links to the product examples and integration guides.
What Eddy does
eddy keeps the data behind customer reports updated as source records change. Your app and agents can query the results, or eddy can send them to other systems.
Customer reports get slow, expensive or out of date. They can also put too much load on the database running your product.
eddy is built for SaaS companies delivering reports to their customers, including reporting data for agents and MCP tools inside their products.
Teams using dbt, Snowflake or Databricks for customer reporting are included in this focus. Internal reporting for a company's own leadership is outside the current focus.
Models and delivery
A materialized view is a SQL model whose result eddy stores and updates as source records change.
eddy reads compiled SQL and dependencies from a dbt manifest. A folder of SQL works too. Check warehouse-specific syntax and functions.
Query the results through Postgres clients, the HTTP report API or MCP tools.
Push updated results to another database, a Kafka topic or a webhook.
Source connections
Postgres: Load the existing tables, then follow inserts, updates and deletes through logical replication.
MySQL: Load tables from MySQL 8.0 or 8.4, then follow the binary log. Values map to Postgres types for your reporting models.
Kafka: Read product events in Segment's message format. Saved progress lets the reader resume after a restart.
Webhooks: Receive events signed as Standard Webhooks, Stripe or GitHub. Repeat deliveries are kept once.
Files on S3: Read Parquet and JSONL files. Built and tested; check availability and load behavior for your hosted pilot.
Another source: Tell us where your data lives. We'll work through the connection before starting a pilot.
Model reuse and source access are separate checks. For Snowflake or Databricks projects, we'll work through the supported data connection with you.
SQL support and recorded coverage
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, 22 / 22: All definitions pass the recorded correctness checks through inserts, updates and deletes.
dbt Jaffle Shop models, 12 / 13: Twelve models are maintained in the recorded run, with a deterministic tie-break added to ambiguous window ordering.
These are recorded correctness checks, not official TPC-H certification or a claim of full dbt compatibility.
Customer access and agents
Your team builds the customer interface and agent tools. Your app checks identity and permissions, chooses which customer's data to use, and controls any actions an agent can take.
Time and alignment
Business time: The business dates you filter, such as the invoice dates selected in a date picker.
Source persistence time: When the source system saved a change. The default timeline for time travel and alignment.
Arrival time: When eddy received the change. This may be later than when it was saved upstream.
Each view or materialized view can align its inputs, with a database-wide default. An aligned view waits for all inputs to reach the same point in time. Newer changes wait until then. Unaligned inputs advance independently.
Query aligned reports as of one moment to compare data from the same point in time. The result identifies its as-of timestamp and timeline. The timeline is configurable.
For your pilot, confirm how much history is available and what happens if a query asks for a moment the data hasn't reached yet.
Availability and pricing
eddy is in early access. We host pilots on your data and agree a price before you start.
We're working toward usage-based pricing. We haven't settled the rates, billing units or allowances yet. For now, we agree each pilot's price directly with your team.
Serverless pricing is a goal we're exploring. We're still working through the billing model and whether the economics support it.
We haven't set a free allowance. Ask us about the current demo and pilot options.
Self-serve plans are not available yet.
Updates: A changed record can affect one row or many. The SQL model determines how much work each change creates.
Queries: Dashboards, apps and agents all query the data. We expect reads to be charged. The billing units and rates are not settled yet.
Storage: The results and history you keep need storage. How much depends on your data and reporting models.
Recorded serving benchmark
3,125 dashboard reads per second, 20.4 ms median response time and 64 concurrent clients.
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.
A recorded warm-cache dashboard lookup benchmark, not a measurement of arbitrary queries, exports, active-write freshness or subscription pricing.
Getting started
You don't need to connect your data for the demo. We'll email you to find a time.