For SaaS engineering leaders

Ship analytics inside your product.

Your customers want their usage, their spend and their outcomes in your app, current to the minute they look. eddy turns the Postgres your product already runs on into that, per customer, with no warehouse in between.

See the product →

01 · The build you skip

No pipeline to own.

The usual path to in-product analytics is a connector, a warehouse, a scheduler, reverse ETL and a cache, all owned by your team. eddy is hosted: connect your database and the pipeline is ours to run.

your Postgres CDC connector warehouse dbt on a schedule reverse ETL cache metrics API eddy hosted for you your appdashboardsagents

~~hours stale · a correction waits for the rebuild~~ milliseconds · updates and deletes on the next tick

02 · Tenancy

Every customer, their own state.

Your tables hold every customer’s rows with a tenant column. eddy splits each transaction by it into a store per customer: its own state, its own position in the log, its own cost, and never another customer’s rows.

18.8 sto onboard 1,000 customers from one snapshot

6,000customer × metric checks against Postgres, all agree

0rows leaked between customers in the judged run: each customer checked on its own share

1,000 simulated customers (a Shopify-shaped test dataset) on four cores. Every customer’s rows judged alone, before and after a kill mid-commit.

03 · Your primary

Your primary database stays yours.

eddy follows the write-ahead log with a role that has REPLICATION and SELECT on the published tables. It creates one publication and one replication slot, and nothing else. Your app never queries the primary for metrics again, and the connection check confirms the slot’s retained WAL is bounded before anything is read.

04 · Serve it

Your app reads it like a table.

Views are served over the Postgres protocol and HTTP, from the pipeline’s own state. Every request reads a snapshot, so the thousandth dashboard costs what the first did and never slows your writes.

Postgres protocol · HTTP + OpenAPI · one customer’s rows alone · snapshot per read

api/routes/usage.tsany Postgres client · your workspace

// your API, serving one customer's dashboard
const eddy = new Pool({ connectionString: process.env.EDDY_URL });  // pg

const { rows } = await eddy.query(
  `select day, active_seats, events, mrr
     from eddy.account_daily
    where account_id = $1
    order by day desc limit 90`,
  [req.account.id]
);                       // a snapshot: 3–7 µs to take, never blocks a write
res.json(rows);

05 · Scale

Idle customers cost almost nothing.

eddy keeps each customer’s state in object storage with kilobytes in memory. An idle customer is evicted until their next write wakes them, so a thousand quiet accounts don’t cost a thousand running ones. You pay for rows processed and state kept, not for idle servers (pricing).

3 MiBfixed footprint per tenant before it holds data

3%of one core for five hundred idle tenants

290 msfor an evicted tenant to wake from S3 and apply its change

7 mscommit in Postgres to every metric fresh

0.09 msto read a metric; 15.7 s as a plain view

440 KBof state for the median customer

Tenancy numbers from 1,000 simulated shops on four cores; the rest from the demo dataset and eddy’s harness.

Keep going

Teams building agentsAgents that see what they changeLive metrics over MCP, provenance for every number, and changes that are previewed first.DevelopersBuild with it from your editorThe MCP server, the model lifecycle, and your workspace’s endpoints.The productSee every screen up closeThe pipeline, the model workspace, review, provenance and the trace.

See it on your schema.

Tell us the metric your customers ask for most. We’ll show it live, per customer, on your own tables.

Get early access See the product