atanasovskib

The article reads like

1. Version 1

2. Version 2

3. We didn’t bother with the rest

I guess for now you shouldn't worry unless you plan to join/co-found an extra-early stage startup

So 7?

There are a lot of differences that need to be taken into account before making a comparison.

1. TimescaleDB implements the compression on a hifher level, the underlying table storage/access method remains the same

2. TimescaleDB doesn't compress latest data, allowing you to keep fast writes and edits for recent data, but also allows you to benefit from compression on row based data

3. Although not currently available, it is possible to have a TimescaleDB hypertable with a column based access method

4. Comparing would have to take into account the data model, access methods (types of queries), ingestion vs query comparison (batch vs real time), backfilling and editing, etc

I agree that this (Columnar) would be closer to Parquet.

In my opinion it would be very hard to justify using Timestream for any analysis heavy workloads for at least three reasons:

1. Queries will need to touch a lot of data - will cost a lot, and there is no ability to optimize the queries in any way (no EXPLAIN, no indexes, no downsampling)

2. No integration with data exploration and visualization tools

3. No ability to have non-timeseries data, or correlate any data in two different tables (no JOINs)

(Disclaimer: I work at TimescaleDB)

The blog post links to a comparison done by the CrateDB folks (https://crate.io/a/amazon-timestream-first-impressions/)

I would suggest checking out other smaller cloud providers for managed databases over Aurora. Check out Aiven.io

I replied to the parent comment. In short yes, it is supported (https://docs.timescale.com/latest/using-timescaledb/continuo...)

I think what you are referring to is the TimescaleDB real-time aggregates https://docs.timescale.com/latest/using-timescaledb/continuo...

It allows you to define aggregations that are automatically used when quering the raw table if the query matches, and it also allows you to drow the raw data with a retention policy but keep the aggregated form (https://docs.timescale.com/latest/using-timescaledb/continuo...)

The Hypertables and Distributed Hypertables can be used to store any kind of data, but works best as long as it has a monotonously increasing partitioning key (e.g. time), with high ingest load, few data modifications (preferable bulked)

The beauty of TimescaleDB being built on Postgres is you can have your regular Postgres tables (OLTP schema) and time-series data (Hypertables) live side by side. Use 1 language (1 mindset) to query them, join them, work with them as you see fit. With Distributed Hypertables (what the post is about) you can now partition your data to live across multiple servers, and still use your 1 mindset to query all that data.

edit: With the preferred workload you get the most out of TimescaleDBs advanced features like compression, continuous aggregates and data retention policies. You can use the aggregates to build complex auto-updating materialized views that are automatically used even when you query the raw tables also (https://docs.timescale.com/latest/using-timescaledb/continuo...)