"Time-series data is just data where every record has a "time" field. That's it."

That's a pretty big simplification. It's like saying one could go running in dress shoes. (Yes, it's possible, but don't you want to use the right tool for the job?)

As one time-series database example, because TimescaleDB [0] is focused on time-series data, its users benefit from [1]:

* 40-50x compression for metrics data (so storage costs for compressed data are 2-2.5% what they would normally be)

* Versatile continuous aggregate policies

* Variable data retention policies

* Overall much more efficient compute and memory utilization (because of faster insert and query rates)

* And yes, also time-based query operators for gap filling, first/last, LOCF, etc

(And I'm sure roskilli could describe M3DB's own advantages over non-time-series DBs.)

[0] Disclaimer to other readers, I'm a co-founder (although OP already knows this, as we've jousted on HN before :-) )

[1] All of our benchmarks and other engineering notes are published here: https://blog.timescale.com/tag/engineering/

I'd say you started with a standard RDBMS and added the other features like sharding, column-oriented storage, time-series helper functions to SQL, and more to it to end up similar to the other native column stores but with a more flexible and popular Postgres frontend.

At the very least, I think we both agree that the relational/SQL options work just fine compared to limited time-series databases like Influx. And for the record, we do use timescale so you've won me over on the PG usability front.

"And for the record, we do use timescale so you've won me over on the PG usability front."

Great! Didn't realize that.

And yes, I would agree that a relational/SQL time-series database like TimescaleDB can work quite well. :-)

It seems clickhouse also has most of those features, but is not considered a time series database. Is that wrong?