Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

hydra.so

Post reply on HN
Print view View original

21–30 of 35 posts

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#21

Post by nlh »

This is super cool and congrats!

Some questions - I understand all of these concepts but so far everything seems to be aimed at people way more immersed in this world than I, so pardon any dumb queries:

I have a small website I run. Everything is currently hosted on Fly.io (sjc) and I’m using Postgres as my main db. I’m about to add a whole bunch of features related to analytics and was dreading having to spend a week learning Clickhouse, so was just going to use Postgres until things get too big and slow to be useful.

Is Hydra aimed at folks like me? I see you guys are also hosted with Fly which is great but in the Virginia region. Am I out of luck unless I move my app to VA? Am I basically giving up my own Postgres instance and porting everything to Hydra?

Thanks for clarifying - your site kinda mostly covers this stuff but not entirely crisply so I’m a bit puzzled.

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#22

Post by coatue »

nlh wrote: post #21

This is super cool and congrats! Some questions - I understand all of these concepts but so far everything seems to be aimed at people way more immersed in this world than I, so pardon any dumb queries: I have a small website I run. Everything is currently hosted on Fly.io (sjc) and I’m using Postgres as my main db. I’m about to add a whole bunch of features related to analytics and was dreading having to spend a wee…

[Joe, Hydra cofounder] Hey, thanks for the kudos! Sounds like a nice fit and that's coincidentally good timing! We started with the Virginia region, but we can focus on SJC next. With 35 regions to cover, we're prioritizing based on user requests - so thanks for mentioning it.

Ideally, you can easily switch over to Hydra. Or Hydra can work as a fast, external analytics database too. It's Postgres-native so no changes are needed to use it in a traditional architecture if you wanted to.

Feel free to DM me on X (@JoeSciarrino) or email founders@ so we can coordinate on the SJC region.

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#25

Post by coatue »

CaveTech wrote: post #24

Current user of Timescale for events processing, with heavy use of materialized views for rolling aggregates. Is this a use case that you think Hydra would be competetive on?

Yes definitely. Check out the public 1v1 benchmark of Hydra v Timescale (https://benchmark.clickhouse.com/#eyJzeXN0ZW0iOnsiQWxsb3lEQi...)

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#26

Post by potamic »

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?

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#27

Post by thenaturalist »

coatue wrote: post #17
thenaturalist wrote: post #16

Hey there, congrats on publicly launching this after your work over the past months! Having followed the project for a while now, I really scratch my head when looking at your pricing. The entire innovation of the past decade in database land has gone towards decoupling storage and compute, driving query engines (like DuckDB) and file formats (like Iceberg). Yet you force-bundle storage and compute in your pricing wh…

[Joe, Hydra cofounder] Hey there, I appreciate you taking the time to write this up - helps a lot to hear what's confusing. One of the downsides of serverless is that it can be difficult to predict the overall monthly cost when the granularity of billing (per invocation, memory usage, or execution time) is complex. For developers this might be totally fine (even preferred), but we think that giving a single, predicta…

Hi Joe, much appreciate the response!

Resounding yes RE removal of user limits.

I would want people to have access, to play around with the tool but also to be able to share responsibility wrt to ops/ extension/ incident mgmt etc.

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#28

Post by coatue »

potamic wrote: post #26

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…

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

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#29

Post by coatue »

thenaturalist wrote: post #27
coatue wrote: post #17

Earlier quoted context omitted.

[Joe, Hydra cofounder] Hey there, I appreciate you taking the time to write this up - helps a lot to hear what's confusing. One of the downsides of serverless is that it can be difficult to predict the overall monthly cost when the granularity of billing (per invocation, memory usage, or execution time) is complex. For developers this might be totally fine (even preferred), but we think that giving a single, predicta…

Hi Joe, much appreciate the response! Resounding yes RE removal of user limits. I would want people to have access, to play around with the tool but also to be able to share responsibility wrt to ops/ extension/ incident mgmt etc.

Ok, I'm down to run an experiment and remove the user limits on your account! DM me on X (@JoeSciarrino) or email founders@hydra so I know which account is yours.

Re: Show HN: Hydra (YC W22) – Serverless Analytics on Postgres

#30

Post by potamic »

coatue wrote: post #28
potamic wrote: post #26

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…

[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…

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?
Post reply on HN