Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Did you use plain Postgres tables or a columnar extension like Timescale or pg_mooncake?

Plain Postgres tables hosted on Google Cloud SQL on a decent machine.

> Nobody in their right mind would argue that Postgres without columnar storage is good for analytics.

Which is what I am saying. Standard means without extensions.

> Personally I'm a huge fan of dedicated databases like ClickHouse.

Where do you run it? What type of machine? Can it be server less?

> BigQuery gets very expensive as your data and query volume grows.

I didn't experience this, it has been hard for me to make BigQuery cost a lot. Storage costs were basically nothing and we just set the clustering/partition on DB creation to be users/sessions/events and dates respectively. It aligned really well with general query patterns.



Your comment is confusing to me because it appears to have nothing to do with the article, which is not about using Postgres' heap tables. In fact, you're arguing for a purpose-built storage engine (BigQuery), which is what pg_mooncake also is, except the latter is integrated with Postgres.

At my company we self-host ClickHouse, but if we started out today we'd definitely adopt ClickHouse Cloud. One big advantage of CH is that tables can be backed by ordinary cloud storage like S3 and GCS, which is incredibly cheap. BQ has support for external Iceberg tables in GCS, but (from what I recall) no write support.

We are shuffling several TBs/week into BigQuery, and that is extremely expensive. Querying this amount of data (billions of rows per day) is also very expensive unless you purchase flat pricing.

If your needs are really modest, then BQ is definitely very reasonable.


I will investigate Clickhouse. It is probably an even better solution that BigQuery when you have a lot of data and have a lot of queries.


Clickhouse is amazing. So is Postgres, but CH excels at its particular use case where Postgres does not.

While these new Postgres extensions will make Postgres more competitive, CH is built from the ground up for these kinds of analytics workloads in a way that Postgres isn't, e.g. in terms of scalable data ingestion.

CH also has a rich set of features like materialized views, aggregate function types, and dictionaries, none of which have counterparts in Postgres of these extensions.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: