That's not recommended. Column-oriented (relational) databases store data by column instead of by row, which helps in large-scale OLAP reads of data but is extremely slow when writing or updating individual rows (since multiple rows have to be grouped into a column segment).

Postgres and other OLTP databases are a better fit.

It might not be the best tool available, but Timescale's columnar capabalities [0][1] looks great to me. I mean, being able to achieve 90%+ compression on a row-oriented database is not something to be ignored.

[0] - https://www.timescale.com/blog/building-columnar-compression... [1] - https://www.timescale.com/blog/timescaledb-2-3-improving-col...

Yes I've been considering evaluating ScyllaDB, I think it could be a good fit for my use case.

ScyllaDB (a next-gen Cassandra clone) is a "wide-column" database, or better called "advanced key/value".

This is very different from columnar/column-oriented databases which are still (usually) relational and just store data by columns instead of by rows for OLAP (large-scale analytics) usage.

Correct. A wide-column database like ScyllaDB is still a row-based store. Usually described as a "key-key-value" because it has both a partition key for data distribution and a clustering key for sort-ordering within a partition.

Not the same-same as a "column-store" like Druid or Clickhouse or Pinot.

[Disclosure: I work at ScyllaDB.]