[qrpike]

I'm not sure I would call Cassandra slow. If the schemas are done well, it can be quite good for time series. Obviously this depends on the type of time series you're writing/querying.

Our biggest goal was writes & uptime. We sometimes do over 150k writes/sec. We also needed it to be up and accepting writes even if one node goes down.

We regularly take nodes offline for updates/etc and cassandra never misses a beat.

We ~really~ wanted to use influxdb, but as a startup we couldn't justify the cost/benefit over Cassandra since we have 8 nodes for the DB. I just went to the influx site to try to find the pricing again and it seems to be hidden now :/

EDIT: As a PS, just remember every one of the influxdb benchmarks ( that I've come across ) are single node. Cassandra is meant to be horizontally scalable. Testing a single node Cassandra is like testing a racecar on your driveway...

[SEJeff]

And our influx setup does bursts of 500k writes per second with a lot less operational overhead than Cassandra. For time series data, a general purpose database is always going to be slower for both reads and writes. The data on disk and in memory is simply laid out differently.

For an excellent academic example, see this paper of Facebook's gorilla in memory TSDB:

http://www.vldb.org/pvldb/vol8/p1816-teller.pdf