[coatue]

[Joe, Hydra cofounder] Yes, you're right and to clarify: Hydra's columnstore is decoupled (bottomless), compressed, and supports multi-node reading. (https://docs.hydra.so/changelog/changelog#march-2025-3)

Events, time-series data, user sessions, click, logs, IOT sensor readings, etc. generate a lot of data over time. While on-disk storage works well for Postgres’ rowstore, it’s a poor choice for fast growing data that requires analysis. To avoid the scale limit of on-disk storage, Hydra separates compute and storage. Also, we're not charging separately for bandwidth since it's been factored into the overall plan price.

While storage volume can be a good proxy, many people see the limits of Postgres with a complex join and filtering on relatively small data volumes. With decoupled columnstore and serverless processing, Hydra can be used in big (and small data) use-cases. Company size is a little less relevant since medium and large-scale companies have use-cases where efficient 'small data' is needed too.

[potamic]

Okay, this makes sense. But now I'm confused where postgres figures in all this. If your compute is separate and storage is separate, I should just be able to run Hydra independently without postgres?

[coatue]

Our goal is to enable realtime analytics on Postgres without requiring an external analytics database. Think more towards extending Postgres, rather than replacing it. Postgres brings it's rowstore to Hydra, which is great for transactional jobs. Also, Postgres brings it's syntax, features, and standard Postgres integrations with tools you like to use are the same and works with Hydra. This makes Hydra easy to use and adopt without a major database migration.