Hello Joe, thanks a lot for hydra and pg_duckdb. I wanted to confirm that for self hosting hydra i have to generate a token from your platform? what data is shared with hydra for this case. We need to double check as our data has restriction of sharing.
Hello thawab, yes! you can self-host Hydra with a token from the platform. Sign-up and visit that URL to take you to the right spot. We call it Bare Metal deployment, here's 1 minute setup guide (https://docs.hydra.so/guides/bare_metal)
billing (usage) metrics so we know what to charge. We offer BYOC 'Bare Metal' deployments as part of the Business plan. You can set it up now, but we offer volume discounts so you should talk to our team directly. Feel free to DM me on X (@JoeSciarrino) or email founders@
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?
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.
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.
[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.
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 while also selling a serverless product.
What's the reason behind that?
Why do it in the first place?
How does your pricing work?
The 40/ 500 compute hours I get are included in the spend limit per tier (i.e. max 160 additional hours in Starter etc.) or completely separate?
Why are there member constraints on a database product?
How does that factor into cost/ map to SDL / reasonable team setups of people operating analytics projects revolving around a database like yours?
I have never seen such a limit with any other vendor and esp. when you wanna get a hold in the market/ have people start using Hydra for the specialized role it can provide, having a 2 person limit for the minimum tier if I wanna PoC this would likely be a show stopper tbh...
[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, predictable price: Hydra $100 / month is better for businesses to plan around.
Usage caps per plan are purely soft limits so users don't actually encounter them. Yes, we want people to upgrade to higher plans. In the words of Maya Angelou "Be careful when a naked person offers you a shirt" - meaning, we believe these are the best prices we can offer today to build a sustainable project on. That said, I appreciate your point about our # of users limit. If we removed that limit would you try out Hydra?
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.
my team is currently looking into offloading some of our analytics data into a columnar database next year. hydra and clickhouse were the top ones on the list. would love a breakdown of how the two compare.
[Joe, Hydra cofounder] Hey, that's really great - I love hearing that. Hydra is a columnar database with an integrated Postgres rowstore. Analytics aren't purely best on columnar: we've heard from users that their analytics workload would benefit from fast lookup on row tables too, not just scanning large tables. Our goal for Hydra is to enable realtime analytics on Postgres without requiring an external analytics database. This makes it possible to join the rowstore and columnstore data in Postgres with direct SQL. Other analytics databases typically rely on ETL pipelines to move data out of Postgres, which depending on your scale, can become expensive and introduce delay.
Close to a drop-in replacement since Aurora bills itself as Postgres. Any data you load into Hydra will automatically be converted into the columnstore! we're happy to help out and feel free to DM me directly.
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).
[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?
I feel like my ideal would be something more hybrid. It's pretty rare that I have a table that I decide upfront should be columnar. It's a lot more common that I want occasional analytics-like queries on my regular tables to not take forever.
We initiall set the rowstore as default, but people wouldn't create columnstore tables and were confused on why performance wasn't improving. So, figured this was cleaner, but you always have the option to switch the default table type back.
The homepage of this website does a bad job of explaining wtf Hydra actually does. Is it a database? Some type of serverless architecture? Ok analytics, but analytics about what, postgrs performance? Does 'analytics' mean that its for OLAP queries?
[Joe Hydra cofounder]. Hydra is a fast analytics db on Postgres. It's a database with both a row and columnstore. Analytics can mean reporting, metrics, customer-facing dashboards. Sounds like we should spend some time making analytics templates.
Hello Joe, thanks a lot for hydra and pg_duckdb. I wanted to confirm that for self hosting hydra i have to generate a token from your platform? what data is shared with hydra for this case. We need to double check as our data has restriction of sharing.
> Visit http://platform.hydra.so/token to fetch the access token and paste it into the section above.
Hello thawab, yes! you can self-host Hydra with a token from the platform. Sign-up and visit that URL to take you to the right spot. We call it Bare Metal deployment, here's 1 minute setup guide (https://docs.hydra.so/guides/bare_metal)
thanks a lot, the other part of the question:
1- what data is shared with hydra for this case?
2- whats the pricing for the bare metal deployment?
billing (usage) metrics so we know what to charge. We offer BYOC 'Bare Metal' deployments as part of the Business plan. You can set it up now, but we offer volume discounts so you should talk to our team directly. Feel free to DM me on X (@JoeSciarrino) or email founders@
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.
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.
[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.
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 while also selling a serverless product.
What's the reason behind that?
Why do it in the first place?
How does your pricing work?
The 40/ 500 compute hours I get are included in the spend limit per tier (i.e. max 160 additional hours in Starter etc.) or completely separate?
Why are there member constraints on a database product?
How does that factor into cost/ map to SDL / reasonable team setups of people operating analytics projects revolving around a database like yours?
I have never seen such a limit with any other vendor and esp. when you wanna get a hold in the market/ have people start using Hydra for the specialized role it can provide, having a 2 person limit for the minimum tier if I wanna PoC this would likely be a show stopper tbh...
[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, predictable price: Hydra $100 / month is better for businesses to plan around.
Usage caps per plan are purely soft limits so users don't actually encounter them. Yes, we want people to upgrade to higher plans. In the words of Maya Angelou "Be careful when a naked person offers you a shirt" - meaning, we believe these are the best prices we can offer today to build a sustainable project on. That said, I appreciate your point about our # of users limit. If we removed that limit would you try out Hydra?
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.
my team is currently looking into offloading some of our analytics data into a columnar database next year. hydra and clickhouse were the top ones on the list. would love a breakdown of how the two compare.
[Joe, Hydra cofounder] Hey, that's really great - I love hearing that. Hydra is a columnar database with an integrated Postgres rowstore. Analytics aren't purely best on columnar: we've heard from users that their analytics workload would benefit from fast lookup on row tables too, not just scanning large tables. Our goal for Hydra is to enable realtime analytics on Postgres without requiring an external analytics database. This makes it possible to join the rowstore and columnstore data in Postgres with direct SQL. Other analytics databases typically rely on ETL pipelines to move data out of Postgres, which depending on your scale, can become expensive and introduce delay.
from what you wrote above, it seems like a great value add for greenfield projects.
we currently use aws aurora. how easy would it be to simply sql dump and load into hydra and how well would it serve as a drop in replacement?
Close to a drop-in replacement since Aurora bills itself as Postgres. Any data you load into Hydra will automatically be converted into the columnstore! we're happy to help out and feel free to DM me directly.
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?
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...)
I feel like my ideal would be something more hybrid. It's pretty rare that I have a table that I decide upfront should be columnar. It's a lot more common that I want occasional analytics-like queries on my regular tables to not take forever.
[Joe, Hydra cofounder] That's good feedback. It's easy to change the default table type to rowstore "heap" (https://docs.hydra.so/guides/analytics#switching-the-default...).
We initiall set the rowstore as default, but people wouldn't create columnstore tables and were confused on why performance wasn't improving. So, figured this was cleaner, but you always have the option to switch the default table type back.
The homepage of this website does a bad job of explaining wtf Hydra actually does. Is it a database? Some type of serverless architecture? Ok analytics, but analytics about what, postgrs performance? Does 'analytics' mean that its for OLAP queries?
[Joe Hydra cofounder]. Hydra is a fast analytics db on Postgres. It's a database with both a row and columnstore. Analytics can mean reporting, metrics, customer-facing dashboards. Sounds like we should spend some time making analytics templates.
I've run through the docs and it's really unclear how the compute model works. "Serverless" is nice, but how exactly is that managed?
is this using pg_duck?
[Joe, Hydra cofounder] Hey there, yes - we codeveloped pg_duckdb and it's what Hydra is built on top of!
Ory Hydra is a relatively high-profile project with a name collision, FYI.
there are a million open source products called hydra. I don't think any of them can really claim it exclusively