The product, up close
See every change, and why.
eddy is a live system you can look inside: the graph as it runs, each model as steps, a change reviewed before it is made, any number traced to its rows.
Renderings of the product’s own screens with example data. The measured numbers are on the overview.
01 · Pipeline
The whole system, running.
Postgres on the left, every model in the middle, what your readers see on the right. Each change is visible on the edges it crosses.
eddyglass pipeline · acme-saasLivepresenterstore s32,418 txnsopen
Postgres0/3A21F08
Transactions
Upgrade a planRemove seats7 msVoid an invoiceNew accountRefund a paymentCorrect history
Write rate5 changes/s
015102050100
Last transaction
lsn0/3A21F08statements1took7 ms
SQL
delete from seats
where account_id=57
and id > 14;
where account_id=57
and id > 14;
DAG12 models64 operatorsclick a box for its SQL, an edge for the rows that crossed it
Gets / min4271 KB · 3 ticks
Cache hits97.8%61 MB / 256 MB
Resident38 MBrss 212 MB
State1.2 GBs3 · 214 files
LSN0/3A21F082,418 txns
Tick4.1 msp99 9.8 ms
Martsmrrmrr_by_planaccount_healthseat_utilizationinvoice_agingusage_dailyexpansion_candidates
eddy7 mscommit → fresh · tick 2,418
Postgres view2.1 splain view, full recompute
account_health · 3,208 rows
| account_id | name | mrr | seats | risk |
|---|---|---|---|---|
| 42 | Northwind | 14,420 | 39 / 40 | low |
| 57 | Contoso | 8,900 | 14 / 40 | high |
| 88 | Glenmore | 22,150 | 71 / 80 | low |
| 103 | Inkwell | 3,600 | 9 / 20 | watch |
| 131 | Meridian | 41,300 | 188 / 200 | low |
| 164 | Brightline | 12,800 | 21 / 50 | watch |
| 201 | Kestrel | 6,250 | 12 / 25 | watch |
| 233 | Halden | 18,700 | 60 / 60 | low |
| 260 | Norrland | 2,900 | 4 / 10 | high |
| 287 | Corvid | 9,450 | 30 / 30 | low |
| 301 | Tallis | 5,100 | 11 / 15 | low |
| 322 | Ashgrove | 27,600 | 90 / 120 | low |
| 345 | Verity | 1,800 | 2 / 5 | watch |
| 371 | Fernwood | 4,400 | 14 / 15 | low |
| 398 | Lumen | 15,050 | 49 / 60 | low |
| 412 | Orbis | 7,700 | 21 / 40 | watch |
- 1Postgres, as it happens. every commit through the slot, with its LSN and what it took; run a scene or your own SQL
- 2The graph, live. every model and the operators under it; a change lights only the edges it crosses
- 3Fresh, and how fresh. commit to every model current, against the same report as a plain Postgres view
- 4The view itself. the rows your app, dashboards and agents read, and the engine’s own numbers underneath
02 · Model workspace
A model is SQL you can read as steps.
Every step shows the rows it outputs. Change a step or the SQL; they stay in sync, and the SQL stays the source of truth.
eddymodel · account_healthLive⌘Kreview change
Reads
stg_accounts
mrr
seat_utilization
usage_daily
Stagesusage_30d · cte
final query
Read byexpansion_candidates
Servededdy.account_health
usage_30d
final query
| account_id | name | used | seats | events_30d |
|---|---|---|---|---|
| 42 | Northwind | 39 | 40 | 1,904 |
| 57 | Contoso | 14 | 40 | 31 |
| 88 | Glenmore | 71 | 80 | 2,377 |
Step · left join
Keeping it fresh
u.account_id=a.account_id
risk · case
| when | events_30d < 50 and used·2 < seats | 'high' |
| when | events_30d < 200 | 'watch' |
| else | 'low' |
operators6 · 2 sharedstate18.4 MB on S3per tick0.31 ms
22% of this tenant’s tick
with usage_30d as (
select account_id, sum(events) as events_30d
from usage_daily where day > current_date - 30 group by account_id)
select a.account_id, a.name, m.mrr, s.used, s.seats, u.events_30d,
case when u.events_30d < 50 and s.used * 2 < s.seats then 'high' when u.events_30d < 200 then 'watch' else 'low' end as risk
from stg_accounts a join mrr m using (account_id) join seat_utilization s using (account_id)
left join usage_30d u on u.account_id = a.account_id
- 1Where it sits. what the model reads, its stages, and what reads it
- 2Every step, with its rows. the query read top to bottom, each step checked by the planner
- 3The step, opened. conditions as rows, a CASE as a table, and what it costs to keep fresh
- 4The SQL stays the truth. an edit to a step is a splice of the text it changes, never regenerated
03 · Review
Know what a change does before it ships.
Both definitions run over the data as it is. You see the rows that would move, what rebuilds, and how long it takes — then apply it while everything keeps running.
eddyreview · replace account_healthLiveby you
− case when u.events_30d < 50
+ case when u.events_30d < 80
+ case when u.events_30d < 80
Rows compared3,208both definitions, run by Postgres
Changed41risk moves watch → high
Unchanged3,167
Build2.8 sat this tenant’s measured rate
| w | account_id | name | events_30d | risk |
|---|---|---|---|---|
| −1 | 164 | Brightline | 66 | watch |
| +1 | 164 | Brightline | 66 | high |
| −1 | 201 | Kestrel | 72 | watch |
| +1 | 201 | Kestrel | 72 | high |
| −1 | 345 | Verity | 58 | watch |
| +1 | 345 | Verity | 58 | high |
Rebuilt after it
The graph
account_healthreplaced
expansion_candidatesreads it
operators added2replaced2shared, kept4
Replace account_health
Command 311
queuedhydrating · the tenant keeps tickingready · judged by Postgres on its first change
- 1The edit. one condition changed, in the model’s own SQL
- 2What it does to the data. both definitions run by Postgres over the tables as they are, compared row for row
- 3The rows that move. every account whose answer changes, before anything changes
- 4Applied while it runs. the build happens beside the running tenant, and Postgres judges it from its first change
04 · Provenance
Every number explains itself.
Click a row and eddy walks it back through the joins and aggregates to the source rows that made it, lighting the path on the graph.
eddyprovenance · account_healthLiverow 57 · Contoso
lensprovenancethe path this row came by, read from each operator’s own state
viewaccount_health
| account_id | name | used | events_30d | risk |
|---|---|---|---|---|
| 57 | Contoso | 14 | 31 | high |
the row you clicked
aggregateusage_30d · group 57
| account_id | events_30d |
|---|---|
| 57 | 31 |
1 group, from 30 days of usage_daily
joinseat_utilization · key 57
| account_id | used | seats |
|---|---|---|
| 57 | 14 | 40 |
1 row under the key
sourceseats · account 57
| w | id | account_id | removed_at |
|---|---|---|---|
| −1 | 15 | 57 | Sep 22 14:02 |
| −1 | 16 | 57 | Sep 22 14:02 |
| −1 | 17 | 57 | Sep 22 14:02 |
14 found · 3 shown
sourceusage_events · account 57
| event | user | at |
|---|---|---|
| report.viewed | u_1182 | Sep 25 09:14 |
| export.run | u_0413 | Sep 24 16:40 |
31 found · 2 shown · from Kafka
- 1Click any row. in any view, and the lens walks the plan back to the tables
- 2The path, lit. only the operators this row came through; the rest of the graph dims
- 3Real rows at every step. read from each operator’s own state, never a summary
- 4Down to the source. the fourteen seats removed on Sep 22 — the answer to “why is this high?”
05 · Trace
One transaction, end to end.
Follow a single commit from Postgres through each operator it reached to the views it changed, each one judged by Postgres.
eddytrace · tick 2,418Livelsn 0/3A21F08
1 · the commit
xid918,442lsn0/3A21F08took7 ms to every view
delete from seats where account_id = 57 and id > 14;Remove seats · run from this page
2 · through the WAL
every other table: no rows
seats−14
| w | id | account_id | role |
|---|---|---|---|
| −1 | 15 | 57 | viewer |
| −1 | 16 | 57 | viewer |
| −1 | 17 | 57 | editor |
| … |
3 · the tick, wave by wave
4 of 64 operators did work · 0.9 ms
stg_seats−14wave 1 · filter · project
seat_utilization−1 +1wave 2 · aggregate by account
account_health−1 +1wave 3 · join
expansion_candidates−1wave 3 · join · filter
4 · views that changed
seat_utilization✓ agrees
account_health✓ agrees
expansion_candidates✓ agrees
9 views unchanged- 1The commit. as Postgres saw it: transaction, position, SQL
- 2The rows it carried. per table, each with its weight: a delete is −1
- 3Only what it reached. the operators that did work, in order, and what each emitted
- 4Judged. every view that changed, recomputed by Postgres and compared
06 · Customers
A thousand customers, each on its own.
Shared tables in, a store per customer out. See which customers are busy, what each one costs, and read any one of them alone.
eddycustomers · a tenant per customerLive1,000 customersone slot
Most active firsttenant column · account_id
| account_id | name | rows served | store | ticks / h | last hour |
|---|---|---|---|---|---|
| 131 | Meridian | 1.9M | 58 MB | 412 | |
| 322 | Ashgrove | 1.1M | 31 MB | 377 | |
| 88 | Glenmore | 842k | 22 MB | 301 | |
| 42 | Northwind | 610k | 17 MB | 288 | |
| 398 | Lumen | 402k | 11 MB | 240 | |
| 233 | Halden | 377k | 9.8 MB | 203 | |
| 164 | Brightline | 291k | 7.6 MB | 177 | |
| 412 | Orbis | 188k | 4.1 MB | 131 | |
| 57 | Contoso | 164k | 3.9 MB | 118 | |
| 287 | Corvid | 120k | 2.7 MB | 96 | |
| 201 | Kestrel | 96k | 2.2 MB | 71 | |
| 301 | Tallis | 61k | 1.4 MB | 52 | |
| 371 | Fernwood | 33k | 720 KB | 31 | |
| 103 | Inkwell | 19k | 440 KB | 18 | |
| 345 | Verity | 6k | 160 KB | 4 |
… 985 more · median store 440 KB
customer 42
Read this customer alone
Only Northwind’s rows, from Northwind’s own store. Postgres judges every customer’s share alone.
Northwind
own storeshops/42
own position0/3A21E40
state17 MB
rows served610k
GET /api/views/account_health?shop=42
| account_id | name | mrr | risk |
|---|---|---|---|
| 42 | Northwind | 14,420 | low |
- 1Every customer, one row. the most active first: rows served, store size, ticks
- 2Its own state. a store and a position in the log per customer, one replication slot for all
- 3Read one alone. the same API, scoped to one customer, from that customer’s store
07 · Agents and SQL
Read it from an agent, or from psql.
The same live views over MCP for agents and over the Postgres protocol for everything else. An agent can act through your own API and read the result on its next step.
Agentconnected: eddy · acme-saas (MCP) · admin-apireader
Which accounts are at risk this week, and why?
select account_id, name, mrr from eddy.account_health
where risk = 'high' order by mrr desc limit 5
→ 2 rows · Contoso 8,900 · Norrland 2,900{ "view": "account_health", "row": { "account_id": 57 } }
→ seats: 14 rows removed Sep 22 · usage_events: 31Contoso is the largest. Usage fell to 31 events after 14 seats were removed at 14:02 on Sep 22, all in one statement by one admin — it looks like a mistaken bulk removal. I’ll restore them.
{ "account_id": 57, "removed_at": "2026-09-22T14:02" }
→ committed · 14 seats{ "view": "account_health", "where": "account_id = 57" }
→ used 28 / 40 · risk: watch · as of the commitAsk about any metric…
psqlhost=eddy.acme.internal · the Postgres protocol
acme=> \timing on acme=> select account_id, name, mrr, risk from eddy.account_health where risk <> 'low' order by mrr desc limit 6; account_id | name | mrr | risk ------------+------------+--------+------- 164 | Brightline | 12,800 | watch 57 | Contoso | 8,900 | watch 201 | Kestrel | 6,250 | watch 103 | Inkwell | 3,600 | watch 260 | Norrland | 2,900 | high 345 | Verity | 1,800 | watch (6 rows) Time: 0.4 ms acme=> select count(*) from eddy.mrr_by_plan; count ------- 4 (1 row) Time: 0.2 ms
See it on your own schema.
Tell us a metric you’d want live. We’ll show it running, with every step visible.