What is Onehouse?

Onehouse is a fast, open data lakehouse platform that runs on any Kubernetes cluster. OneFlow ingests data from your databases, event streams, and object storage into open tables and prepares it incrementally, processing only what changed, and Spark and SQL pipelines run large-scale transformations efficiently. Table Optimizer keeps those tables fast and cheap to query, and Lakegres serves them over a Postgres-compatible endpoint to people and agents, with vector and text search built for lake-scale data. Around the data, the AI Gateway and semantic layer give agents governed access to models, tools, and metrics, the governance catalog enforces one set of access policies on every engine, and OneSync registers the same tables and permissions in the catalogs your other platforms use.

Onehouse runs wherever you run Kubernetes. The control plane (the API and the console) runs in Onehouse’s infrastructure. Everything that touches data runs on a Kubernetes cluster in your own environment, against object storage you own. Onehouse never opens an inbound connection to reach your data, and your tables, and the compute that reads and writes them, never leave your network. It deploys on AWS and Google Cloud, where Onehouse provisions the cluster for you, and on any other Kubernetes through bring your own Kubernetes: Microsoft Azure, NeoClouds, private cloud, and on-premises.

Your tables are in open table formats (Apache Hudi, Apache Iceberg, or Delta Lake) and open file formats (Apache Parquet, Lance, Vortex, and others) in your own buckets, so any engine that reads those formats queries them in place, without copies. If you stop using Onehouse, the tables stay in place and your other engines keep reading and writing them through their own catalogs.

The Onehouse platform: ingestion, transformation, and serving on the Quanton engine over open tables, with governance, agent access, and catalog sync alongside, deployed in your cloud, your data center, or a NeoCloud.

Why Onehouse?

Benefit	What it means
Runs on any Kubernetes	The same platform deploys on AWS, Google Cloud, Azure, on-premises, and NeoClouds, in your own account, next to your data and your GPUs. Hosted cloud platforms run only in the cloud accounts they operate.
Faster Spark/SQL, with no rewrites	The Quanton engine runs TPC-DS at 10 TB 6x faster than open-source Spark and 25% faster than Databricks Photon, without Photon’s DBU premiums. It is fully compatible with Apache Spark, so existing SQL and jobs move over unchanged, and it runs on your own Kubernetes as a drop-in for the Kubeflow Spark Operator.
Indexes on Apache Iceberg	Only Onehouse maintains record-level and secondary indexes on Iceberg tables, so MERGE INTO on Iceberg runs 16x faster than open-source Iceberg.
One endpoint for every agent query	Lakegres serves analytical scans, indexed point lookups, text search, and vector search from one copy of open tables over the Postgres protocol, with no search cluster or vector database to keep in sync. It runs 6x faster than Databricks SQL Serverless on the same tables.
Fastest large-scale CDC and streaming ingestion	Changes land in queryable tables in as little as 10–15 seconds at petabyte scale, and every downstream pipeline processes only what changed. The same design ingests 10 PB a day at Uber, and it saved Notion more than $1M in its first year on an update-heavy workload that Snowflake, and the other table formats Notion evaluated, were not optimized for. See Incremental processing.
Tables that stay fast	Table Optimizer clusters incrementally as data lands, and runs compaction and cleaning in the background with 2–4x less compute, on tables Onehouse writes and on tables other engines write, including Iceberg v3.
Permissions that follow your tables	Hudi, Iceberg, and Delta Lake tables in your own buckets, registered in AWS Glue, Unity Catalog, Snowflake, and OneLake at the same time. Only OneSync translates permissions between catalogs, so a grant made once in Lake Formation, Unity Catalog, or Snowflake is enforced in the others. It launched with Microsoft at FabCon 2026, enforcing those grants in OneLake security.
Operational excellence	The team that created Apache Hudi and ran some of the largest data lakes in the world operates your platform around the clock with AI, from the control plane.
You keep your cloud contract perks	Onehouse bills for compute only, and that compute runs in your cloud account, so your negotiated discounts and committed spend apply directly. Serverless platforms run in the vendor’s account and keep the cloud discounts for themselves.

Where it fits

Onehouse is where your data lands, is transformed, and is then queried by every engine. People and agents query the tables in Onehouse through Lakegres over the Postgres protocol: dashboards and ad hoc SQL, and the indexed lookups, text search, and vector search that agent loops generate. The warehouses and lake engines you already run, such as Snowflake, Databricks, BigQuery, Athena, and Trino, keep querying the same tables in place through their own catalogs, so workloads move to Onehouse at your pace, with nothing to migrate up front.

Teams usually start with one of three moves:

• Take ETL off the warehouse. Ingestion and transformation are often the largest line on a cloud warehouse bill. Run them as incremental pipelines on Onehouse and the warehouse keeps serving reports from the same tables. One team cut compute from $1M to $300K a year by moving its largest MERGE INTO workloads off Snowflake.
• Cut the cost of a premium lakehouse. Spark and SQL jobs from Databricks or EMR run unchanged on Quanton: 25% faster than Databricks Photon without the DBU premium, and 3.5x better price-performance than EMR Serverless.
• Serve context to AI agents faster. Lakegres answers agent queries directly from open tables, with a p99 latency of 537 ms against 6.0 s for Athena on a customer’s production tables, and with point lookups, text search, and vector search on the same endpoint instead of a database, search cluster, and vector store beside the lake.

Onehouse does not replace your BI tool, your operational databases, or your model training stack; it gives each of them the same open tables to work from.

Agents and AI on the same tables

Agent data access runs on the same open tables as the rest of the platform. Flows ingest records, documents, and media with embeddings kept current. Lakegres serves interactive agentic queries, with AI primitives such as vector search and text search built for lake-scale data. AI Gateway routes model and tool calls and logs every call as a table, and the semantic layer turns natural language questions into governed SQL. Training data pipelines turn those runs into the next supervised fine-tuning or post-training dataset. Each step reads and writes open tables in your own storage. See The lakehouse is your data foundation for AI.

The loop around one set of open tables: ingest, prepare, serve, route, and evaluate; what was evaluated becomes the next training set. Training itself runs at your provider.

Who builds Onehouse

Onehouse was founded by engineers who built and ran large-scale data infrastructure at Uber and LinkedIn, and spent more than a decade operating data lakes on open formats and open engines such as Apache Spark and Apache Flink. Onehouse’s founder, Vinoth Chandar, created Apache Hudi at Uber: the first lakehouse in production, and the project that brought ACID transactions and incremental reads and writes to object storage. Hudi still runs Uber’s lake and powers hundreds of other large lakes, including those at Amazon, Walmart, ByteDance, Notion, and JD. It ships pre-installed on five major clouds, including AWS and Google Cloud. The same team drives Apache XTable (Incubating), the standard for table and catalog interoperability, alongside Google, Microsoft, Cloudera, and Dremio.

The platform and its engine were built from that experience: years of designing, operating, and supporting petabyte-scale data platforms, in production and in the open-source community. The same team also operates the platform for you using AI agents; see Operational excellence.