Comment by mohon
6 days ago
Kudos for the product launch. A bit curious on the product itself, to me the product seems similar to what Neon team does, except Neon doesn't touch the columnar/analytics and just focus on the rowstore. I'm wondering how do you position the product, if let say Neon team (after Databricks acq) decides to support the columnstore format?
Neon actually does have a columnstore extension with pg_mooncake today. The key difference with pg_mooncake vs hydra is the bet on open storage formats (Iceberg).
(1) https://neon.tech/docs/extensions/pg_mooncake (2) https://www.mooncake.dev/blog/clickbench-v0.1
[Joe, Hydra cofounder] Hey, thanks! There are similarities, but you’re right to point out that our focus with Hydra is on bringing columnstore-powered serverless analytics to Postgres. We wouldn’t position Hydra differently because we think it’s the right product to help the greatest number of projects and developers in a meaningful way.
I see. What's the catch on Hydra.so in terms of CAP theorem? I assume it's the C one, especially the docs mentioned about read replica. Is there any drawbacks/tradeoff that user should be aware of?