GreptimeDB Achieves PostgreSQL Compatibility Using Rust, pgwire, and DataFusion

The Postgres wire protocol has no opinion about what lives behind it. It does not care whether the server is running Postgres internals, a columnar query engine, or anything else. That architectural neutrality is what GreptimeDB's engineering team built on, publishing a detailed breakdown of how they wired the PostgreSQL client protocol onto a Rust-native stack using pgwire and Apache DataFusion.

The blog post, published April 2 on Greptime's engineering site, arrives at an interesting moment. The 2025 acquisitions of Neon by Databricks and CrunchyData by Francisco Partners had already pushed PostgreSQL back to the center of industry conversation, and the Greptime team framed their writeup explicitly inside that context: two distinct strategies have emerged for teams that want to plug into the Postgres ecosystem, and GreptimeDB represents one of them.

Those two strategies are what the post calls "bottom-up" and "top-down." Bottom-up means embedding Rust code inside a running Postgres instance using a framework like pgrx, which is the model ParadeDB follows. Top-down means reimplementing the wire protocol and client-facing semantics externally, so the Postgres server itself never enters the picture. GreptimeDB took the top-down route from its earliest versions.

The central tool for that route is pgwire, an open-source Rust library that the post's author created and maintains. The analogy offered in the writeup is precise: pgwire does for the Postgres wire protocol what hyper or axum does for HTTP. It handles the six defined segments of the protocol, covering the startup handshake and authentication, simple queries, extended queries with server-side statement caching, Copy operations for bulk data movement, and cancellation semantics. Critically, the simple query subprotocol does not actually require SQL input at all; pgwire exposes both a low-level message-handling API via SimpleQueryHandler::on_query and a higher-level data-oriented API via SimpleQueryHandler::do_query, giving implementers control over how much of the Postgres surface they want to reproduce.

Sitting between pgwire and GreptimeDB's actual execution layer is datafusion-postgres, a project the team maintains as a separate adapter library. It bridges pgwire, the DataFusion columnar query engine, and Arrow's data format, and it includes a partial pg_catalog implementation to satisfy the metadata queries that tools like DataGrip issue automatically on startup. The team acknowledged that full pg_catalog coverage remains a moving target since many system tables are deeply tied to Postgres internals, so the implementation targets the subset of catalog tables that real-world tooling actually queries.

The payoff is practical: standard clients, psql, JDBC drivers, and anything built on libpq, connect to GreptimeDB without modification. And because pgwire is a general-purpose library, the same stack has been adopted by projects well outside Greptime's own roadmap. PeerDB, now part of ClickHouse, uses it. SpacetimeDB, which targets real-time online games, uses it. Fly.io's corrosion project and the recently launched db9.ai are both built on it. The author also presented datafusion-postgres at the DataFusion San Francisco meetup, signaling that this layer of the Rust database stack is being treated as genuine shared infrastructure rather than a one-database implementation detail.

The writeup also gestures toward what comes next: integrating geoarrow and geodatafusion on top of this same stack would produce a PostGIS-compatible surface. For Rust teams weighing whether to target the Postgres extension model or build their own Postgres-compatible interface, GreptimeDB's architecture is now a documented, deployed reference point.