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.

Short answer

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. TimescaleDB’s chunks are, at heart, partitioning by time; I described how to build the same thing without the extension, using plain declarative partitioning, in the PostgreSQL partitioning answer.

Why

1. A hypertable splits the data 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. You don’t leave the SQL ecosystem. Because TimescaleDB is a Postgres extension you’re still in pure SQL, JOINs, and your existing Postgres ecosystem — no new language/tool to learn.
3. 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.

What to do

1. Turn the table into a hypertable. Install TimescaleDB and declare your time-series table as a hypertable; let the engine handle the chunking.
2. Move the averages into 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 the old chunks. TimescaleDB compresses old chunks with native compression; disk and I/O drop dramatically.
4. Reach for Influx only if you want a separate metrics stack. Without a clear reason to stand up a dedicated TSDB, don’t take on an extra query language and a second system.

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.