Story: Compute grid analysis (BOINC-based)
Table of Contents
This page documents a story in Sprint 10. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
First-pass design for a BOINC-style distributed compute grid for running ORE / ledger / LLM workloads across multiple locations.
Status
| Field | Value |
|---|---|
| State | BACKLOG |
| Parent sprint | Sprint 10 |
| Now | Postponed in sprint 10; carried forward. |
| Waiting on | A sprint with the slot. |
| Next | Return alongside the related work. |
| Last touched | 2026-01-27 |
Continued in: Compute grid implementation (sprint 15) — the design lands end-to-end (with NATS JetStream replacing the PGMQ assumption from the original analysis).
Acceptance
- BOINC lexicon mapped to our domain.
- Postgres state-machine entities sketched.
- PGMQ for hot dispatch; TimescaleDB for telemetry.
- Constraints documented.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| BOINC-based compute grid analysis | BACKLOG | 2026-05-19 | Design pass for a distributed compute grid: Postgres as central state machine, PGMQ for hot dispatch, TimescaleDB for telemetry. Entities sketched: hosts, apps + app_versions, workunits, results, batches + batch_dependencies, assimilated_data (hypertable). |
Decisions
- Postgres as the central state machine
- we already operate Postgres heavily; one fewer system to learn.
- Postgres BYTEA for input/output bundles
- sub-optimal but sufficient until we hit resource issues.
Out of scope
- Actually implementing the compute grid — analysis only.
See also
None.