Comment by potamic
7 days ago
Compute is not the only bottleneck with running analytics on your transactional DB, there is also storage bandwidth and costs. Which is why once you cross a certain scale, you will want to separate out your analytics use case. I've always been tempted to do analytics over my transactional DB, but knowing that eventually I will need to move it out, felt it's just simpler to separate it out from the start.
Since you're advocating for the opposite, who do you see as your potential customers? Specifically, where in the lifecycle their growth do you see Hydra fit? Is it more for early stage or medium scale companies that can benefit from getting started with analytics quickly or can it continue to cater (at reasonable cost!) as they cross terabyte/petabyte scale?
[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.
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?
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.