Research spike: storage-abstraction candidates to replace AMS's node:sqlite local-store

[JSONbored]

Problem

packages/gittensory-miner's lib/local-store.js and its siblings (run-state.js, claim-ledger.js, portfolio-queue.js, event-ledger.js) use node:sqlite's DatabaseSync with one file per machine and no tenant concept. A hosted AMS needs a shared, tenant-scoped datastore, but no comparison of realistic replacement backends exists yet, so any future storage-design issue would start from a blank page.

Area

AMS / Cloud architecture

Proposal

Produce a written comparison of realistic replacement backends (managed Postgres, D1, a KV/document store) evaluated purely against AMS's existing read/write patterns in local-store.js et al. — not a fresh green-field storage design. Cover tradeoffs on migration cost (moving off DatabaseSync file-per-machine), tenant-scoping fit, and consistency with ORB's own D1/Postgres adapter precedent (src/selfhost/d1-adapter.ts, pg-adapter.ts), so the eventual design issue can reuse an established adapter pattern rather than inventing a new one.

Deliverables

• A comparison document covering at least 3 backend options, each evaluated against AMS's actual access patterns (not generic pros/cons)
• A non-binding recommendation for the follow-up storage-abstraction design issue to consider

Resources

• packages/gittensory-miner/lib/local-store.js, run-state.js, claim-ledger.js, portfolio-queue.js, event-ledger.js
• src/selfhost/d1-adapter.ts, pg-adapter.ts (ORB's existing precedent)

Boundaries

• Research and writeup only — this issue must NOT change any schema, storage code, or the shape of local-store.js and siblings.
• Feeds the maintainer-owned storage-abstraction design issue; it does not replace it, and its recommendation is non-binding on that design.
• Blocked on (should reference, not contradict) the architecture spec issue for the reuse-boundary pattern once that lands.

[linear-code]

JSO-3742