The same wire protocol. A much smaller database.
psql and PostgreSQL drivers connect to UltraFabric today with a token as the password. Behind the protocol is a deliberately small SQL subset with one property PostgreSQL does not have: every plan is checked for tenant isolation before it runs. No benchmark against PostgreSQL has been run yet.
What exists, and what does not
The only SQL numbers in the repository are through UltraFabric's own gateway. They say how UltraFabric behaves, not how it compares.
pgbench against UltraFabric's gateway, prepared statements
Loopback TCP → gateway → node, shared development host, 23 Oct 2026, commit 4362b9d. No PostgreSQL run on this host exists; the "before" column is UltraFabric one day earlier, without key seeks.
| Statement | Clients | Avg ms | Before | Stmts/s |
|---|---|---|---|---|
| Primary-key SELECT | 1 | 0.143 | 5.52 | 6,984 |
| Primary-key SELECT | 8 | 0.767 | 41.7 | 10,608 |
| GROUP BY with count and sum | 1 | 5.38 | 5.64 | 189 |
| Single-row INSERT | 1 | 0.922 | 1.06 | 1,149 |
| Single-row INSERT | 8 | 6.17 | 6.8 | 1,296 |
No comparative claim. The roadmap's target for the transactional engine is at or above PostgreSQL 17 on single-node OLTP (pgbench and a TPC-C-like run). It will be measured on a dedicated benchmark host with the raw results published. Until then this page makes no speed claim against PostgreSQL.
Works today
CREATE TABLE with a primary key and NOT NULL; INSERT, UPDATE and DELETE as atomic statements; SELECT with WHERE, inner and left joins, GROUP BY, count/sum/avg/min/max, ORDER BY, LIMIT, OFFSET; key lookups and ranges that read only the matching rows.
BuiltNext
BEGIN/COMMIT/ROLLBACK on the engine's snapshot transactions, RETURNING, ON CONFLICT, pg_catalog and information_schema, then one real application's suite.
In progressMigration
Copy-and-follow from PostgreSQL with reverse change capture for rollback is designed for the first-hosted-tenant phase.
PlannedLogin
RS256 token as the password, verified at the gateway (issuer, audience, expiry) and again at the node; a token signed with another key is refused with 28P01. Accepted only over TLS or from the same machine.
BuiltWhere PostgreSQL is ahead
A comparison that hides the other side's strengths is advertising. These are the points a buyer would find anyway.
Transactions
PostgreSQL has BEGIN, COMMIT, ROLLBACK, savepoints and serializable isolation. UltraFabric's storage engine has snapshot-isolation transactions, but SQL cannot open one yet: each statement is its own atomic step, and several writes in one query string are refused.
The whole language and the ecosystem
Subqueries, WITH, UNION, DISTINCT, HAVING, window functions, SQL functions such as upper(), RETURNING and ON CONFLICT all fail with 0A000 on UltraFabric today. Extensions, tooling and three decades of operational knowledge have no counterpart.
pg_catalog and information_schema
Database GUIs and ORMs read these when they connect. UltraFabric does not serve them yet; that is the next SQL phase.
Replication, backups, a hosted service
All planned for later phases. UltraFabric has not had a long soak test, a run on dedicated hardware, or a backup restored for real.
What PostgreSQL does not offer
Built and tested today, not planned.
Isolation verified on every plan
Every data node checks every plan before executing a single operator: tenant-isolated, policy-filtered, masked above the requester's clearance. The optimizer, cache and gateway are untrusted plan authors. PostgreSQL's row-level security is a policy you write and can forget.
BuiltTenant as a hidden key range
Tables carry a tenant key you can neither read, filter on nor write. Primary keys are unique per tenant; two tenants can both hold an order 1. Schema changes need a separate operator credential that can never read tenant data.
BuiltRow and columnar tables in one SQL
CREATE TABLE … WITH (storage = columnar) gives an append-only column-oriented table with the same types, SQL and check as a row table.
BuiltIdentity checked twice
The token is verified at the gateway and again at the data node, which never takes the gateway's word for who is asking. The node itself never listens on the network.
BuiltStatus today
Protocol yes, SQL partly, catalog not yet
The gateway serves the simple query protocol psql uses and the extended protocol most drivers use by default, with $1 parameters in text and binary formats; the Go driver pgx runs in its default mode in the end-to-end test. Types: smallint, int, bigint, real, double precision, numeric(p,s), text, boolean, uuid, date, timestamp, bytea, with no silent lossy conversion. Numbers follow PostgreSQL's typing, and errors come back as PostgreSQL SQLSTATEs (23505, 42P01, 42703, 42883, 23502, 42501, 22012, 22003, 53200). Everything unsupported fails at once with 0A000 and names the feature. The full list is in SQL and psql.
The gate for the SQL phase is one real application's test suite passing against UltraFabric unchanged. It has not passed yet.
Has UltraFabric been benchmarked against PostgreSQL?
No. The only pgbench runs are against UltraFabric's own gateway, with no PostgreSQL baseline on the same host. The roadmap's target, at or above PostgreSQL 17 on single-node OLTP, will be measured on a dedicated benchmark host and published with the raw results; until then no comparative number exists.
Will my ORM work?
Not yet. ORMs read the pg_catalog and information_schema tables when they connect and need BEGIN/COMMIT; both are the next SQL phase, whose gate is one real application's test suite passing unchanged.
Can I migrate a PostgreSQL database today?
No. Copy-and-follow migration with reverse change capture for rollback is designed for the first-hosted-tenant phase and is not built.
Run the same benchmark yourself.
Every report names its commit, tool invocation and raw result file. Early-access teams receive the scripts with the build.