The GPU-native database. Since 2009.
Every analytical operation that benefits from GPU runs as a custom CUDA kernel inside Kinetica's query engine — not as a library call to RAPIDS, not as an opt-in module, not as a future capability. The planner routes work to CPU or GPU automatically. The developer never decides.
2.7×faster than AMD EPYC on the Coffee Shop benchmarkSee resultsGPU-native, not GPU-accelerated.
Three patterns dominate how databases use the GPU today. They look similar in marketing copy. They are structurally different in execution — and the shape of the engine determines what's possible, and what's permanently slower than it should be.
CPU engine, GPU offload.
The engine is CPU-native. The GPU is an optional accelerator that data is shipped out to, operated on, and shipped back from — once per operation.
- Drops onto an existing CPU stack with no rewrite
- Data moves CPU→GPU→CPU on every operation
- GPU support often "developing" or "future capability"
Every operation that benefits from GPU runs as a custom CUDA kernel.
Not "vector search runs on GPU." Not "joins can be offloaded." Nearly the entire analytical surface — aggregations, filters, window functions, joins, GIS, vector ANN — executes through CUDA kernels Kinetica has been writing for over a decade. Operations that don't benefit from GPU (parsing, auth, indexed lookups) stay on CPU where they belong.
What runs in VRAM
The operations where massive parallelism wins — fan-out across rows, SIMD-friendly math, embarrassingly parallel scans. Each one is a kernel Kinetica owns and has refined for over a decade.
- sum
- count
- count_distinct
- avg
- min / max
- stddev
- filters
- derived columns
- window functions
- equijoins
- predicate joins
- vector ANN · CAGRA · HNSW
- aggregate/statistics
- aggregate/histogram
- GIS rendering · ST_* functions
- RAPIDS-integrated ML inference
What runs on cores
The operations where branch prediction and cache locality matter more than parallelism. Forcing these through GPU adds latency, not removes it. Kinetica routes them to CPU automatically.
- query parsing
- validation
- deserialization
- indexed queries
- primary key joins
- column-indexed equijoins
- join post-processing
- table unions
- table projections
- merging partial results
- persist to disk
- resharding
- full-text search
- user authorization
- graph solvers · parallel CPU
The Kinetica query planner inspects each operator in the plan and routes it automatically. The developer never decides which columns live on GPU or which operations push to device. Other GPU databases ship a module the user must opt into per column. Kinetica's engine has been making that decision automatically since 2009.
RAPIDS is a library. Kinetica is a database.
NVIDIA's RAPIDS libraries (cuDF, cuML, cuVS, RAFT) are some of the best GPU primitives in the industry — but they're built for data science workloads, not enterprise real-time databases. Wrapping them in a CPU engine accelerates specific operations. It does not make the engine GPU-native.
Session-scoped dataframes, not a query engine.
cuDF runs inside a host process. There's no long-running query engine that holds GPU memory across millions of queries, no plan optimizer, no SQL surface. Every workload starts cold.
No transactional or locking model.
RAPIDS has no concept of concurrent writers, no isolation, no consistency guarantees. You can't have streaming ingest and queries hitting the same dataframe.
No HA, replication, RBAC, or recovery.
All the things an enterprise database has that a library doesn't — replication, role-based access, point-in-time recovery, distributed consensus — sit outside RAPIDS' scope.
Kinetica is a named cuVS integration partner — vector indexing and search through CAGRA run on the RAPIDS-maintained library. That's the right shape for that workload. For the rest of the analytical surface — aggregations, filters, joins, window functions, GIS, statistics — Kinetica runs its own decade-old library of custom CUDA kernels inside a distributed, lockless, transactionally-aware query engine. Best of both: NVIDIA's libraries where they belong, Kinetica's engine where the database lives.
Every layer NVIDIA ships, plugged in.
Not a logo wall. A working integration at each layer of NVIDIA's AI and accelerated-compute stack — from the CUDA kernel level all the way up to NeMo embedding models invoked through a single SQL function.
- CUDAEvery analytical CUDA kernel Kinetica ships — aggregations, filters, joins, window functions, GIS — written and refined inside the Kinetica engine.native since 2009
- cuVS / RAFT / CAGRAVector ANN indexing and search. Kinetica is a named integration partner on the official RAPIDS cuVS page.integrated 2024
-
NIMIn-database embedding generation. Define a Remote
Model in SQL, call
GENERATE_EMBEDDINGSduring batch or streaming ingest.since 2024 -
NeMo RetrieverEmbedding models on the same SQL surface.
embed-qa-4, Nemotron embeddings, and other NeMo models invoked exactly like any other Kinetica function.supported - AI EnterpriseCertified deployment stack. Kinetica runs on NVIDIA AI Enterprise software for production-grade enterprise AI deployments.certified
- Vera + RubinEarly-access benchmarks on Vera bring-up silicon. 2.7× faster than AMD EPYC and 1.77× faster than NVIDIA Grace on the Coffee Shop benchmark — before Vera ships.early access
A CUDA-native engine wins more on Vera.
NVIDIA Vera is purpose-built for the agentic and data-intensive workloads driving the next generation of AI infrastructure. Wider SIMD, higher memory bandwidth, NVLink-C2C coupling to Rubin GPUs, unified memory addressing. Every Vera advantage favors a database whose engine is already CUDA-native.
Total query time across 17 queries
Vera rewards engines built for the GPU.
NVLink-C2C between Vera and Rubin matters most when CPU and GPU code are tightly co-designed. Kinetica's planner already minimizes data movement between CPU and GPU; NVLink-C2C removes what little remains.
Unified memory addressing rewards engines that already treat GPU VRAM as a first-class storage tier. Bolt-on architectures still ship explicit device-push calls; Kinetica's storage layer has been GPU-tiered for over a decade.
Wider SIMD and higher core count map onto Kinetica's existing vectorized kernels with no rework. Engines that wrap RAPIDS as a library have to re-engineer their integration to take advantage; CUDA-native code just runs faster.
The GPU-native database. Built for what's next.
Real-time SQL on streaming and historical data — composed across vector, structured, graph, spatial, and time-series — executing on the only engine engineered around the GPU from the storage layer up.