Back to Devoured - August 10, 2026
DEVOURED
How Physical Intelligence unified its robotics data stack with Postgres managed by ClickHouse

How Physical Intelligence unified its robotics data stack with Postgres managed by ClickHouse

Data ClickHouse
Physical Intelligence replaced a single overburdened Postgres instance with a split architecture of Postgres for transactions and ClickHouse for analytical robotics data.
What: Physical Intelligence migrated to a managed ClickHouse setup to handle over 10 billion rows of metadata and annotations, enabling researchers to perform high-cardinality searches that previously took days.
Why it matters: This highlights the necessity of separating transactional (OLTP) and analytical (OLAP) workloads as AI research data scales to billions of rows.
Takeaway: If your RDS queries are stalling due to high-cardinality metadata, consider offloading analytical workloads to ClickHouse via ClickPipes for real-time synchronization.
Deep dive
  • Split data stack into transactional Postgres and analytical ClickHouse.
  • Used ClickPipes to automate data movement from Postgres to ClickHouse.
  • Implemented materialized views in ClickHouse to accelerate query performance for researchers.
  • Utilized full-text indexing to enable natural language search across robotics datasets.
  • Leveraged ReplacingMergeTree for efficient handling of high-frequency annotation inserts.
Decoder
  • OLTP (Online Transactional Processing): Databases designed for fast, reliable updates and queries of individual records.
  • OLAP (Online Analytical Processing): Databases optimized for complex queries across large datasets, typically involving aggregations.
  • ReplacingMergeTree: A ClickHouse table engine that automatically removes duplicate entries based on a sort key during background merges.
Original article

Summary

  • Physical Intelligence builds robotics foundation models and uses Postgres managed by ClickHouse to combine OLAP and OLTP workloads in one unified data stack.
  • They migrated to ClickHouse Cloud after their previous single RDS Postgres instance couldn’t handle both their transactional and high-cardinality analytical workloads.
  • They can now explore their data faster and more easily, with rows growing from the 10 to 100 billion row range.

Introduction

Physical Intelligence is a robotics company acting as a research lab pushing frontier models in robotics, with the mission of bringing general-purpose AI into the physical world.

Three axes of generalization

To bring general-purpose AI into the physical world, the team focuses on three axes of generalization:

  • Environments: A foundation model that runs on a robot in any environment, such as a home or a factory floor.
  • Embodiment: A model capable of operating on any hardware form factor, including single-arm robots, multi-arm robots, and robots with legs or wheels.
  • Tasks: A robot brain capable of performing any task, from folding laundry to making coffee.

Foundation models for robotics

Classical robotics relies on methods like A-star search, SLAM, object recognition, and low-level control. Physical Intelligence aims to build a robot brain from scratch, similar to a large language model, which takes data from different sources and executes actions. Their model, π0.7, can perform tasks in various environments and on different robot embodiments without specialized fine-tuning. By utilizing visual sub-goals, the model can chain together skills, transfer tasks across different robot hardware, and learn through human coaching.

How the model learns — and why data matters

The team uses a vision-language-action model, which acts as an LLM with a vision encoder and an action decoder. Achieving generalization requires diverse, petabyte-scale data, including web data, ego-centric human data, and robot-specific data.

The data infrastructure is divided into three categories:

  • Raw data: Petabyte-scale, append-only data used during training. It requires cheap storage and relies on random reads.
  • Transactional data: Data required for company operations and data labeling, requiring ACID guarantees and strong consistency. This fits within 100 million rows.
  • Metadata and annotations: High-cardinality data in the 10 to 100 billion row range. This requires long-running filters and GROUP BY queries where eventual consistency is acceptable.

Where we started: a single RDS database

Previously, the team relied on a single RDS Postgres database. As the volume of data and the complexity of researcher queries grew, they faced significant scaling issues, exacerbated by an over-reliance on JSONB for storing diverse, evolving annotation types. These "ambitious" queries on top of JSONB structures caused performance bottlenecks.

Why ClickHouse

The team transitioned to ClickHouse to separate transactional and analytical workloads. ClickHouse offered fast inserts and efficient storage for their annotation data. Using the ReplacingMergeTree engine, they handled high-cardinality datasets while moving away from inefficient JSONB blobs toward a columnar format. Materialized views were implemented to accelerate specific queries and reduce database load.

The migration

The team leveraged ClickPipes to migrate data seamlessly from Postgres to ClickHouse. This established a unified stack where transactional data lives in Postgres, while annotations and telemetry are replicated to ClickHouse for analytical processing. This setup allows researchers to perform complex, cross-table queries that were previously impossible, such as verifying if specific objects (like an air fryer) have been encountered in training datasets.

The go/data app

The team built an internal tool, "go/data," which allows researchers to query the dataset via SQL or a natural language interface. An AI agent processes these queries, identifying the relevant tables across Postgres and ClickHouse to return results. This system uses full-text indexing to search through millions of data points rapidly, enabling researchers to discover new capabilities and verify training data content without manual multi-day joins.

Bonus: telemetry

The team also migrated their system telemetry to ClickHouse. By using ClickHouse alongside Grafana, they unified their telemetry, OLAP, and OLTP workloads, providing a comprehensive view of their operations on a single platform.

Explore all 68 articles in today's digest

Fresh dev news, AI-digested daily. Never miss a trend at devoured.fyi