ENSDb snapshots & CLI

The problem

Standing up a useful ENS index from zero is expensive on two axes: time and money. A full historical backfill across mainnet, Basenames, Lineanames, 3DNS, and friends means hours-to-days of indexing and a heavy RPC bill - every request to your provider, multiplied by every chain, multiplied by every block of history you have to replay. Add a specially configured Postgres on the other side and the cost of “just spin up a fresh ENSDb” stops being a rounding error. That tax is painful for anyone building, prototyping, demoing, or testing - and it hits hardest in exactly the moments where speed matters most.

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 toward

ENSDb snapshots will be 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 on a fresh indexer to catch up - without sending the underlying RPC requests yourself. Then catch up to realtime from your own ENSIndexer whenever you’re ready.

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 years of chain 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 overnight wait. 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.

Operate ENSNode like a database

The planned `ensdb-cli` will surface 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 real ENS index right now and don’t want to babysit an indexer overnight.
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 Webhooks & events, which reacts to changes in your ENSDb in real time.

What this page is not

This page is intentionally light on technical specifics. There is no SDK to call yet, no CLI flag reference, no snapshot file format to integrate against. Those will arrive in dedicated reference docs once the products land.

In the meantime, the goals above are stable enough to plan around. If your project would benefit from any of them, we’d love to hear from you while the design is still flexible.

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

ENSDb overview Vision, philosophy, and what an ENSDb instance contains today.

Webhooks & events (planned) The other coming-soon capability built on ENSDb: react to ENS state changes in real time.

ENSEngine overview (planned) The planned ENSNode service that powers the capability above: watches ENSDb for changes and routes ENS-aware events to your sinks. Code name is temporary.

Self-host ENSNode Operate your own ENSNode instance - the easiest path to a self-managed ENSDb.