hi hn, hydra cofounder here. jd and I are excited to take the covers off hydra.

hydra: serverless realtime analytics on postgres. by separating compute and storage, hydra enables compute-isolated analytics and bottomless storage. it is designed for low latency applications built on time series and event data.

set up is simple.

> pip install hydra-cli

$ hydra

traditionally, there's been 2 core problems with running analytics on postgres.

- slow performance: aggregate queries can take minutes to return results from large data sets.

- resource contention: expensive queries hog Postgres’ ram / cpu resources and impair transactional performance.

here’s how hydra solves these problems:

- fast: hydra returns analytics queries 400X faster than standard postgres. hydra uses duckdb to perform isolated serverless processing on these tables in postgres. In fact, hydra is faster than most specialized analytics databases.

- isolated serverless processing: there is no impact on postgres ram / cpu resources.

“ok, but why use postgres?” is a common question. it’s true, there are many specialized analytics databases, but they create their own frictions and costs:

- moving and transforming data (ETL) between postgres, s3 bucket, and separate analytics db isn’t cheap. pipelines speed determines how stale the analytics are. hydra side-steps the latency and costs of data pipelines entirely with full support for inserts and updates on columnar files in the analytics schema.

- many use-cases don’t justify a heavy setup. from our time working at heroku, we saw many transactional apps that just need a couple high level aggregates and a few complex analytical queries. hardly olap and not really htap - just apps that need a boost.