PostgreSQL Just Got a GPU: Introducing CYBERTEC PGEE GPU

GPU execution inside PostgreSQL

Tables that grow into the hundreds of millions of rows tend to expose the same weakness: dashboards that once loaded instantly now take half a minute, monthly reports run overnight, and the usual remedy is to copy the data into a separate analytics system. That second platform brings its own burdens — two systems to operate, a pipeline that can break silently, data that lags behind, and a second source of numbers that can disagree with the first.

CYBERTEC PGEE GPU moves the heavy analytical portion of a query onto NVIDIA GPUs while it runs inside PostgreSQL. The database remains PostgreSQL, so SQL, schema, drivers, transactions, backups, monitoring and access control are unchanged; applications require no modification and no query has to be rewritten.

Against a dashboard query over 500 million retail orders, the difference looks like this:

On a larger rig with eight GPUs and a billion-row order table, a query that needed 159 seconds on one CPU core completes in 2.8 milliseconds — a factor of 57,063 — while the machine sustains 452 billion rows scanned per second. On 4 × NVIDIA H200 cards, the figure quoted is 2.1 trillion rows per second.

Why more CPU cores stop helping

The reflex response to a slow query is a bigger server, but a large scan is bound by how quickly data leaves memory, not by core count. Beyond roughly sixteen cores, additional CPUs mostly idle. The numbers above show the pattern: twenty cores took the dashboard query from 31 seconds to 3.4 seconds, and the next hundred cores barely improved on that.

A GPU is not just a larger pool of cores. It carries its own memory and far more bandwidth: a single current-generation card provides about 26 times the memory bandwidth of the mainstream server processor in most racks today, with roughly 20,480 parallel lanes to use it, versus 128 CPU cores. Adding CPUs supplies compute without bandwidth and therefore stalls; a GPU adds both together.

Correctness as a precondition

Many acceleration products ask you to trade accuracy for speed through approximate aggregates, relaxed consistency or "eventually correct" results. That may be acceptable for an internal dashboard, but not for a risk report or a regulatory filing.

CYBERTEC's approach compares every accelerated result against what stock PostgreSQL returns, character for character, in continuous integration and on every change. If the two disagree, the GPU result is thrown away and PostgreSQL's answer is used instead. A two-hour concurrency stress test produced 18,329 correctness checks with zero mismatches, and zero incorrect reads across 345,000 concurrent transactions: the worst case is a slower query, never a wrong answer.

What changes when the work becomes interactive

The practical shift is that workloads previously considered impractical become routine:

• Overnight batches dissolve into questions. An aggregate that finishes in 15 milliseconds leaves nothing to schedule.
• Analysts stop pre-deciding. When the raw table answers interactively, nobody builds a cube or summary table ahead of time.
• Fraud and risk checks run inside the transaction rather than after the fact.
• Whole-table questions get answered. You query all of it, not a sample or the last quarter.

Availability and evaluation

Prospective users are benchmarked against their existing CPU baseline before any commitment, and CYBERTEC states it will say whether the product can help — the queries where it loses are already documented.

PGEE GPU supports PostgreSQL 19. Deployment follows standard PostgreSQL environments across cloud and on-premises, including on-premises servers, Kubernetes, AWS, Microsoft Azure and Google Cloud, and the product will also be accessible via CYBERTEC Scalefield.