Pricing

Pay for the work your data does, not for servers.

eddy counts the rows each step of your SQL processes, whether it is keeping a model current or answering a query. That count, and the state your models keep, is what we intend to charge for. No compute sizes, no idle hours, no rebuilds.

Early access: this is the shape of our pricing, not a price list. Rates are agreed with each early-access team and will be published here.

Two meters

Rows processed, and state.

One unit for keeping models current and for reading them, and one for what they store.

Meter 1 · models

Rows processed

Every row a step handles to keep a model current: the changes that reach it, and the stored rows it reads to apply them.

Joins, aggregates and windows count; filters, projections and casts are free. A step two models share is counted once.

Meter 1 · queries

The same, for queries

Every row an ad hoc query, a dashboard or an agent’s read handles.

One customer’s page counts that customer’s rows, not the whole view’s. A query over a whole model counts the model’s rows, which are already joined and aggregated, not your raw tables’.

Meter 2

State

What your models keep, per GB-month.

Held in object storage, not memory. An idle customer’s state stays there and costs only this until their next write wakes them.

Two changes, counted

Not every change costs the same.

Rows processed follows the data, not the number of changes. A refund touches one order and one plan. Moving an account to a new plan moves every one of its orders, and the count says so.

An order is refunded orders 88213 · status → refunded

joinaccounts2 in · 1 read3
wherestatus <> 'test'filterfree
group byplan2 in · 1 read3

revenue_by_plan= 6 rows processed

An account moves plan accounts 417 · pro → enterprise

joinits 4,812 orders2 in · 4,812 read4,814
wherestatus <> 'test'filterfree
group byplan9,624 in · 2 read9,626

revenue_by_plan= 14,440 rows processed

Before you create it

See the cost of a model before it exists.

The preview your agent or your team runs before every change lists each step, whether it keeps state or is already paid for by another model, and the rows it would keep, so a fan-out is visible before it happens. When a shape costs more than it needs to, it says so, with the rewrite.

claude · eddy

› cost of revenue_by_plan?
● eddy · model_steps_cost
  step              keeps
  join accounts     48,120 rows
  where status      free
  group by plan          3 rows
  2 new stateful steps, 0 shared
  48,120 orders over 10 accounts:
  a plan change moves ~4,800 rows.

Queries

Ad hoc queries count the same way.

Your app, an analyst and an agent read the same live models over Postgres, HTTP or MCP. Each read counts the rows it handles, so a small question costs little and one asked every minute adds up.

Your app, one customer’s page

select day, active_seats, mrr
  from eddy.account_daily
 where account_id = 417
   and day > current_date - 30

30that customer’s rows

An analyst, once

select plan, sum(mrr)
  from eddy.account_health
 group by plan

6,4163,208 read, 3,208 aggregated

An agent, every minute

select account_id, mrr
  from eddy.account_health
 where risk = 'high'

4.6Ma day: 3,208 a run, 1,440 runs

The third is a question asked on a schedule. Created as a model, it processes only what changed, and reading it becomes the first kind of query. The preview shows both numbers, so you can choose.

What you don’t pay for

No meter on the things warehouses bill for.

No compute sizesNo clusters, warehouses or node types to pick, and nothing to scale up for month-end.
No idle hoursNothing runs up a bill while nothing changes and nobody reads. Quiet customers are evicted to storage.
No recomputeA model processes what changed, once. It is never rebuilt on a schedule.
No per-customer feeA thousand customers cost what their rows and their state cost, not a thousand of anything.
No seatsEvery developer and every agent on the workspace.

Questions

Pricing questions.

Why not charge for compute, like a warehouse?

A warehouse’s work is a query over all the data, so the hours its cluster runs are a fair proxy. eddy’s work is what a change touches, and what a query reads, not the size of your data or how long anything was switched on. Charging by the hour would bill you for our servers rather than your workload. Rows processed is also the same number every time for the same data and SQL, which CPU time never is.

Why can one change cost thousands of rows?

Because it really does that much work. A change to a row many others join to, such as an account, a plan or a product, has to move every row that joined it. That is fan-out, and it is the cost of any system that keeps a join correct under updates. eddy shows it per step, per model, so the model and the change responsible are never a mystery.

How do I know what a model will cost before I create it?

Every model is previewed before it’s applied. The preview lists each step, whether it keeps state or is shared with a model you already run, and the rows it would keep, so you can see how far a change to a popular row fans out. It also flags the shapes that cost more than they need to, such as a window with no PARTITION BY, a join with no equality or a LIMIT, and gives the cheaper rewrite.

Are dashboards and API reads metered?

In the same unit. A read that asks for one customer’s rows counts that customer’s rows, so a product serving each customer their own page pays for the rows it serves. There’s no separate price for the Postgres endpoint, HTTP or MCP.

When should a query be a model?

When it runs often. A query processes everything it reads, every time; a model processes only what changed and is then read like any other view. A question an agent asks every minute is usually cheaper as a model.

Is the first load billed?

A model’s first build processes the rows it reads once, like any other rows. The preview says how many rows a build would read before you create it.

Can I cap the bill?

Early-access workspaces are agreed with each team, including a ceiling. Every workspace shows rows processed and state per model and per query, live.

When will rates be published?

When hosted workspaces are self-serve. Until then we agree terms with each early-access team, on this shape.

Keep going

SaaS engineering teamsAnalytics inside your productPer-customer metrics your app serves, live, with no warehouse.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.

Get early access.

Leave a work email and a founder replies within two business days. We onboard every team by hand and agree terms on this shape, with a ceiling.

Get early access See the product