Vector Indexes in Oracle AI Database 26ai: HNSW, IVF, Hybrid, and Operational Trade-Offs

Oracle AI Database 26ai

Vector Indexes in Oracle AI Database 26aiHNSW, IVF, hybrid indexing, and the operational trade-offs that decide whether a design stays useful in production

Oracle AI Database 26ai gives you more than one answer to the question “how should I index vectors?” That is a strength, but it is also where many designs go sideways. HNSW is a memory-centric graph for high-performance approximate nearest-neighbor search. IVF is a centroid-partitioned structure that is easier to rebuild and partition-manage when data shape changes. Hybrid vector indexing is a different class of system entirely: a document retrieval structure that fuses Oracle Text and semantic search into one query surface. The right choice depends less on slogans like “fastest” or “best recall” and more on your retrieval unit, filtering shape, DML pattern, RAC topology, and maintenance tolerance.

Best fit questionAre you ranking vectors, or retrieving documents?That single distinction usually separates HNSW and IVF from hybrid vector indexes.

Operational inflectionDML and partition churn matter as much as query speed26ai adds transactional HNSW behavior, IVF reorganization, online rebuild paths, and RAC-specific variants.

Practical goalChoose the index you can operateSelection criteria grounded in what Oracle documents, not synthetic benchmarks.

Contents

Nine sections covering which index family to choose, how filtering changes the answer, what RAC changes, when rebuilds become unavoidable, and which 26ai features help or constrain production.

01 Family mapWhat Oracle actually offers, and why the families are not interchangeable 02 HNSWGraph behavior, transactional consistency, persistence, and RAC 03 IVF and local IVFCentroids, probes, rebuilds, partitioning, and included columns 04 Hybrid vector indexDocument retrieval, Oracle Text integration, JSON, and filter-aware search 05 Filtering and query shapeWhy predicates often decide the winner more than raw ANN mechanics 06 Operations runbookDDL patterns, rebuild tactics, diagnostics, and failure-mode reasoning 07 Decision matrixA concrete framework for choosing HNSW, IVF, hybrid, or a mixed strategy 08 Pilot planA realistic rollout sequence for validating the choice in your own environment 09 FAQ and takeawaysShort answers to the questions teams usually ask late in the project

Section 01

Family map: Oracle 26ai gives you multiple index paths, not one “vector index” story

Oracle 26ai gives you three index families: graph-based HNSW, partition-based IVF, and hybrid vector indexing for document retrieval. Around those sit important operational variants — local IVF, transactional HNSW, RAC duplication and distribution, online rebuild, JSON support for hybrid, included columns, and scalar-quantized HNSW.

01

HNSW = graph-based ANNIVF = centroid-partition ANNHybrid = document retrieval pipelineLocal IVF = partition-aware variant

HNSW

Use when your core problem is high-performance approximate nearest-neighbor search over vectors and you are comfortable operating a memory-oriented graph structure.

IVF

Use when your vectors can be usefully grouped around centroids and you want a structure whose rebuild and partition behavior is often easier to reason about as data distribution changes.

Hybrid vector index

Use when the retrieval unit is a document or chunk and you want Oracle Text and vector similarity to work as one indexed retrieval system rather than stitching separate pipelines yourself.

Not interchangeable

Hybrid indexing is not simply “HNSW plus text.” It is a different product surface with a different API, maintenance model, and retrieval objective.

What 26ai added

Transactional HNSW with journals and snapshots, persistent checkpoints, RAC duplication and distribution modes, automatic and online IVF reorganization, hybrid JSON support, additional predicate support in hybrid search, online HNSW creation, and scalar-quantized HNSW. This post focuses on the operational side of those additions.

Section 02

HNSW: the memory-first graph index for fast ANN, with real operational consequences

HNSW is Oracle's graph-based in-memory index family. In 26ai, thinking of it as "fast approximate search" is not enough. You also need to understand journals, snapshots, full repopulation, checkpointing, and the difference between RAC duplication and RAC distribution.

02

Mental model

HNSW organizes vectors as a layered neighbor graph in the vector pool. Search walks the graph greedily to find candidates near the query vector. This is what gives HNSW its appeal: it is designed to reduce the amount of data examined while preserving high-quality approximate results. In Oracle terms, this is an In-Memory Neighbor Graph vector index.

Why teams choose it

When the workload is primarily ANN over vector columns, HNSW is often the first serious candidate because Oracle explicitly positions it as the fastest vector search index family it offers.

What it asks from you

Memory sizing, graph refresh behavior, and version-specific restrictions matter more than they do with IVF.

When not to force it

If your main challenge is document retrieval, text relevance, or filter-heavy chunk search, hybrid or IVF-based designs may be a better primary abstraction.

Creation and search parameters

Oracle exposes HNSW through CREATE VECTOR INDEX with ORGANIZATION INMEMORY NEIGHBOR GRAPH. The documented parameter surface includes target accuracy, distance metric, and HNSW-specific controls such as NEIGHBORS or M and EFCONSTRUCTION. Current 26ai documentation also covers scalar quantization for HNSW and an ONLINE creation path for non-distributed HNSW builds.

SQL - Basic HNSW creation

CREATE VECTOR INDEX docs_hnsw_idx
ON docs (embedding)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 90
PARAMETERS (type HNSW, neighbors 40, efconstruction 500);

SQL - Online HNSW creation

CREATE VECTOR INDEX docs_hnsw_idx
ON docs (embedding)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE EUCLIDEAN
WITH TARGET ACCURACY 95
PARAMETERS (type HNSW, neighbors 32, efconstruction 500)
ONLINE;

Important online-build nuance

Current Oracle documentation distinguishes sharply between HNSW and IVF here. HNSW has a documented ONLINE creation path. IVF documentation still states that online creation is not supported, even though online rebuild is. Distributed HNSW also has its own restriction: online distributed HNSW creation is not supported.

Transactional support is real, but it changes how you reason about freshness

Oracle 26ai documents transactional HNSW support through a combination of a private journal, a shared journal, and a persistent ROWID-to-VID mapping table. The crucial point is that DML against the base table does not immediately rewrite the in-memory graph itself. Oracle preserves read-consistent search results by combining graph traversal with exact handling of newly inserted and deleted vectors recorded in those journal structures.

That means HNSW in production is not just a graph. It is a graph plus maintenance structures that allow approximate search to remain transactionally consistent as rows change. As DML accumulates, Oracle documents two refresh mechanisms: incremental snapshots and full repopulation. Snapshots add new vectors and mask deletes; full repopulation builds a fresh graph while the older graph remains in service until cutover.

How to think about freshness

When both query volume and DML rate matter, HNSW freshness is a managed approximation — not a structure rewritten row by row. That is how it is designed to work, not a limitation to work around.

Persistence and checkpoints

Oracle documents persistent checkpoints for HNSW topology and metadata. Checkpointing is enabled by default and is created during index creation or repopulation events. This matters because recovery and RAC behavior lean on these persisted graph artifacts rather than treating HNSW as a purely ephemeral cache.

RAC changes the answer: duplication and distribution are different choices

26ai documents two RAC stories for HNSW, and you should treat them as separate operating models rather than minor configuration switches.

RAC mode	What Oracle documents	Why you pick it	Main caveats
Duplicated HNSW	Each RAC instance holds a full copy of the HNSW graph. Creation is centralized and other instances load the checkpointed graph.	Best when the dataset still fits comfortably per instance and you want simple single-instance query execution with RAC availability.	High memory cost because the full graph is duplicated; scalability is still bounded by per-instance memory.
Distributed HNSW	The vector set is split across instances, each instance owns a slice graph, and queries run in parallel across participating nodes.	Best when HNSW size or build cost outgrows one instance and RAC is part of the scaling plan.	No parallel DML support, no snapshots, no covering columns, no online distributed build, and temporary index unavailability can occur during cluster reconfiguration.

Distributed HNSW is especially important because it changes the memory ceiling. Oracle documents that slice graphs let the usable vector pool scale across RAC instances rather than being limited by one server. That makes distributed HNSW the right mental model for very large HNSW estates, but not automatically the right default. It has extra restrictions and a more complex failure story.

Distributed HNSW has real restrictions

No snapshots, no covering columns, no parallel DML, no online build. During cluster changes Oracle can temporarily disable the index, fall back to full scans, redistribute slice graphs, or rebuild if there are not enough healthy instances to hold the full layout.

Scalar quantization is a capacity decision, not a marketing add-on

HNSW lives in memory, and memory is the first practical ceiling you hit as vector counts and dimensions grow. Scalar-quantized HNSW in 26ai reduces the memory footprint of indexed vectors, with an optional rescore factor for query-time refinement. It is a capacity lever, not a convenience feature.

When HNSW is the right primary index

• Your workload is fundamentally nearest-neighbor search over vector columns rather than document retrieval.
• You want Oracle's graph-based ANN path and can provision vector pool memory deliberately.
• You are prepared to think about graph refresh, checkpointing, and RAC mode explicitly.
• Your predicate strategy does not depend on distributed-HNSW covering columns.

Section 03

IVF and local IVF: centroid partitions, explicit rebuild logic, and better partition alignment

IVF clusters vector space around centroids and probes a subset of partitions during search instead of walking a graph. The real value in 26ai is operational: strong reorganization and partition-management controls that make IVF worth considering when data shape changes over time.

03

Mental model

Oracle documents IVF as a technique that narrows search by identifying centroid partitions. At index creation time, vectors are sampled and clustered into centroids. At query time, Oracle probes the nearest centroid partitions and then scans those partitions to identify candidates. This is approximate search because you do not inspect every partition unless the chosen settings effectively force a much broader search.

Key creation parameters

Oracle documents IVF through CREATE VECTOR INDEX ... ORGANIZATION NEIGHBOR PARTITIONS. The main IVF parameter surface includes target accuracy, distance metric, and IVF controls such as NEIGHBOR PARTITIONS, SAMPLES_PER_PARTITION, and MIN_VECTORS_PER_PARTITION.

SQL - Global IVF creation

CREATE VECTOR INDEX docs_ivf_idx
ON docs (embedding)
ORGANIZATION NEIGHBOR PARTITIONS
DISTANCE COSINE
WITH TARGET ACCURACY 90
PARAMETERS (type IVF, neighbor partitions 64);

SQL - Local IVF creation on a partitioned table

CREATE VECTOR INDEX docs_ivf_local_idx
ON docs (embedding)
ORGANIZATION NEIGHBOR PARTITIONS
DISTANCE COSINE
WITH TARGET ACCURACY 90
PARAMETERS (type IVF, neighbor partitions 16)
LOCAL;

Online creation is not supported for IVF

Do not assume parity with HNSW here. IVF's operational strength is the rebuild and reorganization path, not the creation path.

Why local IVF matters more than it first appears

Oracle documents that global IVF indexes are partitioned by centroid, not by your table's business partition key. That means a query filtered on a relational partition key may still need to examine centroid partitions that have no natural relationship to that key. Local IVF changes the trade-off. A local index creates a one-to-one relationship between base table partitions or subpartitions and index partitions, which can make filtered and partition-pruned workloads easier to reason about operationally.

If your data model is strongly partitioned by time, tenant, or geography and your vector searches nearly always stay within those slices, local IVF deserves early consideration rather than being treated as an exotic feature.

Reorganization is part of the IVF life cycle

IVF is the family where Oracle is most explicit about quality drift over time. If inserts, updates, and deletes materially change the data distribution, centroid assignment can become skewed and partitions can grow unevenly. Oracle documents both manual and automatic IVF reorganization to address this. In current 26ai documentation, automatic IVF reorganization is enabled by default for global IVF indexes.

Operational issue	Why it happens	What Oracle documents	Practical response
Recall drift	New data no longer matches the centroid layout created at index build time.	IVF reorganization rebuilds the centroid structure and catch-up logic applies journaled changes during rebuild.	Expect periodic rebuilds for evolving data rather than treating IVF as set-and-forget.
Skewed partitions	Some centroids accumulate disproportionate data volume.	Oracle explicitly describes degraded quality and efficiency when partitions become imbalanced.	Review data-shape changes after large ingestion phases or major reclassification events.
Heavy partition maintenance	Base tables change through split, exchange, merge, or move operations.	Oracle documents supported PMOPs for global IVF and HNSW indexes, but rebuild may still be required outside the documented support path.	Test PMOP scripts with vector indexes before adopting them as standard runbook steps.
Table truncation	TRUNCATE invalidates the current centroid-partition state.	Oracle documents that truncating a table marks its IVF index unusable.	Plan to rebuild or recreate before resuming indexed search.

Online rebuild is one of IVF's strongest operational features

Oracle documents online rebuild for IVF, including whole-index rebuild and, for local IVF, per-partition rebuild. That is a major practical advantage because it gives you a concrete maintenance path when the data distribution has moved far enough that the original centroid structure no longer represents the table well.

SQL - Global IVF online rebuild

ALTER INDEX docs_ivf_idx REBUILD ONLINE PARALLEL 4;

SQL - Local IVF partition rebuild

ALTER INDEX docs_ivf_local_idx
REBUILD PARTITION p2026q1 ONLINE;

Included columns can change filter economics dramatically

Oracle documents included columns for vector indexes as a way to keep additional filterable attributes inside the index path rather than bouncing back to the base table. In the IVF family, this is especially important because filter-heavy similarity queries can otherwise devolve into expensive base-table joins. Oracle also documents that included columns do not work with partition-local IVF indexes, so there is an explicit design trade-off between locality and covering/filtering behavior.

You usually do not get both

Local IVF is a strong match for partition-pruned workloads. Global IVF with included columns is better when you need aggressive attribute filtering from the vector path. Pick based on what your actual queries do.

When IVF is the right primary index

• Your vector distribution changes enough over time that explicit rebuild and reorganization controls matter.
• Your data model or lifecycle naturally aligns with partition-based maintenance.
• You want local-vs-global design options rather than a single graph residency story.
• Your workload benefits from included columns and you can stay within the supported combinations.

Section 04

Hybrid vector indexing: a document retrieval system, not merely another ANN structure

The hybrid vector index is not another ANN index type. It is built on Oracle Text machinery combined with vectorized chunk indexing and a unified query API. If you treat it as a drop-in for HNSW or IVF you will get the design wrong.

04

What it is

Oracle documents the hybrid vector index as a single index structure that stores both text fields and vector fields for a document. It supports textual queries, vector similarity queries, and hybrid fused queries through the DBMS_HYBRID_VECTOR.SEARCH API. Oracle also documents search modes at both document and chunk level, which is why hybrid indexing is the natural fit for RAG-style retrieval and document search systems inside the database.

Different question, different tool

HNSW and IVF answer: how do I accelerate similarity search on a vector column? Hybrid indexing answers: how do I build a document retrieval pipeline where keyword signals and semantic signals belong in the same query?

What hybrid indexing bundles

• Text indexing behavior from Oracle Text.
• Chunking and vectorization pipeline logic for searchable content.
• A unified API for keyword-only, semantic-only, and fused search modes.
• Maintenance controls such as automatic or manual synchronization.

What it is not

• Not a drop-in replacement for a plain vector index on every embedding table.
• Not automatically the right answer for structured, row-level ANN workloads.
• Not just “HNSW plus text,” because its retrieval unit and maintenance surface are different.

Creation surface and maintenance model

Oracle documents CREATE HYBRID VECTOR INDEX as part of the Oracle Text product. Current documentation also describes automatic and manual maintenance settings, along with synchronization options like manual, periodic, or on-commit synchronization. That matters because hybrid indexing is not only about ranking. It is also about how documents become searchable and stay searchable as DML arrives.

SQL - Minimal hybrid vector index example

CREATE HYBRID VECTOR INDEX my_hybrid_idx
ON docs(file_name)
PARAMETERS ('MODEL MY_INDB_MODEL');

SQL - Basic hybrid search call

SELECT DBMS_HYBRID_VECTOR.SEARCH(
         json('{ "hybrid_index_name" : "my_hybrid_idx",
                 "search_text"       : "leadership experience" }'))
FROM dual;

Additional predicates matter more than they first appear

Oracle 26ai adds additional predicate support with hybrid search through the FILTER_BY field in the search API. That is strategically important because hybrid retrieval pipelines often need relational filters such as tenant, region, document class, language, lifecycle state, or retention boundary. Without a filter mechanism, hybrid search becomes much harder to integrate into serious multi-tenant or governed systems.

JSON support changes where hybrid indexing can live

Oracle 26ai adds hybrid vector index support for native JSON columns. Many document-centric applications already store content in JSON columns, so this removes the need for a separate indexing path.

Know which problem you are solving

Semantic chunks with keyword evidence and governance filters → hybrid is the right choice. Nearest vectors for structured records with a few scalar columns → HNSW or IVF is simpler and usually better.

When hybrid is the right primary index

• The retrieval unit is a document or chunk rather than a single structured row.
• You want keyword and semantic search fused inside one database-native API.
• You care about chunk mode versus document mode as a product behavior.
• Your content already lives in text or JSON forms that map naturally to Oracle Text plus vectorized retrieval.

Section 05

Filtering, query shape, and optimizer behavior: the part that usually decides the winner

Most teams compare HNSW and IVF purely on ANN quality. In production, predicate shape and retrieval shape tend to matter more. The fine print around included columns, distance metrics, APPROX usage, and hybrid filter support is where the real design differences show up.

05

Approximate vector search has documented optimizer requirements

Oracle documents several rules that have direct operational impact:

• The query must use APPROX or APPROXIMATE for the optimizer to consider a vector index path.
• The distance metric used in the query must match the one used by the index.
• The VECTOR_DISTANCE expression cannot be wrapped in another SQL function if you want the index considered.
• You can only create one vector index type per vector column.

SQL - Approximate nearest-neighbor shape

SELECT id,
       category_id,
       VECTOR_DISTANCE(embedding, :query_vector, COSINE) AS dist
FROM docs
WHERE category_id = :category_id
ORDER BY VECTOR_DISTANCE(embedding, :query_vector, COSINE)
FETCH APPROX FIRST 10 ROWS ONLY;

How filtering changes the index choice

Query pattern	Why it matters	Usually favors	Reasoning
Plain ANN on a vector table	Minimal relational filtering, vector rank is the main task.	HNSW	Graph traversal is the cleanest fit when vector similarity dominates.
ANN with partition-pruned workload	The relational partition key narrows the working set before or during search.	Local IVF	Oracle's one-to-one local index partitioning can align better with the base table partition strategy.
ANN with attribute-heavy filtering	Extra predicates can force costly base table access.	Global IVF with included columns, or supported HNSW included-column paths on current RU	Covering behavior matters more than raw ANN mechanics when filters are selective.
Keyword plus semantic document search	Text relevance and vector relevance must both contribute to ranking.	Hybrid vector index	Hybrid is purpose-built for fused document or chunk retrieval.
Filter-constrained chunk retrieval	Tenant or lifecycle constraints must apply inside the retrieval API.	Hybrid vector index	FILTER_BY support in DBMS_HYBRID_VECTOR.SEARCH is the right abstraction.

The hidden cost of choosing only by raw ANN preference

A common mistake is picking HNSW because "graph ANN must be better," then finding out later that production queries are dominated by partition filters, document search, or lifecycle constraints. By that point the wrong design is already embedded in the application.

The right question is not "Which index is fastest?" It is "Which index keeps the optimizer, the filters, and the maintenance model aligned with how the application actually queries?"

Section 06

Operations runbook: creation, rebuild, partition work, and diagnostics

The operational surface of Oracle 26ai vector indexing is where the real differences between index families show up: metadata visibility, rebuild primitives, PMOP behavior, checkpointing, and hybrid maintenance settings.

06

Start with the simple metadata you always have

Oracle documents USER_INDEXES, ALL_INDEXES, and DBA_INDEXES as the baseline catalog path, including INDEX_TYPE and INDEX_SUBTYPE. That gives you a stable first step for verifying what exists and which vector index family Oracle believes it is.

SQL - Verify vector indexes in the catalog

SELECT index_name,
       index_type,
       index_subtype,
       status
FROM   user_indexes
WHERE  table_name = 'DOCS'
ORDER  BY index_name;

Operational checklist by family

HNSW checklist

• Confirm vector pool sizing before production build.
• Choose RAC mode deliberately: duplicated or distributed.
• Review whether online build, included columns, or distributed restrictions matter.
• Plan how graph refresh and checkpoint behavior will be observed.

IVF checklist

• Decide global versus local before you automate maintenance.
• Treat reorganization as a normal part of life, not an exception.
• Test partition operations with the exact DDL your platform team uses.
• Use included columns only where the supported combinations match your filter strategy.

Hybrid checklist

• Validate chunking and retrieval mode against real application prompts.
• Pick a maintenance mode that matches DML and freshness needs.
• Verify relational filters through the search API, not only in prose.
• Test JSON-specific configuration if content is stored in JSON columns.

Troubleshooting flow

Symptom	Likely cause	What to inspect	Next action
ANN query stops using the indexApproximate search plan disappears	Missing APPROX, distance mismatch, unsupported expression shape, or index state issue.	Query text, distance metric, and catalog status in USER_INDEXES.	Fix the SQL shape first before tuning parameters.
IVF quality degrades after data churnResults feel less representative	Centroid distribution no longer matches the current data set.	Recent ingestion pattern, update mix, and time since last rebuild.	Rebuild online; for local IVF, consider rebuilding only the affected partition.
HNSW memory pressure appears in RACBuild or growth exceeds one node comfortably	Duplicated mode no longer fits the per-instance envelope.	Current RAC topology and whether distributed HNSW restrictions are acceptable.	Evaluate distributed HNSW rather than forcing more duplication.
Hybrid search misses governance boundariesWrong tenant or lifecycle content leaks into results	Relational constraints are not being applied through the hybrid search contract.	Search API payload, maintenance lag, and filter logic.	Move the constraints into documented hybrid filtering rather than post-processing.
Partition maintenance leaves vector index unusableStatus changes after table DDL	The PMOP path fell outside what Oracle documents as maintained automatically for that index type.	Exact ALTER TABLE statement and post-DDL index status.	Add a rebuild step to the runbook or adjust the PMOP sequence.

Partition maintenance: treat it as a compatibility matrix, not an assumption

Oracle documents a supported PMOP set for global IVF and HNSW indexes on partitioned tables, typically using UPDATE GLOBAL INDEXES or UPDATE INDEXES. That is helpful, but it does not justify blind confidence. The safe habit is to test the exact PMOPs your platform uses and check post-operation index state every time you standardize a new maintenance path.

Direct-load and bulk-ingestion reasoning

Neither HNSW nor IVF should be treated as magically immune to ingest pattern. Bulk load, repartitioning, or major vector re-embedding events are exactly the moments when you should re-evaluate whether the current index shape still matches the data. HNSW may need repopulation. IVF may need reorganization. Hybrid may need synchronization or maintenance policy review if freshness expectations changed.

📘

eBook

Exadata DBA Guide

A comprehensive PDF guide for Oracle DBAs covering Exadata architecture, Smart Scan, Flash Cache, Storage HA and performance tuning.

Get the PDF →

Section 07

Decision matrix: a defensible framework for choosing HNSW, IVF, hybrid, or a mixed strategy

Start with four questions: what is the retrieval unit, what filters dominate, how much data churn do you expect, and is RAC part of the scaling story. Answer those and the choice narrows fast.

07

Criterion	HNSW	IVF / Local IVF	Hybrid vector index
Primary objectWhat you are indexing	Vector columns used for ANN over structured rows.	Vector columns used for ANN where centroid partitioning is acceptable or desirable.	Documents, chunks, text-bearing content, or JSON content with fused keyword and semantic search.
Best fitMain reason to choose it	Memory-first graph ANN and strong search performance orientation.	Operationally explicit rebuild path and strong partition-aware options.	Single retrieval contract for text plus vector search.
FilteringPredicate-heavy workloads	Works, but restrictions differ across modes; distributed HNSW does not support covering columns.	Often strong when included columns are applicable; local IVF helps partition-pruned designs.	Best when filters are part of document retrieval through FILTER_BY.
DML behaviorFreshness story	Transactional consistency via journals plus snapshots or full repopulation.	Ongoing DML can skew centroids; reorganization is a normal maintenance tool.	Controlled by hybrid maintenance and synchronization model.
RACCluster scaling	Strongest RAC story, but duplicated and distributed modes have materially different restrictions.	Global and local designs interact with partitioning and PMOP more than with graph distribution.	RAC is not the primary design differentiator here; retrieval contract is.
MaintenanceWhat operators live with	Memory sizing, checkpoints, repopulation, RAC mode decisions.	Rebuild cadence, skew management, partition maintenance behavior.	Sync and optimize policy, chunking semantics, filter-aware retrieval validation.

Mixed is usually the right answer

Use HNSW or IVF for structured ANN over operational rows. Use hybrid for document retrieval or RAG-style evidence lookup. Oracle 26ai supports that division of labor without any special wiring.

Section 08

Pilot plan: validate the choice before you standardize it

A real pilot tests retrieval shape, filter behavior, DML drift, and maintenance actions — not just one query against one index. The steps below are for a proof-of-production, not a slide deck.

08

Step 1

Fix the retrieval unit

Decide whether the thing being ranked is a row vector, a chunk, or a whole document. Until that is explicit, you cannot choose between HNSW, IVF, and hybrid honestly.

Step 2

Shadow real filters

Use the exact tenant, lifecycle, geography, or time predicates the application will run. Filter behavior often changes the winning design.

Step 3

Inject churn

Run insert, update, and delete patterns that resemble your production rate. HNSW and IVF react differently to sustained change.

Step 4

Rebuild on purpose

Trigger the documented rebuild or reorganization path during the pilot. If you do not test the maintenance motion, you have not really tested the index.

Step 5

Compare against exact shadow samples

For a small but representative query set, compare approximate results with exact search results to judge whether the chosen accuracy settings are acceptable for the business.

Step 6

Record the rollback path

Document what happens if the index becomes unusable after a PMOP, if hybrid sync lags, or if HNSW memory pressure exceeds the target node envelope.

Minimal starter DDL for a pilot table

SQL - Pilot table skeleton

CREATE TABLE docs (
  id           NUMBER PRIMARY KEY,
  file_name    VARCHAR2(400),
  tenant_id    NUMBER NOT NULL,
  category_id  NUMBER,
  created_at   DATE,
  title        VARCHAR2(400),
  body         CLOB,
  payload      JSON,
  embedding    VECTOR(768, FLOAT32)
);

Success criterion

The right index is not the one that wins a synthetic benchmark. It is the one that stays accurate enough under real filters and DML, and uses the documented maintenance path without special handling.

Section 09

FAQ and closing takeaways

Questions that tend to come up once teams start building. Worth answering before the design is locked in.

09

Should HNSW always be the default if we care about speed?

No. HNSW is a strong default candidate for row-oriented ANN, but partition alignment, filter coverage, rebuild cadence, document retrieval needs, and RAC restrictions can make IVF or hybrid the better primary design.

Is hybrid vector indexing only for RAG?

No. RAG is an obvious use case, but the broader point is document or chunk retrieval where semantic and lexical signals should be fused. That includes search portals, policy retrieval, knowledge systems, and governed content discovery.

When should we favor local IVF?

When the table is partitioned for a business reason that also constrains search scope, such as time, tenant, or geography, and your query workload typically stays inside those boundaries.

Can we standardize on one vector index family for every workload?

Usually not. Oracle 26ai's feature set is broad enough that structured ANN and document retrieval often deserve different index strategies. A mixed design is common and often correct.

What is the biggest operational mistake?

Treating index choice as a one-time DDL decision instead of a lifecycle decision. HNSW needs memory and refresh thinking. IVF needs rebuild and partition thinking. Hybrid needs sync and retrieval-contract thinking.

Bottom line

• Pick HNSW when vector ANN over structured rows is the primary workload and you can provision graph memory deliberately.
• Pick IVF when partition-aware maintenance, rebuild control, or included-column filtering matters enough to outweigh graph-first appeal.
• Pick hybrid when the retrieval unit is document or chunk content and keyword plus semantic ranking belongs in one API.
• Revisit the choice after modeling filters and DML because those two factors routinely overturn first impressions.

One rule to remember: choose the index family that matches the retrieval and maintenance reality you actually have, not the one that sounds best in isolation.

Knowledge check

Quick quiz

?

Five questions on Oracle vector index types. Pick one answer then hit Submit.

Q1. What is the key operational difference between duplicated and distributed HNSW in a RAC environment?

They are the same — Oracle chooses automatically based on cluster size Duplicated holds a full copy per instance; distributed splits the vector set across instances and has extra restrictions including no snapshots or online build Distributed is always faster and should be the default for RAC Duplicated HNSW supports online build; distributed does not support any build operation

Correct: B. Duplicated puts a full graph copy on each instance — simple but memory-expensive. Distributed splits vectors across instances to remove the per-instance memory ceiling, but loses snapshots, covering columns, parallel DML, and online build support. They are not interchangeable defaults.

Q2. Why does IVF quality drift over time and what is the documented fix?

The graph edges become stale — Oracle refreshes them through snapshots Memory pressure causes partial eviction — a cold restart fixes it DML changes the data distribution so centroid assignments become skewed — IVF reorganization rebuilds the centroid structure Token expiry in the vector pool — running DBMS_VECTOR.FLUSH clears it

Correct: C. IVF builds centroid partitions at index creation. When inserts, updates, and deletes shift the data distribution, those centroids no longer represent the current data well and partitions can grow unevenly. Oracle documents IVF reorganization — manual or automatic — to rebuild the centroid structure and restore quality.

Q3. What does the hybrid vector index answer that HNSW and IVF do not?

How to make ANN faster on very large tables How to index BINARY vectors efficiently How to run vector queries in parallel across RAC nodes How to build a document retrieval pipeline where keyword and semantic signals belong in the same query

Correct: D. HNSW and IVF answer "how do I accelerate similarity search on a vector column?" Hybrid answers a different question: how do I retrieve documents or chunks where text signals and semantic signals both contribute to ranking through a single API?

Q4. What SQL change is required for the Oracle optimizer to consider a vector index path?

The query must use APPROX or APPROXIMATE in the FETCH clause An index hint must be added with the exact index name The VECTOR_DISTANCE expression must be aliased The query must use a PARALLEL hint

Correct: A. Oracle documents that the query must use APPROX or APPROXIMATE for the optimizer to consider a vector index path. The distance metric must also match the one used when the index was created, and VECTOR_DISTANCE cannot be wrapped in another function.

Q5. When does local IVF give a meaningful advantage over global IVF?

When the table has more than 10 million rows When the table is partitioned by a business key such as time, tenant, or geography and queries typically stay within those boundaries When included columns are needed for filter coverage When IVF online creation is required

Correct: B. Local IVF creates a one-to-one relationship between base table partitions and index partitions. When the table is partitioned for a natural business reason — time, tenant, geography — and queries usually stay within those slices, local IVF can align better with the base table structure and make per-partition rebuild more targeted. Note that local IVF does not support included columns, so there is a design trade-off.