https://docs.aws.amazon.com/AmazonRDS/latest/PostgreSQLRelea...
https://cloud.google.com/sql/docs/postgres/extensions#postgr...
https://learn.microsoft.com/en-us/azure/postgresql/single-se...
Let alone AWS Aurora, AWS RedShift, Snowflake, etc
[1]: https://ideas.digitalocean.com/app-framework-services/p/pgve...
As an aside, I question timescale use case. It’s highly niche, where you need to store arrays of data, at >>1k entries per day, you can’t use batch export of the data, and the export process is largely concerned with only recent data (aka doesn’t need to incorporate future modifications of older entries).
1 years worth of 4 byte ints at 1 minute intervals is only 2MB uncompressed. Do you really need second-level or sub second resolution in the db? Cuz 2MB chunks (realistically much less) are very cheap. 2MB fits in 250 8kb pages. Many join+limit 25 queries on unclustered tables use about that much. It’s so, so cheap to process.
Last I checked, Timescale also doesn’t make it easy to combine data at different resolutions. If you store 10ms, 1m, 1day resolutions, you do need to write 3 queries and combine them to get a real-time aggregate.
I hope I get owned and learn some stuff. So can you share more about your use case? It’d be interesting to see what is getting you interested in timescale.
Continuous aggs and the job daemon are really nice bonuses too.
What sorta impact does that schema have on insert performance? I would expect the DB to have to rewrite the entire array on every update, though that cost could be mitigated by chunking the arrays.
Are you ditching timestamps and assuming data is evenly spaced?
It was daily data too, literally 10 or more orders of magnitude less ingestion than Timescale is built for, so the arrays fit inside 1-2 postgres pages and so writing was absolutely not a problem every for 5-10 years of data.
Timescale may be the right solution when you need, I quote from their docs, "Insert rates of hundreds of thousands of writes per second", or somewhere within a few orders of magnitude of that. Good for the niche, but the niche is uncommon.
Yes ditching timestamps. The full row configuration used amazon keywords as keys, so they looked something like start_date|end_date|company_id|keyword_match_type|keyword_text|total_sales_by_day. They match_type and keyword text were like 40 bytes per row, so that's where the huge savings came from.
The data was assumed to be contiguous, aka there's end_date-start_date+1 entries in the total_sales_by_day array.
If this data were in Timescale, the giant keys would be compressed on disk, but I believe (would need to check) that there would be a lot of noise in memory/caches/processing after decompressing while processing the rows.
Anyway, in conclusion, I do think Timescale has its niche uses, but I've seen a lot of people think they have time series data and need Timescale when they really just have data that is pre-aggregated on a daily or even hourly basis. For these situations Timescale is overkill.
I really like the idea of TOAST compression as an archival format too for big aggregates - I’ll have to check out the performance of a (grouping_id, date, length_24_array_of_hourly_averages) schema next time I get an excuse.