Skip to main content
Hydra adds serverless online analytics processing (OLAP) functionality to Postgres. Hydra is column-oriented by default: to enable serverless analytics, simply create a table. Hydra makes it easier to build realtime analytics by automatically managing the transactional rowstore and analytical columnstore together. Inserting data into a table will automatically convert it into an optimized columnar format.
Use Hydra to eliminate the costs and latency of moving and transforming data between a row and external columnstore with data pipelines (ETL).
Hydra runs isolated resources (CPU & RAM) per process, removing the potential for resource contention with Postgres’ transactional rowstore. Data in analytics tables benefit from efficient compression of 5-15X and is ideal for large data volumes. For example: 150GB compresses to 15GB with a 10X compression rate.

​
Postgres as a multi-workload data store

Hydra is a “multi-workload data store” with the following core capabilities:
  • high throughput, ACID-compliant online transactional processing (OLTP)
  • vectorized, parallel execution of online analytical processing (OLAP)
With Hydra transactional and analytical operations can be employed independently and in concert. It removes the complexity and latency bottlenecks associated with running multiple heterogenous datastores with different data formats, schemas, syntax, and features.
In a rowstore, table rows are stored sequentially. This arrangement enables fast retrieval of rows because the column values for each row are grouped together. A rowstore make it easy to add / modify a record, but may scan unnecessary data during read operations. For example, PostgreSQL is a rowstore.
In a columnstore, tables are organized by storing all the values of each column in sequence. This format enhances the efficiency of filtering or aggregating columns but complicates the retrieval of individual rows due to the gaps between row data. For example, DuckDB is a columnstore.

​
Analytics overview

  • Isolated Compute Tenancy
Each user is allocated their own process which is an isolated piece of compute designed this way to lessen contention between users, which is a common challenge for analytics.
  • Serverless processing
Hydra automatically parallelizes the work that you send to it. As a result, scheduling multiple queries at-a-time does not meaningfully increase throughput, as Hydra has already parallelized the workload across all available resources. Dedicating serverless processes to analytics means there is no resource impact on Postgres’ transactional workloads.
  • Sharing
Hydra’s analytics tables separate storage and compute, which means that one user cannot see another’s writes into a database until that database is updated to that user. Hydra can spin up read scaling replicas, which are zero-copy clones of the main database for read-only use, enabling high scalability of analytics workloads.