SurrealDB 3.3 Lets Any Postgres Client Connect and Streams Query Results, but Does Not Speak ANSI SQL
SurrealDB 3.3 adds a Postgres wire-protocol listener, row-by-row result streaming and 15 security fixes, though the docs say it speaks SurrealQL, not ANSI SQL.
Editor's Note ·
- Correction:
- The article and its summary say the release notes list 15 security advisories or fixes. The SurrealDB 3.3 release notes give no total; they list 16 advisory entries (covering 21 distinct GHSA identifiers) plus two further security fixes that the notes say have no separate advisory.
- Clarification:
- The article reports row-by-row result streaming alongside the Postgres listener. The release notes describe streaming as available over the new gRPC transport, the query_stream WebSocket RPC method and the embedded Node.js and browser engines, and do not say the Postgres listener streams. The docs also say ANSI SQL is 'not yet supported' over the Postgres protocol, rather than ruling it out permanently.
Overview
SurrealDB 3.3 is out, and its headline feature is compatibility at the connection layer. According to the SurrealDB 3.3 release notes, “any Postgres client or driver, including psql, JDBC, npgsql and tokio-postgres, can now connect to SurrealDB.” The protocol documentation adds an important caveat: “The name ‘Postgres protocol’ describes the transport layer, not the query dialect.”
What We Know
Postgres wire protocol. Per the protocol documentation, the listener supports simple and extended query flows, prepared statements, interactive transactions, TLS, query cancellation and SCRAM-SHA-256 authentication, and it is switched on with the --postgres-bind flag. The release notes say that “DEFINE USER now stores a SCRAM verifier alongside the password hash.” Clients speak SurrealQL by default, with an optional ISO GQL dialect, according to the documentation.
Documented limits. The documentation lists no ANSI SQL translation, no pg_catalog emulation (so schema browsers and some GUI tools will not work), no LIVE queries, no COPY, and no GQL inside BEGIN…COMMIT blocks.
Streaming results. The release notes state: “Query results now stream to the client row by row instead of arriving as one buffered response.”
Graph and index performance. According to the release notes, “Graph adjacency is now stored in compact blocks,” and “traversals over high-degree vertices and from many starting records run substantially faster.” The same page says that a query filtering on several indexed fields “reads only the records that match all,” and that “indexed writes run 2.3 to 2.6 times faster” for full-text indexes. Those are the vendor’s own figures; no independent benchmark is cited.
Transactions and access control. The release notes describe locked reads: “SELECT ... FOR UPDATE registers the records it reads for conflict detection.” They also add that “DEFINE ACCESS ... AUDIENCE rejects a JWT whose aud claim names a different service.”
Storage and search. File buckets can live in AWS S3 and S3-compatible stores, Google Cloud Storage or Azure Blob Storage, per the release notes, which also add support for Chinese, Japanese and Korean full-text search.
Security fixes and breaking changes. The release notes list 15 security advisories addressed in this release for v3.2.4 and earlier, including a critical cross-tenant access issue. Breaking changes listed on the same page include ISO GQL being enabled by default, a reversed UPDATE/UPSERT evaluation order, and a changed DEFINE MODULE syntax.
What We Don’t Know
- How the Postgres listener performs under real workloads, or how well common drivers and ORMs behave when they expect ANSI SQL; neither source provides testing data.
- Whether the performance gains hold outside the vendor’s own scenarios.
Analysis
The Postgres listener lowers the cost of connecting existing tooling, since drivers and psql work as transports. The documented lack of ANSI SQL and pg_catalog support, however, means applications written for Postgres queries would still need to be rewritten in SurrealQL or GQL. For operators, the release notes say “A 3.2 datastore upgrades in place” and that “3.3.0 applies its data migrations automatically on first start,” but also that “3.2 and 3.3.0 nodes do not fully interoperate,” which matters for rolling upgrades.