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.
coatue 1 hours ago [-]
[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.
CaveTech 1 hours ago [-]
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?
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)
thawab 7 hours ago [-]
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?
coatue 7 hours ago [-]
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@
thenaturalist 8 hours ago [-]
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...
coatue 7 hours ago [-]
[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?
cultofmetatron 12 hours ago [-]
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.
coatue 12 hours ago [-]
[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.
cultofmetatron 11 hours ago [-]
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?
coatue 11 hours ago [-]
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.
pikdum 11 hours ago [-]
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.
fourseventy 11 hours ago [-]
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?
coatue 11 hours ago [-]
[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.
switchbak 10 hours ago [-]
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?
mritchie712 11 hours ago [-]
is this using pg_duck?
coatue 11 hours ago [-]
[Joe, Hydra cofounder] Hey there, yes - we codeveloped pg_duckdb and it's what Hydra is built on top of!
curtisszmania 1 hours ago [-]
[dead]
switchbak 10 hours ago [-]
Ory Hydra is a relatively high-profile project with a name collision, FYI.
VWWHFSfQ 10 hours ago [-]
there are a million open source products called hydra. I don't think any of them can really claim it exclusively
Rendered at 05:03:46 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
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.
Is this a use case that you think Hydra would be competetive on?
> Visit http://platform.hydra.so/token to fetch the access token and paste it into the section above.
1- what data is shared with hydra for this case?
2- whats the pricing for the bare metal deployment?
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...
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?
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?
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.