If pg was olap there wouldn’t exist any competition out there. IMO hybrid oltp and olap is what most companies need for their user facing apps and whoever nails it will become #1 in zero time.
Ps. I would like to test firebolt, sounds promising.
Ps. I would like to test firebolt, sounds promising.
I understand that the shape of the schema has to be somewhat different for analytics (though I think that point is overstated and many use cases could probably get accomplished with the same table layout but just different index placements)
OLAP databases typically use a column store which is amazing for reading a subset of columns because of much better compression and use of vectorized execution as opposed to Postgres’ tuple-at-a-time execution. The tradeoff is it’s expensive to update a column store since you have to rewrite a chunk of the column at least.
Postgres is moving towards better OLAP. AlloyDB is a recent commercial DB that swaps out the Postgres storage engine to better support OLAP.
That said, you can coerce Postgres into doing a reasonable job at OLAP for a surprising amount of data.
What does this actually mean? If PG were an OLAP database it probably wouldn't have full ACID support, because pure OLAP workloads typically don't do a lot of updates. And it would have a lot of hooks around storage like compression codecs that don't give a lot of value in an OLTP database. Finally it would probably be eventually consistent because it's expensive to ensure data consistency across a large, distributed dataset.
So it wouldn't really be PG at that point.