What makes you say this is a useless demo? I can't count the number of people who've struggled to do analytics inside of Postgres. Almost always they end up setting up a separate system such as Clickhouse and replicating the data between the two systems. Now they can have one system that's Postgres-compatible, and it's faster than either of the original systems.
> Everyone who knows a bit about databases knows the difference between execution models and what kind of optimization it brings.
In our last post[0], when we mentioned we were getting close to Clickhouse level performance (now faster than Clickhouse), we were met with disbelief. This post is meant to explain part of how we closed the 300x gap between Postgres and Clickhouse. The execution model being 10x of it.
I stand corrected, there is. Wishing you the best of luck here.
I can see the appeal for pgrust for smaller teams who need analytics, and don't want to deal with having to ETL to something like ClickHouse. But beyond a certain complexity, replicating your data to a warehouse or lakehouse _is_ the right approach and more scalable for several reasons:
- Analytics tend to be centralized, i.e. you want data from several Postgres databases spread across multiple teams to be replicated into 1 place, so people can start joining data across the entire business
- Analytics tend to fall under a different team ownership with their own set of non-technical requirements (e.g. data governance)
- Lakehouse architecture (Iceberg + [insert query engine]) is more scalable in terms of cost
- In some cases, you want to be able to swap different query engines depending on the use case, e.g. use PuppyGraph to query your data in Iceberg for fraud analysis
Everyone who knows a bit about databases knows the difference between execution models and what kind of optimization it brings.