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