DEV Community

Yurii Dobrytsia
Yurii Dobrytsia

Posted on • Originally published at Medium

Oracle AI Database 26ai: Relational Integrity, Vector Search, and AI-Ready Financial Workflows

#ai #oracle #sql #database

Why this article

This article was originally published on Medium. I am cross-posting it here for the developer and data engineering community, with the canonical link pointing to the original version.

The Core Question

The most interesting part of Oracle AI Database 26ai is not that it can run ordinary relational workloads. That part is expected. The more important question is how an established enterprise database changes when AI workloads become part of the same data layer.

In many AI projects, teams separate operational data, vector search, document storage, model calls, and analytics into different systems. That can work, but it introduces integration cost: duplicated data, inconsistent access control, extra synchronization, and more places where governance can fail.

Oracle's 26ai direction is different. The database is positioned as a place where structured business data and AI-oriented retrieval can live together. Relational records, JSON, graph, spatial data, text, and vector embeddings can be queried under the same database engine and security model.

This article uses a compact financial example to show why that matters. The starting point is a secured loan backed by bond collateral. The first version uses ordinary relational SQL to calculate exposure and detect undercollateralization. The stronger version adds Oracle 26ai-specific AI concepts: VECTOR columns, vector distance search, vector indexes, hybrid retrieval, and Select AI.

What Makes 26ai Relevant For AI Workloads

Oracle AI Database 26ai is the long-term-support release that replaced the 23ai naming line after the October 2025 release update. Oracle states that the release includes hundreds of new features with a focus on AI and developer productivity. The features that matter most for this article are:

  • AI Vector Search: Store and search vector embeddings inside Oracle Database.
  • VECTOR data type: Store embeddings next to business records instead of only in a separate vector database.
  • Vector distance functions: Use SQL functions such as VECTOR_DISTANCE with metrics such as cosine or Euclidean distance.
  • Vector indexes: Use approximate-nearest-neighbor indexes such as HNSW and IVF to speed up similarity search.
  • Hybrid search: Combine semantic vector search with keyword search through Oracle Text and vector indexing structures.
  • Select AI: Use natural-language prompts through SQL when an AI profile and provider are configured.

This is the Oracle-specific depth that a generic relational database introduction misses. Tables, joins, keys, and ACID behavior still matter, but in 26ai they can now be combined with semantic retrieval patterns used in RAG and agentic AI applications.

Baseline Business Model: A Secured Loan

The scenario is intentionally small. A customer receives a loan. A government bond is deposited as collateral. The loan accrues simple interest. If the collateral value falls below the current exposure, the loan status is changed to TERMINATED.

The relational model has two core entities:

  • BOND_COLLATERAL: stores collateral instruments and their current value.
  • SECURED_LOAN: stores loan contracts and references collateral through a foreign key. 
CREATE TABLE BOND_COLLATERAL (
  BOND_ID      NUMBER        NOT NULL,
  BOND_NAME    VARCHAR2(50)  NOT NULL,
  VALUE_EUR    NUMBER        NOT NULL,
  CONSTRAINT PK_BOND_COLLATERAL PRIMARY KEY (BOND_ID)
);

CREATE TABLE SECURED_LOAN (
  LOAN_ID        NUMBER        NOT NULL,
  BORROWER       VARCHAR2(50)  NOT NULL,
  BOND_ID        NUMBER        NOT NULL,
  PRINCIPAL_EUR  NUMBER        NOT NULL,
  RATE_PCT       NUMBER        NOT NULL,
  START_DATE     DATE          NOT NULL,
  STATUS         VARCHAR2(12)  NOT NULL,
  CONSTRAINT PK_SECURED_LOAN PRIMARY KEY (LOAN_ID),
  CONSTRAINT FK_SECURED_LOAN_BOND FOREIGN KEY (BOND_ID)
    REFERENCES BOND_COLLATERAL (BOND_ID)
);
Enter fullscreen mode Exit fullscreen mode

The foreign key is not decoration. It ensures that a loan cannot reference missing collateral. In a financial system, this kind of referential integrity is the basic layer below analytics, reporting, and AI.

INSERT INTO BOND_COLLATERAL
VALUES (1, 'GOV BOND', 100000);

INSERT INTO SECURED_LOAN
VALUES (1, 'CUSTOMER A', 1, 70000, 6.0, DATE '2026-01-01', 'ACTIVE');

COMMIT;
Enter fullscreen mode Exit fullscreen mode

Now the exposure can be calculated as principal plus accrued interest:

SELECT
  L.LOAN_ID,
  L.BORROWER,
  B.BOND_NAME,
  L.PRINCIPAL_EUR,
  B.VALUE_EUR AS COLLATERAL_VALUE,
  ROUND(
    L.PRINCIPAL_EUR
    * (L.RATE_PCT / 100)
    * ((DATE '2026-01-10' - L.START_DATE) / 365),
    2
  ) AS INTEREST_EUR,
  ROUND(
    L.PRINCIPAL_EUR
    + (
      L.PRINCIPAL_EUR
      * (L.RATE_PCT / 100)
      * ((DATE '2026-01-10' - L.START_DATE) / 365)
    ),
    2
  ) AS EXPOSURE_EUR
FROM SECURED_LOAN L
JOIN BOND_COLLATERAL B ON B.BOND_ID = L.BOND_ID;
Enter fullscreen mode Exit fullscreen mode

If the bond value drops to EUR 65,000, the exposure is now larger than the collateral value. The update below implements the termination rule:

UPDATE BOND_COLLATERAL
SET VALUE_EUR = 65000
WHERE BOND_ID = 1;

COMMIT;

UPDATE SECURED_LOAN L
SET STATUS = 'TERMINATED'
WHERE (
  L.PRINCIPAL_EUR
  + (
    L.PRINCIPAL_EUR
    * (L.RATE_PCT / 100)
    * ((DATE '2026-01-10' - L.START_DATE) / 365)
  )
) > (
  SELECT B.VALUE_EUR
  FROM BOND_COLLATERAL B
  WHERE B.BOND_ID = L.BOND_ID
);

COMMIT;
Enter fullscreen mode Exit fullscreen mode

This is still ordinary SQL. It is useful, but it does not yet use the AI-specific capabilities of 26ai.

Extending The Example With Vector Search

Real credit monitoring does not only depend on numeric fields. It also depends on policies, internal risk rules, collateral documentation, market commentary, covenant clauses, and exception notes. Those are often text-heavy and harder to search with only exact keywords.

This is where Oracle AI Vector Search becomes relevant. Oracle 26ai supports a VECTOR data type for embeddings. A text fragment can be transformed into an embedding by an embedding model, then stored in Oracle next to its business metadata.

For example, a credit-policy table could look like this:

CREATE TABLE LOAN_POLICY_CHUNK (
  CHUNK_ID         NUMBER         NOT NULL,
  POLICY_NAME      VARCHAR2(120)  NOT NULL,
  CHUNK_TEXT       CLOB           NOT NULL,
  CHUNK_EMBEDDING  VECTOR(384, FLOAT32),
  CONSTRAINT PK_LOAN_POLICY_CHUNK PRIMARY KEY (CHUNK_ID)
);
Enter fullscreen mode Exit fullscreen mode

The 384 dimension is only an example. In a real system, the dimension must match the embedding model used to generate the vectors. Oracle supports vector formats such as FLOAT32, FLOAT64, INT8, and BINARY.

Small sample fragments could describe business rules:

INSERT INTO LOAN_POLICY_CHUNK
  (CHUNK_ID, POLICY_NAME, CHUNK_TEXT, CHUNK_EMBEDDING)
VALUES
  (
    1,
    'Collateral monitoring',
    'If the exposure exceeds eligible collateral value, the loan must be reviewed and may be terminated.',
    TO_VECTOR('[0.12, 0.44, 0.31]', 3, FLOAT32)
  );
Enter fullscreen mode Exit fullscreen mode

The example above uses only three dimensions to keep the SQL readable. Production embeddings usually have hundreds or thousands of dimensions.

Once the table contains many embedded fragments, a semantic search can retrieve policy text by meaning:

SELECT
  POLICY_NAME,
  CHUNK_TEXT,
  VECTOR_DISTANCE(
    CHUNK_EMBEDDING,
    TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
    COSINE
  ) AS SEMANTIC_DISTANCE
FROM LOAN_POLICY_CHUNK
ORDER BY VECTOR_DISTANCE(
  CHUNK_EMBEDDING,
  TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
  COSINE
)
FETCH FIRST 3 ROWS ONLY;
Enter fullscreen mode Exit fullscreen mode

The important point is not the sample vector values. The important point is architectural: policy text can be retrieved semantically while remaining inside the same database environment as the loan and collateral records.

Adding A Vector Index

Exact vector search compares the query vector against many stored vectors. That is acceptable for tiny examples, but not for large document collections. Oracle supports vector indexes to make approximate-nearest-neighbor search faster.

For example, an HNSW index can be created like this:

CREATE VECTOR INDEX LOAN_POLICY_HNSW_IDX
ON LOAN_POLICY_CHUNK (CHUNK_EMBEDDING)
ORGANIZATION INMEMORY NEIGHBOR GRAPH
DISTANCE COSINE
WITH TARGET ACCURACY 95;
Enter fullscreen mode Exit fullscreen mode

Oracle also supports IVF indexes:

CREATE VECTOR INDEX LOAN_POLICY_IVF_IDX
ON LOAN_POLICY_CHUNK (CHUNK_EMBEDDING)
ORGANIZATION NEIGHBOR PARTITIONS
DISTANCE COSINE
WITH TARGET ACCURACY 95;
Enter fullscreen mode Exit fullscreen mode

This is a concrete Oracle-specific feature. A normal relational database chapter does not explain HNSW or IVF vector indexing. These indexes matter for AI workloads because RAG systems and agent memory stores often search thousands or millions of embedded chunks.

After indexing, a query can request approximate results:

SELECT
  POLICY_NAME,
  CHUNK_TEXT
FROM LOAN_POLICY_CHUNK
ORDER BY VECTOR_DISTANCE(
  CHUNK_EMBEDDING,
  TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
  COSINE
)
FETCH APPROX FIRST 3 ROWS ONLY;
Enter fullscreen mode Exit fullscreen mode

This gives up exact exhaustive comparison in exchange for speed, controlled by the index and target accuracy.

Combining Structured Rules And Semantic Retrieval

The stronger AI-data pattern is to combine relational filtering with semantic retrieval. For example, first identify loans that are undercollateralized, then retrieve the most relevant policy fragments for explaining what should happen.

WITH EXPOSURE AS (
  SELECT
    L.LOAN_ID,
    L.BORROWER,
    L.STATUS,
    L.PRINCIPAL_EUR,
    B.VALUE_EUR AS COLLATERAL_VALUE,
    ROUND(
      L.PRINCIPAL_EUR
      + (
        L.PRINCIPAL_EUR
        * (L.RATE_PCT / 100)
        * ((DATE '2026-01-10' - L.START_DATE) / 365)
      ),
      2
    ) AS EXPOSURE_EUR
  FROM SECURED_LOAN L
  JOIN BOND_COLLATERAL B ON B.BOND_ID = L.BOND_ID
),
POLICY_HITS AS (
  SELECT
    P.POLICY_NAME,
    P.CHUNK_TEXT,
    VECTOR_DISTANCE(
      P.CHUNK_EMBEDDING,
      TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
      COSINE
    ) AS SEMANTIC_DISTANCE
  FROM LOAN_POLICY_CHUNK P
  ORDER BY VECTOR_DISTANCE(
    P.CHUNK_EMBEDDING,
    TO_VECTOR(:QUERY_EMBEDDING, 384, FLOAT32),
    COSINE
  )
  FETCH APPROX FIRST 3 ROWS ONLY
)
SELECT
  E.LOAN_ID,
  E.BORROWER,
  E.EXPOSURE_EUR,
  E.COLLATERAL_VALUE,
  P.POLICY_NAME,
  P.CHUNK_TEXT
FROM EXPOSURE E
CROSS JOIN POLICY_HITS P
WHERE E.EXPOSURE_EUR > E.COLLATERAL_VALUE;
Enter fullscreen mode Exit fullscreen mode

This is closer to the kind of data pattern AI systems need:

  • Numeric exposure is calculated using deterministic SQL.
  • Collateral status comes from governed relational data.
  • Policy explanation comes from semantic retrieval.
  • The application does not need to copy business data into a separate vector-only store.

For a risk analyst, this could support a dashboard explanation. For an AI assistant, it could become part of a retrieval-augmented answer: "This loan is undercollateralized because exposure is EUR 70,103.56 while collateral is EUR 65,000. The relevant policy says loans exceeding eligible collateral must be reviewed and may be terminated."

The model should not be allowed to invent the numeric conclusion. SQL should calculate it. The model can help explain it.

Hybrid Search: Why Keywords Still Matter

Vector search is useful because it searches by semantic similarity. But financial and legal documents often contain exact terms that must not be blurred away, such as an ISIN, contract ID, counterparty name, legal phrase, or rating category.

This is why hybrid retrieval matters. Oracle's 26ai documentation describes hybrid vector indexes as combining Oracle Text structures with vector indexing structures. In practice, that means an application can combine:

  • Keyword matching for exact terms.
  • Vector similarity for meaning and context.
  • Relational filters for structured constraints such as customer, region, status, date, or exposure amount.

That combination is more robust than pure vector search for enterprise AI. A semantic search may find the right concept, but a keyword or relational predicate may be needed to anchor the result to the exact business object.

Select AI: Natural Language As A Database Interface

Oracle 26ai also includes Select AI, which allows natural-language interaction through SQL when the system is configured with an AI profile and provider.

For example, a user can ask for generated SQL:

SELECT AI showsql list all active loans where exposure is greater than collateral value;
Enter fullscreen mode Exit fullscreen mode

Or run a natural-language request:

SELECT AI list all terminated loans with their collateral values;
Enter fullscreen mode Exit fullscreen mode

The useful part is not that this replaces SQL knowledge. It does not. Oracle's own documentation warns that LLM outputs may be wrong and should be checked. The useful part is that a database can expose a natural-language layer while still grounding the final answer in database metadata and SQL execution.

For professional use, I would treat Select AI as a productivity interface, not as an authority. A good workflow is:

  1. Use SELECT AI showsql to inspect the generated query.
  2. Validate joins, filters, and aggregation logic.
  3. Run the SQL only when the generated logic is correct.
  4. Add comments, views, and clear column names to improve natural-language interpretation.

This point matters because many AI failures in analytics are not syntax failures. They are data-model failures: joining at the wrong level, filtering the wrong status, double-counting facts, or misunderstanding a business definition.

Strengths And Weaknesses Of Oracle 26ai For This Use Case

The strongest argument for Oracle 26ai is integration. A financial AI workflow can keep transactional records, policy fragments, vector embeddings, SQL logic, and retrieval logic closer together. That reduces the need to stitch together a separate relational database, vector database, text search engine, and governance layer.

The second strength is governance. In finance, healthcare, logistics, and government, AI systems must be built around access control, auditability, consistency, and operational reliability. Oracle's enterprise database background is relevant here because the AI features are being added to an engine already designed for controlled data.

The third strength is query composition. Oracle can combine relational predicates and vector similarity in SQL. That is valuable because most enterprise AI questions are not purely semantic. They are mixed questions: "Find the relevant policy for active loans in Germany where collateral coverage dropped below threshold after a market value update."

There are trade-offs. Oracle is complex. AI Vector Search introduces additional concepts such as embedding models, vector dimensions, distance metrics, vector memory sizing, HNSW versus IVF indexes, target accuracy, and hybrid indexing. Select AI requires provider configuration and careful validation. For small prototypes, this can feel heavier than using a lightweight database plus a managed vector service.

Cost and operational skill also matter. Oracle AI Database Free is useful for learning, but production deployments need licensing, infrastructure planning, backup, monitoring, patching, security configuration, and database administration.

What This Example Shows

The original relational workflow shows how Oracle handles structured business data: tables, keys, joins, calculations, updates, and transactions. The 26ai extension shows how the same environment can support AI-oriented retrieval:

  • Store policy text and embeddings in a VECTOR column.
  • Use VECTOR_DISTANCE to find semantically relevant fragments.
  • Use HNSW or IVF vector indexes for approximate search.
  • Combine vector retrieval with structured SQL filters.
  • Use Select AI as a natural-language interface, while validating generated SQL.

That is the deeper lesson: AI-ready databases are not only about storing vectors. They are about combining deterministic business logic with probabilistic retrieval in a governed data system.

Conclusion

Oracle AI Database 26ai is most interesting when it is evaluated as an enterprise AI data layer, not only as a traditional RDBMS. The ordinary relational features still matter because they provide correctness, structure, and transactional behavior. The newer AI features matter because they bring semantic search, vector indexing, and natural-language access closer to the operational data.

For the secured-loan example, SQL should calculate exposure and enforce status changes. Vector search can retrieve the relevant policy fragments and explanatory context. Select AI can help users ask questions, but the generated SQL still needs review.

This balance is the practical future of many AI systems: deterministic databases for facts and rules, vector search for meaning, and language models for interaction and explanation.

References

Top comments (0)