Cloud Parts

Pivot

A young open-source analytics server in Rust that speaks the PostgreSQL protocol and queries Iceberg and Delta Lake tables straight from object storage.

What it is
Real-time analytics databases,Query engines
Type
Open source
Made by
Epsio Labs
License
MIT or Apache 2.0, at your option
Facts checked
6 October 2026
Website Source code

What it is

Pivot is one Rust binary. pivot server listens on port 5432 for PostgreSQL clients such as psql, BI tools and app drivers; pivot open s3://bucket/path starts a local SQL shell on the same engine with no server. It keeps no data of its own: tables live in object storage (S3, GCS or a local directory) in one of two datastores. A Pivot datastore is a set of Delta Lake tables of Parquet files that Pivot writes, compacts and keeps statistics for; an Iceberg datastore points at an Iceberg REST catalog and is read-only. One query can join tables from several datastores. SQL is parsed, bound and optimised by a fork of DuckDB’s planner, then translated into Pivot’s own operators, which run on one worker thread per core with io_uring I/O, its own cache instead of the OS page cache, and work stealing between cores. Server settings, users and datastore definitions come from YAML configuration; a shared PostgreSQL-backed metastore for clusters is still in development.

Speed on Parquet comes mostly from reading less. A table can be soft-sorted with sort_by, and background compaction rewrites files whose sort-key ranges overlap, six at a time, so file and row-group min/max statistics prune well; dictionary checks and page-level pruning skip more, and late materialization reads wide columns only for rows that survive a filter or LIMIT. Pivot is made by Epsio Labs, the company behind the Epsio incremental SQL engine, and is free under MIT or Apache 2.0; there is no paid edition yet. The project calls itself early and not production ready: v0.1.0 was tagged on 5 October 2026, and the docs warn that SQL, configuration and on-disk layout change between releases with no migration path.

Why teams pick it

  • Serves low-latency SQL over open tables without first copying them into a separate real-time database
  • Any PostgreSQL client or driver can connect, and the same engine runs as a local shell for ad hoc work or AI agents
  • Holds no state except object storage, so instances can be added or stopped quickly and several servers can share one datastore
  • Tables it writes are ordinary Delta Lake and Parquet, readable by Spark, DuckDB, Trino and others
  • Permissive MIT or Apache 2.0 licence, with the benchmark harness published for anyone to rerun

Watch out for

  • Very new and explicitly not production ready: breaking changes in SQL, config and storage format between releases, and whole areas of SQL missing
  • Append-only for now: no DELETE or UPDATE, and Iceberg tables can be read but not written
  • No spill to disk, so a large join, aggregation or sort must fit in memory; a single query can’t yet span several machines
  • Linux only: the installer and packages target Linux, and the engine relies on io_uring, which Docker blocks unless run with seccomp=unconfined
  • Two people have made nearly all commits, and there are no GitHub releases yet, only tags, Docker images and Debian packages

Alternatives

What all real-time analytics databases have in common →
Alibaba Cloud HologresCommercialAlibaba Cloud’s PostgreSQL-compatible real-time data warehouse, which takes streaming writes, answers analytical queries and serves key lookups from one copy of the data.Apache DorisOpen sourceAn open-source MPP analytical database, born at Baidu as Palo, that serves sub-second queries on fresh, updatable data through the MySQL protocol and also queries Iceberg, Hudi, Paimon and Hive tables in place.Apache DruidOpen sourceAn open-source real-time analytics database that makes Kafka and Kinesis events queryable within seconds and serves fast slice-and-dice queries to dashboards and APIs.FireboltCommercialA cloud data warehouse built for low-latency, high-concurrency queries behind apps and dashboards, also free to self-host as Firebolt Core.StarRocksOpen sourceAn open-source MPP analytical database with a vectorized engine that serves fast joins and real-time updates on its own tables, and also queries Iceberg, Hudi, Delta Lake and Hive tables in place.TinybirdCommercialA hosted ClickHouse platform that turns SQL queries into authenticated REST API endpoints, for analytics inside your product.

How it fits with other technologies

In `psql` connected to a Pivot server: a soft-sorted table loaded from Parquet on S3 · sql

CREATE TABLE trips (
  vendor_id       INTEGER,
  pickup_at       TIMESTAMP,
  passenger_count BIGINT,
  trip_distance   DOUBLE,
  fare_amount     DOUBLE,
  tip_amount      DOUBLE
) WITH (sort_by = 'pickup_at');

INSERT INTO trips
SELECT VendorID, tpep_pickup_datetime, passenger_count,
       trip_distance, fare_amount, tip_amount
FROM read_parquet('s3://pivotlake-examples/nyc-taxi/yellow_tripdata_2024-01.parquet');

COMPACT trips;

SELECT date_trunc('day', pickup_at) AS day,
       count(*) AS trips,
       CAST(avg(tip_amount) AS DECIMAL(10, 2)) AS avg_tip
FROM trips
WHERE pickup_at >= '2024-01-01' AND pickup_at < '2024-02-01'
GROUP BY day
ORDER BY trips DESC
LIMIT 5;

A server over its own bucket and an existing Iceberg catalog#

pivot server --config pivot.yaml serves both datastores; SELECT … FROM lake.crm.customers reaches the Iceberg tables, and unqualified names go to the default one.

yaml
datastores:
  events:
    kind: pivot
    location: s3://acme-analytics/pivot/
    default: true
  lake:
    kind: iceberg
    uri: https://catalog.example.com/api
    warehouse: s3://acme-lake/warehouse/
    secret: lake-catalog
secrets:
  acme-analytics:
    type: s3
    scope: s3://acme-analytics/
    region: us-east-1
    access_key_id: replace-me
    secret_access_key: replace-me
  lake-catalog:
    type: iceberg
    credential: client-id:client-secret
users:
  dashboard:
    auth:
      method: scram-sha-256
      verifier: pivot-scram-sha-256$...

The vendor’s own benchmark numbers#

From the Pivot homepage, checked 6 October 2026: query time relative to the fastest engine, lower is better. Epsio Labs ran every engine itself, on one AWS c8gd.metal-48xl, with the harness in its pivotlake/benchmarks repository. Treat these as claims to reproduce, not independent results.

Engine (storage)ClickBench, 43 queriesTPC-H SF1000Star Schema SF1000
Pivot (Parquet)1.09×1.00×1.00×
ClickHouse (native)2.17×4.68×3.36×
DuckDB (Parquet)4.31×2.16×2.58×
DuckDB (native)4.17×3.10×5.00×
DataFusion (Parquet)3.09×7.37×12.86×
ClickHouse (Parquet)3.61×27.14×120.51×
Spark53.73×43.59×44.38×
  • TPC-H and SSB are scored as one timed run of all queries after dropping the page cache; the ClickBench column uses ClickBench’s own scoring, a geometric mean of per-query ratios.
  • Pivot’s authors also added pivot-parquet entries to the official ClickBench repository; the pull request was merged on 1 October 2026. Compare on the public dashboard, same machine only.

See it in a real stack

No architecture uses Pivot yet. Drop it into the playground and wire it up yourself.Open playground →

Benchmarks

Benchmark · ClickHouse Inc.ClickBenchHow fast analytical databases run 43 SQL queries over one 100-million-row table of web analytics events, on the same cloud machines.Includes Pivot · 7 caveats to read first
How to read a benchmark →
Where it came from2025–2026

Epsio Labs, founded by Gilad Kleinman and Maor Kern, sells Epsio, an engine that keeps the results of heavy SQL queries up to date incrementally inside an existing database. Pivot is built by Epsio’s team, with nearly all commits from Kern and one colleague, and tackles a nearby problem: teams that keep their data in open table formats on object storage still copy it into a separate real-time database, such as ClickHouse or Druid, when dashboards and apps need fast answers for many users.

Kern’s first commit, a per-core task runtime called Dispatch, landed in December 2025. The team took DuckDB’s parser and optimiser instead of writing a planner and spent its effort on execution: morsel-sized batches that stay in CPU cache, its own 2 MB block allocator on huge pages, direct I/O with io_uring, and pruning tuned for Parquet. The docs say the initial codebase was written without LLMs, and that LLMs are now used to hunt for local optimisations that humans then redesign before merging.

The project moved to its own pivotlake GitHub organisation in August 2026, tagged its first release candidate that month, submitted results to ClickBench in September and tagged v0.1.0 in October.

Why it’s built this way

Query open formats instead of a proprietary store
Data already sits in Iceberg or Delta Lake for other engines. Writing Pivot’s own tables as Delta Lake too means nothing is locked in a format only Pivot can read.
Reuse DuckDB’s planner, write a new executor
Parsing, binding and logical optimisation are mature in DuckDB. Owning only the physical operators let a two-person team concentrate on scheduling, memory and I/O.
Thread per core with work stealing
Context switches and cold caches cost more than the computation in analytical queries. One worker per core that prefers cache-hot work, stealing only when idle, keeps cores busy without that cost.
The PostgreSQL wire protocol
Every language and BI tool already has a PostgreSQL driver, so applications can connect without a new client library.

Timeline

  1. 2025

    First commit in December: the Dispatch per-core runtime

  2. 2026

    GitHub repository created in March under Epsio Labs

  3. 2026

    Moves to the pivotlake organisation; first release candidate in August

  4. 2026

    ClickBench entries merged on 1 October; v0.1.0 tagged on 5 October

Sources14 · facts checked 6 October 2026

Improve this page on GitHub