PR #1145, merged on 2026-05-06 by @gmorgachev, replaces the single-file SQLite devshard store with a partitioned Postgres backend. The change is drop-in: SQLite-only deployments need no config change, and new binaries auto-migrate the legacy database on first boot.

Devshards are the per-host storage layer used by the inference subnet — they hold session state, signed diffs, and threshold signatures during an epoch. Until this PR, every host kept that data in a single file, /root/.dapi/data/devshard.db, that grew without bound. Operators running hosts long enough were watching that file accumulate state from epochs months past, with no built-in way to reclaim space.

What changed

  • A new ManagedStorage layer ticks every 30 seconds, computes cutoff = max_observed_epoch + 1 - retain (default retain=3), and prunes everything older.
  • Postgres is now a first-class backend. Three new tables — devshard_sessions, devshard_diffs, devshard_signatures — are each PARTITION BY RANGE (epoch_id). Partitions are created lazily as new epochs arrive; pruning drops the old partition outright.
  • A HybridStorage mode keeps Postgres as the primary backend with a SQLite local fallback during outages. Per-escrow stickiness ensures a session always reads from the same backend.
  • Mode is controlled by the PGHOST environment variable. Unset means SQLite-only and behaves exactly as before. Set means hybrid mode, sharing the same env-var convention as the existing payloadstorage module.
  • Legacy /root/.dapi/data/devshard.db is migrated to the new devshard/ directory on first boot and renamed *.migrated.<unix>. The migration is idempotent across restarts.

The PR adds 5,486 lines across 51 files, with no schema, proto, HTTP, or gossip changes — strictly per-host storage internals.

Why it matters

Two practical consequences for host operators. First, disk usage stops growing forever. The 30-second pruner with retain=3 keeps three epochs of state on disk and discards the rest, so a host that has been online for months no longer carries devshard data from months ago. Second, hosts that already run a Postgres instance for payloadstorage can point devshard storage at the same database with one env-var change, getting partition-aware queries and operational tooling without spinning up a separate store.

Tradeoffs and follow-ups

For simplicity, partitioning is by epoch_id only, not (epoch_id, escrow_id). Loading a session reads its diffs from the shared epoch partition, indexed on escrow_id. The PR description flags per-escrow state snapshots as the next step.