Switching to 0.10.0-nightly-614a37c in combination with switching to the TSM engine resulted in a very stable InfluxDB instance. So far my only gripe has been that some queries can get pretty slow (e.g. counting a value in a large measurement can take ages) but work is being done on improving the query engine (https://github.com/influxdb/influxdb/pull/5196).
To give you an idea of the data:
* Our default retention policy is currently 30 days
* 24 measurements, 11975 series. Our largest measurement (which tracks the number of Rails/Rack requests) has a total of 28 539 279 points
* Roughly 2.3 out of the 8 GB of RAM is being used
* Roughly 4 GB of data is stored on disk
This whole setup is used to monitor GitLab.com as well as aid in making things faster (see https://gitlab.com/gitlab-com/operations/issues/42 for more info on the ongoing work).
Unfortunately, I need 2+ instances with Active/Active or failover to seriously consider anything for production which is why I've not touched InfluxDB beyond some light testing.
The input is actually much higher than that. Data points over the network look like this:
cpu_idle,host=serverA,region=uswest value=23.0 1454617920
That's actually a toy example. Most real data would probably have more tags and longer measurement names. Obviously that's much more than 3 bytes.
We persist that to disk in a write ahead log (WAL) and then later we can do compression and compactions on the data to squeeze it down to 3 bytes per point. However, that takes more than a single write against the disk to get to.
Run a load test against it. See how much network bandwidth you can use. See what your HD utilization looks like. My guess is you'll be surprised by what you see.
Is writing less than 20MB/sec of data something to brag about?