Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Ajay from TimescaleDB here.

In general, a time-series database makes architectural decisions and focuses on capabilities for time-series data that lead to orders of magnitude higher performance and a better developer experience.

For example, TimescaleDB:

- Auto-partitions data into 100s-10,000s of chunks, resulting in faster inserts and queries, yet provides the Hypertable abstraction that allows you to treat the data as if it lives in a single table (eg full SQL, secondary indexes, etc)

- Provides Continuous Aggregates, which automatically calculate the results of a query in the background and materialize the results [1]

- Supports native compression, using a variety of best-in-class algorithms based on datatype (eg delta-of-delta encoding, Simple-8b RLE, XOR-based compression (aka "Gorilla" compression), dictionary compression [2]

- Adds other capabilities like interpolation, LOCF, data retention policies, etc, that are necessary for time-series data

- Scales up on a single node, or out across multiple nodes

There's more, but I'll stop because I don't want this to sound like marketing.

You are welcome to implement this yourself (and our docs explain how if you'd like), but most find it easier to use the database we already provide for free[3]. :-)

[1] https://docs.timescale.com/latest/using-timescaledb/continuo...

[2] https://docs.timescale.com/latest/using-timescaledb/compress...

[3] https://blog.timescale.com/blog/multi-node-petabyte-scale-ti...



Thanks for the detailed explanation, that helps a lot.

It sounds like a time-series database does in fact include some elements of ETL at the database layer. I can see how that would be helpful.


Glad to hear. I'm also available via email ajay (at) timescale.com if you have additional questions

We also have a pretty active community on Slack (4,000+ members): https://slack.timescale.com/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: