When you run servers, you might want to record plenty of parameters. From received packets counters, via disk io operations, to cpu load. If you want to identi

When you run servers, you might want to record plenty of parameters. From received packets counters, via disk io operations, to cpu load. If you want to identify issues with good precision, you will record _hundreds_ of counters per each server. Sticking this kind of data to relational database is not good. With couple of servers you might have millions of _writes_ per second. While the data is only read when you refresh some charts. This makes the time series db unique - they need to handle write-heavy loads, and perform well when asked to retrieve couple of parameters within defined time window. So two things: - time series db's are needed for anyone running live systems and measuring them on-the-fly - time series db's have unique access patterns, not usually optimized by more conventional databases