Good distinction, but the 90-day trend queries actually don't touch JSONB at all, because trends hit scalar columns (avg_hrv, duration_seconds, start_time) where a regular B-tree index is sufficient. The JSONB arrays are only used for sample-level queries like "show me my HR during last night's sleep" which are inherently single-session lookups, not range aggregations.

On streaming: currently returning complete payloads. For this use case it hasn't been a problem, because the trend queries aggregate 90 rows of scalar data which is fast, and the response is compact text. Streaming would make sense if I were piping large sample arrays directly, but those get aggregated server-side before returning. Worth revisiting if I add something like full workout trace exports.

Thanks, yes I also saw the Garmin MCP and I also tried the TrainingsPeaks MCP. I have a Polar Watch so I needed to build something for myself. I use Terra API for my Data Pipeline. So they normalize and aggregate my Data (so Terra handles all provider-specific rate limits). Storage is a mix, every workout, sleep or daily record gets its own with row extracted summary fields as typed columns (HR, HRV or duration) plus the raw time-series stored as JSONB arrays.

Your point about sleep tracking is real but the JSONB arrays compress well in Postgres and a night's worth of 30s data is 1-2K data points, so it's manageable. The bigger concern is the query performance when you need 90d of sleep data. what MCP Servers have you tried out, something similar?