Listening for events…
← All Docs

Stage 1 findings — Mike's new box vs. TerraPulse footprint (2026-06-26)

Recon complete. Inputs for the Stage 1 topology decision (Brad + Claude, tomorrow night).

Mike's new box (mike, 192.168.1.241)

  • CPU: Intel Celeron N5095A, 4 cores / 4 threads, 2.0–2.9 GHz, x86_64. Low-power mini-PC class. Has AES-NI, VT-x. Modest — fine for services, weak for a 377M-row spatial DB under load.
  • RAM: 15.6 GB total + 4 GB swap. Idle (~640 MB used). Healthy headroom.
  • Disk: 954 GB NVMe. Only 100 GB carved into the root LV (85 GB free); ~850 GB sits UNALLOCATED in the LVM volume group — claimable with lvextend. So real usable capacity is ~935 GB once expanded.
  • OS: Ubuntu 26.04 LTS, kernel 7.0. Fresh.
  • Installed: near-clean slate. python3 = 3.14.4 (system; TerraPulse uses 3.13 via pyenv — mismatch to resolve), git, curl, wget, systemd 259. Absent: postgres, postgis, pyenv, node, npm, nginx, gcc/make, duckdb, docker. Clean = good.
  • Sudo: yes, password required (no passwordless).
  • Net: wired enp3s0 192.168.1.241/24, gw 192.168.1.1, public IP 73.144.161.59 (residential). Wi-Fi down (good, wired).

TerraPulse footprint (what has to move)

  • PostgreSQL: 186 GB (377,883,290 observations). This IS the migration — everything else is rounding error.
  • data/ (DuckDB staging + rosters + caches): 3.2 GB. location_storehouse: 1.6 MB.

The decisive question: link speed between the boxes

  • Internet path measured ~4.5 Mbit/s (≈0.56 MB/s). Moving 186 GB over that = ~92 hours (~4 days). Not viable as a dump/restore.
  • Possible fast local path, UNCONFIRMED: the TerraPulse box has a USB NIC at 192.168.1.100/24 — same subnet as Mike's box and the gateway. A route to 192.168.1.241 exists via that NIC, but a direct ping did not answer. If a real gigabit local link exists, 186 GB moves in ~30 min instead of 4 days. Brad to confirm the L2 topology — this is the single biggest lever on Stage 3.

Implications for the topology call (for tomorrow)

  1. Disk is fine once we lvextend into the spare ~850 GB. 186 GB DB fits with room.
  2. CPU is the real constraint. A Celeron N5095A running a 186 GB PostGIS DB + 60s ingestion + API + SSR concurrently will work but won't be fast on heavy spatial queries. Argues either for (a) accept-modest-perf full clone, or (b) distribute: keep the heavy DB on the strong box, run a read-replica or lighter services on Mike's.
  3. Data transfer is gated on the link question. If no fast local path: ship a physical disk, OR use PG streaming replication (slow initial sync, then self-heals), not a one-shot dump over the WAN.

Candidate topologies to weigh tomorrow

  • A — Full clone: entire stack on Mike's box. Simple, independent. Limited by Celeron + transfer.
  • B — Warm replica: Mike's box runs a PG streaming replica + standby services; strong box stays primary. Failover/redundancy. Initial sync still needs the link.
  • C — Split services: PG stays on the strong box; Mike's box runs web/API/ingestion against it. Only works if there's a fast, reliable link between them.
Live Feed