perf(executor): aggregate realized PnL in SQL to cut DB egress

[Gift-Stack]

Problem

The executor settlement loop (settlement.ts) was the dominant source of Postgres egress, independent of user traffic:

• It ticks every 250 ms (~345k ticks/day, 24/7).
• Each tick, for every account with an open position, accountValue() ran SELECT * over that account's entire closed-trade history just to sum realized PnL in JS.
• So the full, growing trade history was re-transferred 4× per second, forever. One account with ~200 closed trades ≈ 40 KB/tick × 345k ticks ≈ ~14 GB/day of pure egress — enough to blow a Neon free-tier data-transfer quota on its own.

(reconcileAccount had the same SELECT *-then-reduce pattern, though only per close.)

Fix

Aggregate in SQL instead of in JS. New settledTotals() returns sum(realized_pnl) + count(*) as one row, using the existing (account_id, status) index:

• accountValue (hot path, every tick) and reconcileAccount both use it.
• The per-tick accounts read is narrowed to just starting_equity instead of SELECT *.
• Per-tick egress is now small and constant — it no longer grows with trade history. The ~14 GB/day example drops ~3 orders of magnitude.

Behavior

Identical — it's the same sum, computed in the database. The 2 settlement tests pass unchanged, plus a new db test asserts settledTotals returns sum=750.25, count=2 and excludes open positions.

The 250 ms tick interval is intentionally unchanged (it's matched to the mark feed); the aggregate alone removes the egress problem, so there's no reason to touch money-path timing.

Verification

pnpm typecheck, biome lint, executor tests (2), and db tests (5) all pass.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
ultraprop	Ready	Preview, Comment	Jun 30, 2026 12:54pm

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
ultraprop-docs	Skipped		Jun 30, 2026 12:54pm
ultraprop-website	Skipped		Jun 30, 2026 12:54pm