coatue

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

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

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

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

Sweeeet. Let's give it a go!

Would this work with Hydra? https://news.ycombinator.com/item?id=43937852

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.

[Joe, Hydra cofounder] Hey there, yes - we codeveloped pg_duckdb and it's what Hydra is built on top of!

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

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

Benchmarks - https://benchmark.clickhouse.com/#eyJzeXN0ZW0iOnsiQWxsb3lEQi...

Features: Serverless Processing

- Parallel, vectorized excution

- Compute Autoscale

Bottomless Storage

- 10X data compression

- Automatic caching

- zero-copy snapshots & forks

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

repo: https://github.com/duckdb/pg_duckdb

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?

Hey Craig, for the public record- pg_duckdb was not inspired by the team at Crunchy Data. Our early mvp version, "pg_quack" was made public (apache 2.0) on February 2nd. About 2 months later, Crunchy's analytics product shipped on April 30th. If you were working on it around a similar time it was a coincidence. Let's call it great minds think alike.

Upsert, also known as "INSERT ... ON CONFLICT", is a feature in PostgreSQL that let's a user insert a new record or update an existing one if it already exists, using a single command.

Upsert is useful in several ways:

1. Data Consistency: It manages and keeps the data clean and free of redundancies. Any attempt to insert a new row of data into an existing table is modified into update commands when a conflict occurs.

2. Simplified Queries: Instead of writing separate INSERT and UPDATE queries, with Upsert, you can both cases in a single query thereby reducing the complexity.

3. Efficiency: Since a single statement can handle the process of inserting a new row or updating an existing one, the number of queries processed by the server can be reduced.

4. Atomicity: Upsert operations are atomic, meaning they will either fully complete or fully fail, ensuring the data integrity is maintained.

5. Error Handling: It prevents the processing from being halted due to error thrown if data already exists. In a large batch operation, this is especially useful.

Yes, that's right- npm was in reference to npmjs.com. The analogy was made since pgxman handles version and dependency management, but for Postgres extensions.

HN titles are short. Please Note: Hydra BYOC is "Early Access" - if you are interested, please contact our team to join the next cohort. https://www.hydra.so/get-in-touch