4 ms·
I think this is fair. The whole selling point is to have time series abilities inside of PG. It will not be as fast as a tailored engine? Sure. But the advanta
by mamcx 7y ago
I think this is fair. The whole selling point is to have time series abilities inside of PG.
It will not be as fast as a tailored engine? Sure. But the advantage of stay inside of PG is very great (not only ecosystem, but have sql, OLTP + OLAP, etc).
Is like how a document store could be better than add JSON with PG...
In practique? I think this hybrid approach is very good.
P.D: And what about the opposite? Which columnar store can I use for OLTP?
- GordonS 7y agoI was going to say something similar. We have TimescaleDB in production with hundreds of millions of time series data sat alongside "regular" data - having to deploy a single database instead of Postgres and a specialised time series database is a real boon. For us, TimescaleDB queries run way faster than stock Postgres. They might well run faster in something specialised, but querying/aggregating hundreds of millions of rows in 10s or 100s of milliseconds is plenty fast enough for many use cases.