Point Nineveh at your contract's address. Get a database and an API that stay in sync with the chain — sorted, filtered, aggregated, live. No indexer to write, nothing to run.
What is X right now? One account's balance. One listing by id. It can't sort, total, join or give you a feed — and the data your app needs isn't even in storage. It lives in events and write sets, because keeping totals on-chain costs gas on every transaction.
So every team writes an indexer: a processor, a database, a server, a deploy pipeline. A week of work, and something to maintain forever. Nineveh is that week, done.
Show me all of them, sorted
Top players. Cheapest listings. Biggest holders.
What happened?
A feed. A history. This user's last twenty actions.
How much, in total?
Revenue per seller. Volume per day. Count per account.
No processor to write, no migrations, no schema to keep in step. Change a rule and Nineveh rebuilds the table from history in the background, then swaps it in — the old data keeps serving the whole time.
nineveh.yaml
# nineveh.yaml — the whole backend
sources:
sold: { event:"0x…::market::Sold" }
state:
sellers:
key: [seller]
columns:
seller: address
sold: { type: u64, default: 0 }
revenue: { type: u64, default: 0 }
reduce:
- on: sold
set:
sold:"sold + 1"
revenue:"revenue + price - fee"
your API, a second later
GET /v1/tables/sellers?order=revenue.desc&limit=2
{ "rows": [
{ "seller": "0x7a3f…c41d",
"sold": "128",
"revenue": "94210" },
{ "seller": "0x1e87…8d2a",
"sold": "91",
"revenue": "63880" }
],
"count": 4 }
Wide integers come back as strings, because a u128 doesn't fit a JavaScript number. Every table gets the same treatment, plus a live change feed and signed webhooks.
Four steps, and none of them are yours
1
The chain pushes
Nineveh sits on Aptos' transaction firehose. Every transaction arrives in order as it commits — no polling, no cron, nothing to schedule.
2
It decodes what you follow
Each transaction carries its events and its write set — the exact storage slots it changed. That's why resources and tables work, not just events.
3
It folds
Records run through your rules. Everything from one transaction lands in a single database write, with a bookmark saying how far it got.
4
You query it
REST over every table, with filters, sorting and paging, plus a live change feed and signed webhooks.
In order
A balance that goes 5 → 12 → 7 lands as 7, never as 12.
Exactly once
Rows and cursor commit together, or neither does.
Crash-safe
A restart resumes from the cursor. Nothing counted twice.
Exact arithmetic
Move's integers, checked. A bad rule halts; it never corrupts.
One plan, no card. The limits are real numbers the backend enforces, not a trial that expires — when you reach one, it tells you which and what it means.
