Hacker News Reader

If you load that into a column store you’ll likely see that drop to 1TB or smaller.

Very much agree.

Even without this new capability of S3-based storage, Timescale's native columnar compression often gets like 95% storage reduction, even while staying fully in the PostgreSQL ecosystem.

(We often see our users amazed about how much less storage/disk they require after migrating from RDS.)

https://docs.timescale.com/timescaledb/latest/how-to-guides/...

But isn't that the "wrong" store to use (as far as performance is concerned) when you want random, row-level access?

Columnstores can do row level access by trading off a bit in terms of compression. If you organize the columnstore files as an LSM tree and use incremental compression schemes (so you don't have to compress too many more rows then the one your after) it can get close to the performance of a B-Tree for point reads - it depends on the specific table schema.

[1] https://dl.acm.org/doi/abs/10.1145/3514221.3526055

Reply on news.ycombinator.com