ensdb-cli & ENSDb snapshots

The problem

Completing a full historical indexing backfill of ENS from zero is expensive on two axes: time and money. A full historical indexing backfill of ENS across mainnet, Basenames, Lineanames, 3DNS, ENSv1, ENSv2, etc generally means days of indexing and a heavy RPC bill - every request to your RPC provider, multiplied by every chain, multiplied by every block of 9+ years of ENS history you have to index. That tax is painful for anyone building, prototyping, demoing, or testing.

ENSDb already gives you the live, onchain state of ENS in a plain PostgreSQL database that any language with a Postgres driver can read. The next step is making it trivial - and cheap - to bootstrap and operate that database. That’s what ENSDb snapshots and ensdb-cli are for.

What we’re building

ENSDb snapshots are portable, versioned packages of an ENSDb instance that anyone can publish or consume. Pull one down, restore it into Postgres, and start querying ENS in minutes instead of waiting days to complete 9-years+ of historical indexing backfill from scratch - and without being required to send hundreds of thousands of pricy RPC-calls yourself. When you start from a fresh ENSDb snapshot, it’s cheap and fast to catch up to realtime indexing.

ensdb-cli will be the operator-facing tool around them - the surface where you list indexer instances and their indexing status, generate fresh snapshots, inspect what configuration a snapshot was built with, and clean up schemas you no longer need.

Cut your RPC bill

Skip the historical RPC fanout entirely. Pull down a published ENSDb snapshot instead of replaying 9+ years of ENS history through your own RPC provider - saving real money on every bootstrap, every CI run, every fresh environment.

Spin up in minutes, not days

Skip the long historical backfill too. A nearly up-to-date ENS index is ready as fast as you can download it - no specially configured Postgres required, no days of waiting. Perfect for hackathons, demos, prototypes, and any other time you need a fresh ENSDb fast.

Repeatable CI environments

Use snapshots as deterministic fixtures for tests and CI pipelines. Every run starts from the same well-known ENS state, with zero RPC dependency.

Confident release reviews

Diff snapshots across ENSNode versions to catch unexpected changes in indexed data - a powerful way to validate indexing-logic refactors before a release ships.

Easier self-hosting

Bootstrap your own ENSNode instance from a recent snapshot, then catch up to realtime from there. Less time waiting, more time building.

ensdb-cli: purpose-built ops tooling

`ensdb-cli` surfaces the operations you actually need day-to-day: inspect indexer instances, manage snapshots, clean up unused schemas, and more.

Who this is for

Hackathon teams and prototypers who want a full ENSDb right now and don’t have time or money to wait days on 9+ years of an ENS historical indexing backfill.
Self-hosters standing up new ENSNode instances who’d rather start from a recent snapshot than backfill from genesis.
CI and testing pipelines that need deterministic ENS state to run repeatable assertions against.
Maintainers running release reviews who want to diff indexed data across versions to catch unintended regressions before they ship.
Anyone building specialized ENS services on top of ENSDb who needs faster iteration loops and lower operational cost.

How this complements ENSDb

Snapshots and the CLI sit on top of the ENSDb open standard. Because ENSDb is just Postgres governed by a well-defined schema, snapshots are portable: any ENSDb Writer implementation can produce one, and any ENSDb Reader (or your own code) can consume one.

This is the same foundation that powers ENSNode’s other planned ENSDb capabilities - including ENSEngine, enabling you to react to changes in ENSDb through webhooks and other event-driven strategies without need for polling.

ENSDb integration quickstart The integration point these snapshots build on - the live ENS state, ready for SQL or the ENSDb SDK.

ENSDb overview Vision, philosophy, and how an ENSDb instance works.

ENSEngine integration quickstart React to ENS state changes with webhooks & events rather than polling.

ENSEngine overview React to changes in ENSDb through webhooks and other reactive / event-based development strategies.

Self-host ENSNode Operate your own ENSNode instance to build and publish your own ENSDb snapshots.