Time-series data: TimescaleDB or InfluxDB?

Short answer: 100M rows/day in a plain MySQL table fails — because the B-tree index and full-table aggregates don’t fit in RAM. Time-series engines solve this structurally. If you think in SQL and need aggregation, the right tool is TimescaleDB.

The root problem isn’t the model, it’s scale: in time-series the data grows endlessly, the index balloons, and queries like “the average of the last 30 days” scan the whole table. A standard table can’t take it.

1. TimescaleDB auto-partitions by time with hypertables. TimescaleDB, a Postgres extension, splits the table into time-based “chunks.” Inserts and time-range queries only touch the relevant chunks; the whole-table-scan problem disappears. The index is per-chunk too, so it doesn’t crush RAM.
2. Pre-computed averages with continuous aggregates. A continuous aggregate materializes hourly/daily averages in the background. Your “historical average” query reads the ready-made rollup, not the raw millions of rows — it returns instantly.
3. Compress old chunks and keep your SQL ecosystem. TimescaleDB compresses old chunks with native compression; disk and I/O drop dramatically. And you’re still in pure SQL, JOINs, and your existing Postgres ecosystem — no new language/tool to learn.
4. InfluxDB is purpose-built but a separate world. InfluxDB is designed from scratch for time-series, but it’s a separate system with its own query language; its relational/JOIN side is weak. For someone like you who already thinks in SQL and wants aggregation, it adds friction. Reach for Influx only if you want to stand up a separate, dedicated metrics stack.

Bottom line: TimescaleDB hypertables + continuous aggregates + compression — the lowest-friction win in your scenario. Consider Influx only if you want a separate TSDB. Either way, downsample old raw data and retention-drop it; keeping raw data forever rescues no engine. The answer to “is PostgreSQL enough for everything?” in time-series: with the extension, mostly yes.