Core capabilities

Interactive agentic queries with Lakegres

Lakegres serves interactive SQL queries from AI agents, apps, and BI tools directly on your lakehouse tables, over the PostgreSQL wire protocol. Underneath, it is a distributed SQL engine built on Quanton, with columnar caching, load-aware elastic autoscaling, and memory- and flash-optimized indexes. It serves standard analytical queries at sub-second latency.

Lakegres is designed for a world where agents generate most queries, in bursts, with a mix of shapes that is hard to predict. An agent sends four kinds of queries inside one reasoning loop: it rolls up history, looks up a single customer, searches for a phrase in last week’s traces, and asks for the documents closest in meaning to its question, often within the same task and at hundreds of queries a second. Lakegres answers all four from one endpoint, on the same copy of the data.

Engines built for the lake, such as Athena, Trino, or a cloud warehouse, are designed for the first kind: scan-shaped analytics. Operational databases such as Postgres handle point lookups, but not at lake scale or alongside wide scans. Search and vector databases each add another system to load, secure, and keep in sync. Lakegres replaces that stack with a single endpoint on open tables.

Lakegres answers four query shapes from one endpoint and one copy of the data.

Getting started

Create a Lakegres cluster in the console and pick an engine size based on your workload. Each size is priced in OCU per hour, and Onehouse scales the cluster out and in automatically, in units of that engine size, as query load rises and falls, so agent bursts need no manual resizing. Auto stop shuts the cluster down when it sits idle. A small cluster serves thousands of queries a second.

Creating a Lakegres cluster: engine sizes in OCU per hour, the engine range it scales within, and auto stop.

Connect with any agent framework or client that talks to Postgres, including BI tools such as DBeaver, Tableau, Power BI, and Looker. Users sign in with OAuth through Okta, Microsoft Entra, Google, and others, and every query follows the access policies described under Governance.

1. Analytical queries

Analytical queries are rollups, statistics, correlations, and joins across large amounts of data, the workload the lakehouse was built for. Lakegres runs them on Quanton with a distributed columnar cache, at interactive latency. On a customer’s production tables, p99 query latency is 537 ms against 6.0 s on AWS Athena, and 1 TB joins finish in 63 s against 381 s on Databricks SQL.

2. Point lookups and high-cardinality filters

Agents constantly fetch one order, one user, or every event for a device. Lakegres answers these lookups in under a second on very large tables, because Onehouse maintains record-level and secondary indexes underneath Hudi and Iceberg tables and Lakegres reads only the row groups that match. On a 1 TB TPC-DS lookup benchmark, Lakegres cuts query latency by 95%. Lakehouse query engines have no indexes to use and must scan. Postgres serves lookups, but not on tables of this size.

3. Text search

Text search finds words and phrases across text at lake scale, without running Elasticsearch or another search cluster beside the lake. A full-text index is maintained with the table, on copy-on-write and merge-on-read tables alike, and Lakegres uses it to read only the files and rows that contain the terms. Spark, Athena, other lakehouse engines, and most cloud warehouses have no full-text index, so every text search scans the whole table, which on a terabyte takes many seconds each time. With the index, the work scales with the number of matches. On the MS MARCO passage corpus, the index cuts median query time from 6.4 s to 0.78 s, about 8x faster. At 884 million passages (100 copies of the corpus), a warm query that matches 11.5 million rows returns in about 1.3 seconds, and reading only the matching rows from the cache, rather than whole files, halves the scan stage again.

Two uses matter most for agents. Agents search their own traces, the runs recorded by the AI Gateway, to find how a similar task went before. They also search the text extracted from unstructured data, such as parsed documents and the descriptions of images and video, then fetch the original document, image, or video from the same table.

4. Vector search

Vector search finds the records closest in meaning to a question, at lake scale and in open formats. The vector index lives with the table, stays current through inserts, updates, and deletes on copy-on-write and merge-on-read tables, and supports approximate search with optional exact re-ranking. On one billion vectors, it reaches 0.96 recall@10 with exact re-ranking. On 8.8 million 1,024-dimension embeddings, Lakegres returns the top 10 in about 200 ms at the tail with the index cached.

Vectors live in the same tables as the facts, so one query can rank by similarity and join to business data. There is no second copy to reconcile, or to rebuild when an embedding model changes. The vector search index is built in the Apache Hudi community, with Uber and Walmart driving the design together with Onehouse.

Text and vector search are in preview; analytical queries and indexed lookups are in production. Point-in-time queries apply to all tables, so evaluations and RL rollouts can read the lake as of a past moment and an agent run stays reproducible.

Performance

The performance results above were measured on a customer’s production tables, over several hundred tables, and on public benchmark datasets. Lakegres also runs 6x faster than Databricks SQL Serverless on the same tables. Announcing Lakegres describes the architecture and query shapes behind each result.

How it works

A Postgres-compatible gateway handles connections and identity. A routing layer built on non-blocking I/O authorizes each request and balances it across a pool of engines, failing over when one is unavailable. Each engine runs Quanton with a distributed columnar cache, table indexes for point lookups, index joins, text, and vectors, and an HTTP/2 server that keeps request queuing near zero. The cache is transactional: it is tied to the table’s commit timeline, so it never serves stale data and never rebuilds more than it has to. Engines scale vertically by size and horizontally by count, and the autoscaler adds or removes them based on latency and utilization signals.

Lakegres request path. Engines are added and removed as a unit; the cache in each is tied to the table’s commit timeline.

Governance

The Onehouse governance catalog governs access. Table and row policies, and column and cell policies in preview, are defined once and apply to every query the endpoint serves, from a dashboard or an agent, in any shape. Agents that connect through the AI Gateway reach Lakegres through the gateway’s built-in MCP server, so the same policies apply to their tool calls. AWS Lake Formation is available as an alternative enforcement point when a cluster uses a Glue catalog. Lakegres runs on every deployment target, including bring your own Kubernetes and on-premises.