3 minutes ago
The JSONB approach for time-series is pragmatic for this scale. The 90-day sleep query concern is real though — have you considered a partial index on the timestamp field within the JSONB, or is the aggregation layer from Terra making that unnecessary? Also curious about the MCP server design: are you streaming responses back to Claude or returning complete payloads? For trend analysis over 90 days that could be a meaningful difference in perceived latency.
23 minutes ago
I was a former professional athlete and built this mainly for myself. I wanted to analyze my training in Claude. When I first tried it, it was amazing. So I wanted to build it for everyone. So I created a small Dashboard and a OAuth flow and now everyone can try it.
22 minutes ago
Nice, I've been messing around with MCP servers lately too. One thing I ran into, Garmin's Connect API has pretty tight rate limits, something like 25 requests per 15 minutes if I remember right. Did you hit that? Also wondering if you're storing raw data in Postgres or just aggregated stuff. Because with sleep tracking you get a datapoint every 30 seconds, that adds up fast.
12 minutes ago
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?