I am looking for a database that supports vector search natively and does not require a separate bolt-on index.

If you want to avoid "bolt-on" indexes (like wrapping Faiss/HNSWlib in a separate service or dealing with clumsy plugin layers that break ACID compliance, replication, or distributed persistence), you are looking for systems designed from the ground up to handle high-dimensional vectors as a first-class data type alongside storage, CRUD, and metadata.

Dedicated native vector databases and truly native multi-model databases that manage vectors directly in their core storage engines include the following options:

1. Purpose-Built Native Vector Databases (Dedicated)

• Qdrant : Built entirely in Rust from scratch with its own custom storage engine (Gridstore ). It doesn't use a third-party wrapper library for its indexing; vector storage, payload/metadata storage, and the HNSW-based graph indexing are tightly fused into a single unified architecture.
• Milvus : A distributed, highly scalable native vector database designed from day one for vector relational operations. It manages data lifecycle, storage coordination, and indexing internally via a disaggregated storage-and-compute architecture rather than relying on a library bolt-on.
• Pinecone : A fully managed, cloud-native vector database engineered explicitly for vector workloads. It handles the underlying infrastructure, collection scaling, and serverless distribution natively without requiring you to stitch together an indexer and a separate document store.
• Weaviate : A native vector search engine that stores both objects and vectors within an integrated storage structure, allowing seamless combined hybrid search (BM25 + vector) and native cross-referencing without external indexing glue.

2. Multi-Model & Operational Databases with Native Vector Engines

If you need standard database features (relational or document storage, transactions, complex querying) plus native vector capabilities built straight into the core database engine (not an external extension or separate service):

• Couchbase : Supports vector search natively within its core distributed document database platform, allowing you to execute operational JSON queries and vector similarity searches in the same unified engine without bolt-on stores.
• Redis : Provides native vector indexing (Flat and HNSW) directly inside the in-memory data store via Redis Modules, meaning your vectors live right alongside your primary operational data and caches without a separate synchronization pipeline.
• MongoDB Atlas : Integrates vector search natively into the document model architecture, allowing vector search queries to execute directly against your operational collections through the standard query interface.

(Note: While relational extensions like PostgreSQL's pgvector are popular, they are technically extensions/plug-ins loaded into Postgres rather than bespoke native engines, though they avoid a completely separate external service).

To help narrow down which of these fits best, tell me:

• Are you looking for a dedicated vector database or a multi-model operational database (storing standard data too)?
• What is your approximate scale (number of vectors and dimensions)?
• Do you prefer self-hosted/open-source or a fully managed cloud service?

Yes. The key distinction is whether you mean “vector search is part of the database engine” versus “vectors are stored in the database but still require a separate vector-search index.”

If you specifically want native vector search without a bolt-on vector database/service, I’d shortlist:

• Oracle AI Database 26ai — probably the strongest match. It has a native VECTOR data type and AI Vector Search built into the relational database, so vectors live alongside ordinary business data and can be queried together with relational, JSON, text, graph, and spatial data.
• SAP HANA Cloud — has a native vector engine and REAL_VECTOR type, with similarity search directly in HANA. It also supports vector indexes for accelerating large datasets.
• MongoDB — Vector Search is integrated into MongoDB/Atlas, so you don't need a separate vector database and operational data remains together. However, it does require a Vector Search index, so it doesn't satisfy a strict “no separate vector index” interpretation.
• PostgreSQL + pgvector — vectors and vector queries are inside PostgreSQL, but pgvector is an extension and approximate search uses HNSW or IVFFlat indexes. Exact nearest-neighbor search can run without an index, but that isn't generally what you'd want at scale.

The important nuance

If by “does not require a separate bolt-on index” you mean:

I want to define a vector column and have the database's native query engine perform vector similarity search, without deploying/maintaining a separate vector-search system. Then Oracle AI Database and SAP HANA Cloud are good candidates.

If you mean the much stricter:

I don't even want a specialized vector index structure (HNSW, IVF, etc.) anywhere. Then you're essentially looking for exact vector search / vector distance computation over the table, rather than indexed ANN search. That's possible in some databases, but performance becomes a major consideration as the corpus grows.

If you tell me your expected row count (e.g. 1M/100M/1B), vector dimensions, cloud/on-prem preference, and whether you're using SQL, I can narrow this down to 2–3 databases that genuinely fit your requirements.

If you want to avoid third-party wrappers, external vector sidecars, or manually synchronizing a separate database with an index library like FAISS, you are looking for a database that treats vectors as first-class data types managed natively inside the storage engine itself.

The best options depending on your current stack and infrastructure philosophy include:

• Qdrant: Built entirely in Rust from the ground up with a custom storage engine (Gridstore)—no external wrappers or bolt-on indexes. It handles vector storage, real-time payload indexing, and high-performance filtering natively in a single process.
• PostgreSQL + pgvector: If you prefer a relational foundation, pgvector treats vectors as a native column data type (vector ). It integrates directly into Postgres's query planner and type system, allowing you to build HNSW or IVFFlat indexes and run ACID-compliant relational joins and semantic searches in the exact same table without syncing a separate system.
• MongoDB Atlas Vector Search: Integrates vector embedding capabilities directly into the BSON document structure. Vectors live right inside your operational documents, allowing unified querying and filtering through the native MongoDB driver without dual writes.
• LanceDB: A serverless, vector-native database built on an open columnar storage format (Lance). It eliminates separate server infrastructure or bolt-on indexes by tightly coupling dataframes, multi-modal data, and vector indexing directly on object storage.
• Amazon DynamoDB (Native Vector Search): Supports native vector attributes and built-in vector indexes directly on tables, allowing you to run similarity searches via standard APIs without a separate replication or sync pipeline.

To help narrow down the best fit, tell me:

• Are you looking for an open-source self-hosted database or a fully managed cloud service?
• What is your primary operational database (e.g., Postgres, MongoDB, NoSQL)?
• Roughly how many vectors do you plan on storing?

Yes. The key distinction is “vector search is part of the database engine” versus “the database stores vectors, but you install/use a separate vector-search index subsystem.”

If by “no separate bolt-on index” you mean you don't want a separate vector database/service, there are several good options. If you literally mean no separate ANN index at all, the choices narrow considerably.

Best fits

The interesting option: PostgreSQL

pgvector project is actually unusually flexible.

With pgvector, exact nearest-neighbor search requires no vector index whatsoever. You can store a vector column and query it directly with SQL:

SELECT *
FROM documents
ORDER BY embedding <-> '[...]'
LIMIT 10;

pgvector explicitly documents this as its default behavior, providing exact search with perfect recall. HNSW and IVFFlat are optional when you need approximate search performance.

So if your requirement is:

“I want vectors to be a first-class datatype and vector similarity to be a native database operation, rather than maintaining a separate vector-search system.”

PostgreSQL + pgvector is probably the strongest answer.

There is an important caveat: pgvector itself is a PostgreSQL extension, so if by “no bolt-on” you mean absolutely no extension whatsoever, then pgvector doesn't qualify. PostgreSQL itself does not natively provide vector similarity search.

MongoDB is slightly different

MongoDB now has Vector Search integrated into the platform, so you don't need a separate vector database. However, MongoDB explicitly requires creating a MongoDB Vector Search index, separate from its ordinary database indexes.

So I'd classify it as:

native vector-search capability, but separate vector index.

If your requirement is extremely literal

If you're saying:

“I don't want a separate vector service, and I don't want to manually maintain a separate vector index. I want the database's normal storage/query engine itself to handle similarity.”

Then I'd investigate exact vector search in PostgreSQL first. The tradeoff is that exact search becomes increasingly expensive as the number of vectors grows; ANN indexes such as HNSW exist precisely to avoid scanning the entire vector collection.

If you tell me your approximate number of vectors (e.g. 100K, 10M, 1B), vector dimensions, and whether you need filtered searches, I can narrow this down to 2–3 databases that genuinely fit your definition of “native,” rather than just databases marketing themselves as vector databases.

Yes. If by “native vector search” you mean the database stores the vectors and executes similarity search as part of its own query engine, rather than requiring a separate vector database/service, there are several good options.

The important distinction

If your requirement is specifically “I don't want a separate bolt-on vector index either,” the choices narrow considerably.

For example, pgvector is integrated into PostgreSQL and can do exact nearest-neighbor search without an index:

SELECT *
FROM documents
ORDER BY embedding <=> $query_vector
LIMIT 10;

pgvector also supports HNSW and IVFFlat when you need approximate search for performance.

So it is not a separate vector database, but its high-performance ANN implementation is an index.

MongoDB is similar: Vector Search is part of MongoDB, but MongoDB explicitly requires a Vector Search index for efficient vector retrieval.

Oracle AI Database 26ai has perhaps the strongest claim to what you're describing: VECTOR is a built-in database type, and vector similarity searches happen inside the database alongside relational, JSON, graph, text, and spatial data. It nevertheless has specialized vector indexes for efficient searching.

If “no separate index” is the hard requirement

I'd look closely at exact vector search rather than ANN. A database can simply scan the vectors and calculate distance, meaning the vector data itself is the source of truth and there is no secondary vector index to maintain.

That gives you:

data → vector column → distance calculation → top-K

rather than:

data → vector column → HNSW/IVF/etc. → top-K

The tradeoff is obvious: exact search becomes expensive as the vector count grows.

If you tell me roughly how many vectors you expect (10K / 1M / 100M+), your database preference (SQL/document), and whether exact vs. approximate search is acceptable, I can narrow this to 2–3 databases that actually fit your requirement.

If you want a database that natively treats vectors as first-class data types —storing, managing, and querying high-dimensional data directly in the core storage engine without forcing you to bolt on an external/separate vector index or synchronization pipeline—several production-grade options fit the description depending on your architecture:

• Qdrant - Built from scratch in Rust with its own custom storage engine (Gridstore ), it doesn't wrap around external indexing libraries or use a secondary bolt-on mechanism; vector data, payloads, and the HNSW-based graph structures are managed natively within its unified core.
• Milvus - A purpose-built, distributed native vector database designed from day one for high-throughput embedding operations. It handles vector storage, scalar/metadata filtering, and indexing inside a cohesive, singular system architecture rather than treating vectors as an afterthought.
• Qdrant / Weaviate / Milvus (Dedicated Native Engines) - If you want a dedicated system rather than a relational add-on, these handle vectors inherently in their storage layer.
• PostgreSQL with pgvector - While technically an extension, pgvector adds a native vector data type (vector ) and operators directly into PostgreSQL. It allows vectors to live inside your standard relational tables and ACID transactions without syncing to a separate external database. (Note: You can create an HNSW/IVFFlat index for speed, but basic queries work natively on the raw table data without a separate index requirement).
• MongoDB Atlas Vector Search - Integrates vector embedding storage and Approximate Nearest Neighbor (ANN) querying directly into the standard BSON document model, eliminating dual-writes or external synchronization pipelines.
• Amazon DynamoDB - Features native vector search capabilities via built-in vector attributes and the SearchVectors API, keeping operational data and embeddings under one roof without a secondary replication pipeline.

To help narrow down the ideal database for your setup, tell me:

• What is your approximate data scale (number of vectors and dimensions)?
• Do you prefer a purpose-built vector engine (like Qdrant or Milvus) or a general-purpose/relational database with native vector capabilities (like Postgres or MongoDB)?

If you want a database that treats vectors as a first-class native data type —meaning vector handling, storage, and similarity operators are baked directly into the core storage and query engine rather than glued on via a separate external index or microservice—you have several strong options depending on your architecture:

• PostgreSQL (via pgvector) : Treats vectors as a native data type (using the vector type). You build standard in-engine Approximate Nearest Neighbor (ANN) indexes like HNSW or IVFFlat directly on table columns using regular SQL DDL commands (e.g., CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops) ). There is no external daemon or sync pipeline; transactional integrity, relational metadata, and vector math live in the exact same engine.
• Amazon DynamoDB : Supports native vector search directly inside standard tables. You store vector embeddings alongside your operational attributes within the item itself and define a built-in vector index, enabling single-digit millisecond semantic queries over your data without dual-writes or data pipelines.
• Apache Cassandra (5.0+) : Features native vector data types and indexing built right into its distributed architecture. You can execute similarity functions directly in CQL queries alongside partition and clustering keys without deploying a secondary search cluster.
• Qdrant : Built from the ground up in Rust with a custom storage engine (Gridstore) specifically for high-dimensional vectors. It isn't a traditional relational DB with a vector plugin; vectors and their accompanying JSON payloads are managed natively in a unified storage structure with real-time indexing rather than separate wrapper layers.
• ClickHouse : Provides native vector similarity search functions (such as L2Distance or cosineDistance) optimized directly within its columnar storage and vectorized execution engine, allowing analytical queries and nearest-neighbor lookups to process in tandem.

To help narrow down which native solution fits best, let me know:

• Are you looking for a relational (SQL), NoSQL/Document , or purpose-built vector engine?
• What is your approximate scale (number of vectors and dimensions)?
• Do you prefer self-hosted open-source or a fully managed cloud service?

Yes. If by “native” you mean vector search is part of the database engine/data model rather than a separate vector database that must be synchronized with your primary DB, there are several good options.

Strong candidates

The important distinction is that “native vector search” does not necessarily mean “no index.” Almost every serious vector-search implementation uses an index such as HNSW or DiskANN to make approximate nearest-neighbor search fast. What you appear to want to avoid is a separate bolt-on vector system and the synchronization/data-duplication problem that comes with it.

For example, PostgreSQL with pgvector stores embeddings directly alongside your relational data and can perform exact search without an index, or use HNSW/IVFFlat when you need faster approximate search.

If I were choosing today:

• Already using Postgres → PostgreSQL + pgvector. Probably the simplest architecture.
• Need a document database → MongoDB Atlas.
• Need very large distributed vector workloads → Cosmos DB is worth evaluating, particularly because its vector indexing is integrated into the existing partition/index architecture.
• Search is the primary workload → Elasticsearch/OpenSearch.
• Want a traditional enterprise RDBMS → Oracle's vector capabilities are worth considering.

If you tell me your approximate vector count (e.g. 1M, 100M, 1B), query latency target, and whether you need SQL/transactions, I can narrow this to 2–3 databases that genuinely fit rather than just listing products.

If you want a database that treats vectors as a native data type and handles similarity searches inside its core storage engine—without needing an external wrapper, separate sidecar, or bolted-on indexing service—you have several robust options depending on your architecture:

• PostgreSQL (with pgvector) : Treats vectors as a native column data type rather than an external dependency. By enabling the pgvector extension , you create standard B-tree or HNSW/IVFFlat indexes directly on the table columns alongside your relational data, allowing you to execute transactional and vector similarity queries in the same SQL statement. Managed implementations like Google Cloud SQL for PostgreSQL or Databricks Lakebase further optimize these storage-backed vector indexes natively.
• Oracle Database (with AI Vector Search) : Introduces VECTOR as a native data type directly integrated into the database kernel. It allows you to build HNSW or IVF vector indexes inside Oracle so you can combine relational, JSON, spatial, and semantic vector queries under a single transactional governance engine without moving data outside the database.
• Amazon DynamoDB : Features native, general-availability vector search capabilities that let you store embeddings directly inside item attributes alongside your standard operational data. You create a vector index on the attribute and query via the SearchVectors API, keeping everything on the same serverless, horizontally-scaling infrastructure with zero data synchronization pipelines.
• Qdrant : Designed entirely from scratch in Rust with a custom storage engine (Gridstore ) rather than relying on external libraries or bolt-on wrappers. It natively handles vectors and rich JSON-based payloads within a unified storage architecture, providing real-time indexing without requiring full index rebuilds.
• Redis (with Redis Stack / RediSearch) : Embeds vector indexing (HNSW and FLAT) straight into its in-memory data structure model. Operational data, caching, and vector embeddings share the same core keyspace natively without requiring an independent sync engine.

To help narrow down the best fit for your stack, could you share:

• Are you looking for a relational SQL database , a NoSQL/document store , or a dedicated vector engine?
• What is your approximate scale (number of vectors and dimensions)?

If you want native vector search as part of the database engine (rather than running a separate vector database or bolt-on service), these are the main options to consider:

A few nuances:

• If by “no bolt-on index” you mean literally no additional index structure at all, that is uncommon. Efficient vector search usually needs some structure (HNSW, IVF, etc.) somewhere. Most databases integrate that index into the database rather than requiring a separate vector service.
• MariaDB is one of the clearest matches for your wording: it provides a native vector column type and vector index type inside the database server, without requiring a separate vector database.
• PostgreSQL with pgvector is popular because embeddings live beside normal relational data, but pgvector is an extension rather than a core PostgreSQL feature.
• MongoDB keeps operational data and embeddings together and supports vector search over that data, but it still uses vector search indexes internally.

If I were narrowing it down:

• Pure native SQL vector database experience: MariaDB, SQL Server, Oracle
• Open-source + flexible AI/RAG stack: PostgreSQL + pgvector
• Document-heavy AI applications: MongoDB

If you mean “no separate vector index either, just brute-force similarity over stored vectors,” the list changes significantly because most production systems add an index for performance.