
TimescaleDB 1.0 Is Production Ready - ScottWRobinson
https://blog.timescale.com/1-0-enterprise-production-ready-time-series-database-open-source-d32395a10cbf
======
msiggy
I'm excited to give this database a try if I can find some free time.

------
valyala
TimescaleDB is great for storing time series comparing to vanilla ProstgreSQL!

Unfortunately it sometimes looses in storage cost-effectiveness comparing to
competing TSDBs - [https://medium.com/@valyala/when-size-matters-
benchmarking-v...](https://medium.com/@valyala/when-size-matters-benchmarking-
victoriametrics-vs-timescale-and-influxdb-6035811952d4)

------
zip1234
How fast is it when it has a TB of data? I realize that this is affected by
the machine it is running on, but just curious how long those sample queries
in the docs would take to run.

~~~
nevi-me
I spent about 8 months writing data to TSDB. I was sending about 200 vehicle
locations per 7-10 seconds for most of the day. I guess around 1 million
events per day.

I played around with the data in the first week of setting it up, but then I
ignored the feed for months.

When I came back on the 8th month, I couldn't get many/most queries to run in
decent time. I didn't diagnose the issue, but I stopped the data stream and
archived the database. My data was around 100GB, and I was reading it from a
server-grade HDD. (I'll update my answer if I can find more accurate details
when I get home).

I don't think it was a TSDB issue, might have been on my side. If I can
restore my old data into a fresh DB, I'm going to try TSDB again with the
data. I'm doing a Stats degree part time, so it'd be interesting to apply some
forecasting knowledge to my dataset.

------
athenot
It would be nice if they did a quick comparison to InfluxData and other time
series databases.

~~~
RobAtticus
We do have comparisons, but judging by their Medium read times some may not be
considered "quick" :)

* Influx: [https://blog.timescale.com/timescaledb-vs-influxdb-for-time-...](https://blog.timescale.com/timescaledb-vs-influxdb-for-time-series-data-timescale-influx-sql-nosql-36489299877)

* Cassandra: [https://blog.timescale.com/time-series-data-cassandra-vs-tim...](https://blog.timescale.com/time-series-data-cassandra-vs-timescaledb-postgresql-7c2cc50a89ce)

* Mongo: [https://blog.timescale.com/how-to-store-time-series-data-mon...](https://blog.timescale.com/how-to-store-time-series-data-mongodb-vs-timescaledb-postgresql-a73939734016)

We also released a tool called Time Series Benchmark Suite (TSBS) here that
someone just submitted a PR for Clickhouse:
[https://github.com/timescale/tsbs/pull/26](https://github.com/timescale/tsbs/pull/26)

There is also this spreadsheet that compares a bunch of different time series
databases, including TimescaleDB:
[https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCE...](https://docs.google.com/spreadsheets/d/1sMQe9oOKhMhIVw9WmuCEWdPtAoccJ4a-IuZv4fXDHxM/pubhtml)

Hopefully some of that is useful :)

~~~
athenot
Thanks a lot, this is useful for comparing.

Edit: did a quick search and the discussion for the first link is here:
[https://news.ycombinator.com/item?id=17766566](https://news.ycombinator.com/item?id=17766566)

------
dominotw
I evaluated this heavily but had to backoff because scale is limited to a
single machine. Really eager for their clustering solution.

~~~
RobAtticus
Sorry to hear, though I'd like to mention that there is a fair amount of scale
you can get out of a single TimescaleDB node. We scale with disk space so you
can throw more disks at it; we have production users who are in the hundreds
of billions of rows and 10s of TB of data on a single node. Also with support
for streaming replication you can spread out your read load and get HA
support. But yes, we will have more to say in the coming months about
clustering though.

~~~
grumpydba
Hi,

are the upcoming clustering efforts developed with the intent to be mainlined
in postgresql ?

Indeed some way to automatically failover/failback (ie automate pg_rewind)
without all the keepalived/pacemaker/haproxy/patroni stuff is really needed.

------
sman393
Can this be used side by side on normal Postgres cluster? As in could I have
one DB for app data, and one for metrics data? Considering switching from
MySQL (ndb cluster) to running a Postgres cluster and this could be a good
motivator.

~~~
RobAtticus
Yep, absolutely. Regular PostgreSQL tables coexist alongside TimescaleDB
(hyper)tables in the same database. We believe that's actually a pretty big
plus since you can keep metadata that you may need to join on your metrics
data without doing it in an application layer.

~~~
sman393
Good to hear! how does the current TimescaleDB single node limitation play
into it?

~~~
RobAtticus
Not sure I follow exactly what you're asking. You can do read replicas for
HA/failover/read sharding which you can do with regular PostgreSQL databases
as well. So at least on the axis TimescaleDB presents no limitations.

~~~
sman393
Alright thanks! I thought I read that TimescaleDB doesn't support clustering
yet, only single node Postgres installs, But I could've misunderstood it.

~~~
RobAtticus
It does not support sharding writes across multiple nodes, but we do work with
streaming replication so you can set up read replicas (and for failover).

