Please stop tormenting me. This looks like exactly what we need (I was looking into manually partitioning the other day) it's just so annoying there is not yet Amazon RDS support.
Timescale, an open-source time-series SQL database for PostgreSQL
11–20 of 102 posts
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#12A project I work on has time series stats in postgres--it's essentially an interval, a period, a number of fields that make up the key, and the value. There's a compound index that includes most of the fields except for the value. It works surprisingly well, for tens of thousands of upserts per second on a single postgres instance. Easy app integration and joins are a huge plus. I'm really curious to check this out a…
In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres:
https://blog.timescale.com/timescaledb-vs-6a696248104e
tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#13Please stop tormenting me. This looks like exactly what we need (I was looking into manually partitioning the other day) it's just so annoying there is not yet Amazon RDS support.
Customer requests help the process with RDS along :)
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#14So this is based on Postgresql. How does it compared to other solutions that are written from scratch to be a time series DB like influxDB?
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#15So this is based on Postgresql. How does it compared to other solutions that are written from scratch to be a time series DB like influxDB?
We are working on benchmarks comparing ourselves to other solutions so hopefully we'll have concrete numbers on those soon. (Incidentally, we did a blog post on us vs plain PostgreSQL today: https://blog.timescale.com/timescaledb-vs-6a696248104e)
At a high level though, we do find that having native support for full SQL to be a big win. Also, if you already store metadata or other relational data that you want to combine with your time-series data, it's great to be able to use one DB instead of separate solutions. Performance wise we do believe we are competitive and in some cases much better, and we have the 20 years of stability from PostgreSQL to build on.
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#16Any SQL database can do time-series well with more functionality then the specialized stuff like influxdb which doesn't really have much reason to exist at this point.
Citus is a another good alternative and SQL Server and MemSQL also have in-memory and columnstores if you need the performance and scalability.
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#17A project I work on has time series stats in postgres--it's essentially an interval, a period, a number of fields that make up the key, and the value. There's a compound index that includes most of the fields except for the value. It works surprisingly well, for tens of thousands of upserts per second on a single postgres instance. Easy app integration and joins are a huge plus. I'm really curious to check this out a…
In a funny bit of coincidence -- we didn't post this link to HN :) -- we just published a blog post today comparing Timescale vs. native Postgres: https://blog.timescale.com/timescaledb-vs-6a696248104e tl;dr: 20x higher inserts at scale, faster queries, 2000x faster deletes, more time-oriented analytical features
And actually, if you want to run the benchmarks yourself:
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#18A project I work on has time series stats in postgres--it's essentially an interval, a period, a number of fields that make up the key, and the value. There's a compound index that includes most of the fields except for the value. It works surprisingly well, for tens of thousands of upserts per second on a single postgres instance. Easy app integration and joins are a huge plus. I'm really curious to check this out a…
Curious about your comment about "upserts" WRT time series data. When and why would you update a record in such a table?
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#19How would this work together with something like Stolon? https://github.com/sorintlab/stolon
Re: Timescale, an open-source time-series SQL database for PostgreSQL
#20A project I work on has time series stats in postgres--it's essentially an interval, a period, a number of fields that make up the key, and the value. There's a compound index that includes most of the fields except for the value. It works surprisingly well, for tens of thousands of upserts per second on a single postgres instance. Easy app integration and joins are a huge plus. I'm really curious to check this out a…
Curious about your comment about "upserts" WRT time series data. When and why would you update a record in such a table?
Not sure about parent's use case, but we've seen scenarios where users want to synchronize data from downstream (say, they are collecting data on a hub in an IoT setting, and even using Timescale both on the hub and in the cloud).
But because they don't want to keep track exactly which batches they've uploaded already (in a fault-tolerant way), they want to execute the insert to the cloud DB as an UPSERT.
So most of the time it'll actually just be inserting, but in the rarer case that the data has already been merged, the 'ON CONFLICT' side of things (in Postgres speak) can take over: DO NOTHING, DO UPDATE, etc.
As aside, turns out the constraints you'd need for upserts aren't supported by Postgres table inheritance (the typical way you do sharding), nor in PG 10 partitioning. But, we did add special support for this in our latest release :)