[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.
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.
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.
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.
[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.
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@
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)
[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?
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.
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.
[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.
DuckDB Labs is excited to announce that we are going to be working with Hydra in the coming years to build DuckDB-Powered PostgreSQL for real-time apps and analytics development. DuckDB Labs has entered a long-term strategic partnership with Hydra to enrich and extend the DuckDB ecosystem. Joseph Sciarrino and his co-founder, Jonathan Dance “JD” helped pioneer the fusion of columnar analytics with transactional RDBMS, raising the bar of what’s possible with Postgres, which is why we are confident to join them in this endeavor.
Our collaboration with Hydra revolves around pg_duckdb, an open-source (MIT licensed) program that embeds DuckDB’s state-of-the-art analytics engine and features within Postgres. pg_duckdb is meant for developing high-performance applications and analytics with any new or existing Postgres database. We’ve observed software engineers increasingly embedding powerful analytics directly into their applications. These applications tend to require both greater access to disparate data sources and sub-second response times. We believe pg_duckdb will serve these use-cases nicely by overcoming Postgres’ known limitations in analytical processing.
... continues in article
Hey Phil, the blogpost says pg_duckdb is being taken forward by duckdb labs, hydra, motherduck, neon, and microsoft azure. We're fully invested in developing pg_duckdb and I'm happy to work collaboratively- do you have something valuable to add to pg_duckdb?