Funny timing... just installed 1.0 rc1 this week. Dual-writing and experimenting reading from TimescaleDB in prod currently.<p>So far it's been perfect... besides a small config issue[1] causing a crash that should have been detected when Postgres starts up, TimescaleDB gives me reliability and durability of Postgres without having to manually create partition tables.<p>What will happen when Postgres supports auto creating partition tables for declarative partitioning[2]? Will TimescaleDB still be necessary?<p>Feature request 1: when all rows of a chunk/partition table are deleted can that chunk be automatically dropped instead of having to manually run drop_chunks[3]?<p>Feature request 2: for the getting started docs, add an option to install with <a href="https://nixos.org" rel="nofollow">https://nixos.org</a><p>[1]: <a href="https://github.com/timescale/timescaledb/issues/733" rel="nofollow">https://github.com/timescale/timescaledb/issues/733</a><p>[2]: <a href="https://www.postgresql.org/docs/11/static/ddl-partitioning.html#DDL-PARTITIONING-DECLARATIVE" rel="nofollow">https://www.postgresql.org/docs/11/static/ddl-partitioning.h...</a><p>[3]: <a href="https://docs.timescale.com/v1.0/api#drop_chunks" rel="nofollow">https://docs.timescale.com/v1.0/api#drop_chunks</a>
Is TimescaleDB a good fit for events?<p>For example, we have data where each record is a tuple of (time, event, object), where the event is things like "viewed", "performedSearch", etc., and the object is event data as JSON. Let's say the object is a movie, in which case the payload might be something like:<p><pre><code> {"id": 123,
"name": "The Godfather",
"director_id": 456,
"genre": "crime"}
</code></pre>
Our reporting UI lets users do aggregations based on arbitrary dimensions, so we might do the equivalent of:<p><pre><code> select object->>'genre' as genre,
object->>'director_id' as director_id,
extract(month from time) as month,
count(*) as count
from events
group by month, genre, director_id
</code></pre>
Then we do things like pivot/nest values to display the groupings.<p>It's unclear to me whether TimescaleDB fits this use case, or whether we'd have to change how things are indexed. Right now we just index the whole object itself. Another scheme I've considered is that we could index it with the values as keys; so for example, the above event would be {"name:The Godfather": 1, "director_id:456": 1, "genre:crime": 1} and essentially represent the counts. A counting aggregation would then be rewritten as as a sum(). But it's unclear to me how you do intersections here without also creating all the permutations (i.e. something like {"director_id:456/genre:crime": 1}) beforehand.<p>We're currently using Elasticsearch for this. Performance is okay, but we're not entirely happy with it.
Just to give a little (estimated) timeline:<p>* Currently our first release candidate is available via Github and Docker<p>* We are aiming to release a 2nd release candidate next week<p>* Sometime shortly after that (1-2 weeks) we'll go final 1.0.0<p>Happy to answer any questions!
Hi, it's very interesting!<p>Do you test if TimescaleDB affect the performances of the relational part of Postgres ?
In other words, can I use TimescaleDB as my primary DB to store both my users and time series data ?
Congrats on the RC! TimescaleDB is a very neat idea, there's a lot to gain by building on Postgres.<p>There's also a very serious limitation due to that: the requirement to predefine schemas. My primary use case for a timeseries-focused db is storing system and application metrics. Using a commercial (e.g. datadog, signalfx) or open source (e.g. influxdb, prometheus) timeseries product I can submit arbitrary data. If I had to perform a schema migration every time a developer wanted to record a new metric, it would be extremely painful.<p>If this has changed since I last looked at TimescaleDB, please correct me!