7 ms·

> I am very disappointed to see the direction: It is moving from a "interesting attempt to recreate system software" to "building flashy but useless demo" What

> I am very disappointed to see the direction: It is moving from a "interesting attempt to recreate system software" to "building flashy but useless demo" 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. [0] https://news.ycombinator.com/item?id=48841676 https://news.ycombinator.com/item?id=48841676

nullpoint420 1mo ago
I just deployed this to production to replace our self-hosted Postgres - and we’re experiencing corruption. Can you help us out?
- malisper 1mo ago
  Yes. Email me and Jason at malis@pgrust.com and jason@pgrust.com
  - nullpoint420 1mo ago
    Wow ok fair enough. Sorry to put you through a fire drill but I wanted to see if there would be support or not. I stand corrected, there is. Wishing you the best of luck here.
hasyimibhar 1mo ago
> 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. 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

nullpoint420 1mo ago

I just deployed this to production to replace our self-hosted Postgres - and we’re experiencing corruption. Can you help us out?

malisper 1mo ago
Yes. Email me and Jason at malis@pgrust.com and jason@pgrust.com
- nullpoint420 1mo ago
  Wow ok fair enough. Sorry to put you through a fire drill but I wanted to see if there would be support or not. I stand corrected, there is. Wishing you the best of luck here.

hasyimibhar 1mo ago

> 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. 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