The only vector database built for real-time operational data at GPU speed.

Q: Which embedding models does Kinetica work with — do I have to run my own?

Kinetica calls embedding models from inside SQL via CREATE MODEL and GENERATE_EMBEDDINGS() . Supported providers include OpenAI , NVIDIA NIM , and any locally hosted model that exposes a compatible inference endpoint. The embed-then-search pipeline collapses into a single SQL statement — no sync job, no second store, no embedding drift behind your source data.

VectorGPUReal-timeHybrid

New embeddings are searchable the moment they land. Vector, filter, join, and time window — one SQL statement, one engine.

Start FreePowered by NVIDIA cuVS · CAGRA · HNSW

The Category

Stop running a second database for retrieval. Kinetica handles vector search alongside your analytics — no sync, no separate ops.

Milvus · Pinecone · Qdrant · Weaviate

Purpose-built for ANN — but it lives apart from your data.

The fastest at pure-vector workloads. The cost: it sits next to your data stack as a separate system, and your application code has to handle joins, consistency, and operations across both.

+Highest QPS on pure vector workloads
−Two systems to operate, secure, and sync
−Joins with structured data live in app code

The Mechanism

GPU brute-force serves queries the instant data lands. The index builds in the background and takes over seamlessly — search never blocks.

Progressive indexing · zero-lag vector search

incoming embeddingsGPU brute-forceindexed

No reindex wait

New embeddings are queryable the instant they land via GPU brute-force.

Tiered storage

Index parts migrate to lower-cost tiers automatically when GPU memory is constrained.

Algorithm fallback

When data isn't indexed yet, Kinetica falls back to other GPU algorithms — freshness SLAs hold.

The Numbers

5× faster to searchable. Top-3 QPS. Highest recall.

Load duration · less is better

5× faster to searchable

Time to make 10M × 768-dim embeddings queryable

Kinetica

1,217s

Milvus

5,714s

Zilliz

7,635s

Pinecone

14,170s

Qdrant

14,620s

Query throughput · more is better

Top-3 on QPS

Queries per second at 10M scale, low filter

Zilliz

378

Milvus

178

Kinetica

138

Pinecone

136

Qdrant

Recall · more is better

99% recall accuracy

% of true nearest neighbors returned in top-K

Kinetica

99%

Zilliz

97%

Milvus

92%

Pinecone

92%

Qdrant

89%

Source: VectorDBBench · 10M × 768-dim dataset · February 2024 run. Numbers shown as published; benchmark refresh in progress.

The Query

Vector similarity, structured filters, and joins execute together in one GPU-accelerated SQL statement.

Hybrid query · live + historical embeddings + filter

streamingreferenceresult

Capital markets · the question being asked

“Find today's breakout stocks — match live trading patterns against historical breakouts (filtered to mid- and large-cap), updated every second.”

Vector + JOINStructured filterStreaming + referencePostgres operators (<-> <=> <#>)Single SQL statementNo glue code

The Pipeline

Generate embeddings and search inside a single SQL statement — no embedding service, no sync job, no second store.

Other stacks

Five systems. Sync jobs. Drift.

The standard pattern: embed in one service, store in another, query through a third. Every hop adds latency, every sync window adds drift, every system adds operations.

Kinetica

One system. One SQL statement.

CREATE MODEL registers the embedding service. GENERATE_EMBEDDINGS() calls it from inside SQL. The result feeds straight into vector search — no sync job, no second store.

The ecosystem

Built on NVIDIA's open vector-search stack.

▲ Powered by NVIDIA cuVS

Open-source GPU vector search · CAGRA · IVF · clustering

rapids.ai/cuvs

Apache Lucene

Datastax

FAISS

Kinetica

Milvus

OpenSearch

Redis

Weaviate

Every partner above leverages the same NVIDIA-engineered ANN algorithms. Kinetica is the only one that pairs them with a full analytical query engine — so vector search composes natively with SQL, joins, time windows, and geospatial in a single query plan.

Vector search that fits inside the database your analytics already run on.

Start Free Read the docs

Frequently asked questions

What is Progressive Indexing, and how does it avoid the reindex wait other vector databases have?

Most vector databases require an index rebuild before new embeddings can be queried — which forces you to choose between freshness and latency. Kinetica's Progressive Indexing serves queries with GPU brute-force the moment an embedding lands, while a CAGRA + HNSW index builds in the background. When the index is ready, the query path switches over seamlessly. Newly written embeddings are searchable on arrival — no batch window, no stale results.

Can I run vector search alongside structured filters, joins, and time windows in a single SQL statement?

Yes. Vector is just another column type in Kinetica, so the optimizer plans across vector similarity, structured filters, multi-table joins, and window functions in one query plan. Kinetica supports the standard Postgres distance operators (<->, <=>, <#>) plus functions like L2_DISTANCE, and chooses pre- vs. post-filter automatically based on selectivity. No glue code, no application-side joins.

How does Kinetica compare to dedicated vector databases on benchmarks?

On VectorDBBench (10M × 768-dim, February 2024), Kinetica was 5× faster to make new embeddings searchable than the next-closest system, placed top-3 on QPS, and led on recall accuracy at 99%. Dedicated vector DBs like Zilliz still edge out raw QPS on pure-vector workloads — but they don't run analytics, joins, or filters in the same engine, so you pay for that lead in operational complexity.

Which embedding models does Kinetica work with — do I have to run my own?

Kinetica calls embedding models from inside SQL via CREATE MODEL and GENERATE_EMBEDDINGS(). Supported providers include OpenAI, NVIDIA NIM, and any locally hosted model that exposes a compatible inference endpoint. The embed-then-search pipeline collapses into a single SQL statement — no sync job, no second store, no embedding drift behind your source data.

What's the relationship between Kinetica and NVIDIA cuVS?

Kinetica is a member of the NVIDIA cuVS partner ecosystem, alongside Apache Lucene, Datastax, FAISS, Milvus, OpenSearch, Redis, and Weaviate. We share the same CUDA-native ANN algorithms — CAGRA, IVF-PQ, IVF-flat. The difference is what wraps around them: Kinetica is the only cuVS partner that pairs them with a full analytical query engine, so vector search composes natively with SQL, joins, time windows, and geospatial in one plan.

Will I hit a scale ceiling like I do with pgvector or other relational vector extensions?

No. pgvector and similar OLTP extensions bolt vector storage onto B-tree indexes and CPU-bound query engines that were never designed for high-dimensional similarity search — they hit a ceiling at millions of embeddings. Kinetica's storage is columnar, its execution is GPU-vectorized, and its indexes (CAGRA, HNSW) are purpose-built for billion-scale vector workloads. Scale is a capacity question, not an architectural one.