Tools · proposed · IntegrationLater

Mirror selected Postgres records to Arkiv — without replacing Postgres.

Not a rip-and-replace. A one-way sync of chosen records (status changes, attestations, milestones) onto Arkiv. It needs a persistent worker (category a). It's LATER because a verifiable trail only matters once mainnet exists — today the value is in the modeling, which the arkiv-from-web2 skill delivers.

Why later: A verifiable "audit lane" is weak on testnet (who trusts testnet proof?). The arkiv-from-web2 skill carries the modeling value now.

arkiv-migrationmigrationoutboxpostgreslater

Status

Later · mainnet-era

Type

Tool

Feasibility

Hard

THE IDEA

Connects to your Postgres/Supabase/Firebase, proposes an entity mapping you approve, then runs an incremental sync of the records that benefit from a public, queryable, tamper-evident trail.

The problem today

"Is one-click migration of any Postgres DB possible?" — honestly, no: Arkiv has no joins and no server ORDER BY, so a blind 1:1 table copy gives you data you can't query well. Someone must decide the entity shape, TTL, and what to mirror.
What IS feasible out of the box: introspect the schema → propose a mapping → you approve → incremental sync.
On testnet, a "verifiable record" carries little weight — this earns its keep on mainnet.

What it would do

Planner: introspects your schema → proposes entities (rows→entities, foreign keys→attributes, join tables→edge entities, a TTL policy per table) for you to approve.
Runner: outbox-style sync + backfill with checkpointing, batch sizing (via mutateEntities), dry-run, and a spend estimate.
Flags what to KEEP in Postgres (joins, private, hot paths) vs what to MIRROR (public, verifiable, queryable).

WHY IT’S A BETTER EXPERIENCE

Additive, not a rewrite — the only path a real team takes onto a new data layer.
Turns "how would I even use this?" into a concrete, reviewable mapping.

HOW IT COMPARES

Prisma introspection / Drizzle pullread a schema and generate a model — same move, targeting Arkiv entities.

Status quo (Postgres)the real competitor. We don't beat it — we ride alongside it for verifiable records.

FEASIBILITY — AND WHY THIS ISN’T HAND-WAVING

Hard to build

Outbox + chain writes need real failure recovery, and relational→entity mapping needs judgment. Ship the arkiv-from-web2 skill first; build the runner near mainnet.

Grounded in

Research frame: "sync selected verifiable records to Arkiv, do NOT replace Postgres."
Arkiv's only migration guide today is Kaolin→Braga (testnet rotation) — web2→Arkiv is an open gap.
No-joins / no-ORDER-BY constraints (which make 1-click-any-DB impossible) verified against the SDK + PR #70.

PAIRS WITH

arkiv-from-web2 arkiv-write-queue