Oracle AI Database
from the ground up

What are JSON Duality Views?

Relational databases store data in tables — rows and columns with strict schemas. Document databases store data as flexible JSON documents. Developers have been forced to choose one or the other, or glue them together with complex ORM layers.

JSON Duality Views solve this. They give you both representations simultaneously from the same underlying data. Think of it like looking at a sculpture from two angles — same object, different views.

Below is a live example. On the left, data lives in a relational table. On the right, the same data is exposed as a JSON document. Click any name in either view to edit it, and watch the other side update instantly. You can even have multiple duality views on the same table — try Both Views to see an employee-centric and a department-centric JSON shape update simultaneously from one table change.

[
  {
    "id": 1,
    "name": "Alice",
    "role": "Engineer",
    "department": {
      "id": 1,
      "name": "Platform",
      "floor": 3
    }
  },
  {
    "id": 2,
    "name": "Bob",
    "role": "Designer",
    "department": {
      "id": 2,
      "name": "Product",
      "floor": 5
    }
  },
  {
    "id": 3,
    "name": "Carol",
    "role": "Manager",
    "department": {
      "id": 3,
      "name": "Operations",
      "floor": 2
    }
  }
]

How cascading updates propagate

The real magic happens when data has relationships. In a duality view, updating a foreign key in the relational side automatically restructures the JSON document.

Play with the slider below. It controls the department_id of employee "Alice". Watch how the JSON document restructures itself — the department nested object changes, and the relational row updates simultaneously.

{
  "_id": 101,
  "name": "Alice",
  "department": {
    "id": 2,
    "name": "Marketing",
    "head": "Eve",
    "budget": 300,000
  }
}

Notice how when you change the dept_id from 1 to 2, the nested JSON object transforms from "Engineering" to "Marketing". The database resolves the foreign key relationship and produces the correct document shape — no application code needed.

What are Property Graphs?

Some data is inherently about connections. Social networks, supply chains, fraud rings — these are best understood as graphs of entities linked by relationships.

A property graph consists of nodes (entities) and edges (relationships). Both can carry properties — key-value pairs. Oracle AI Database lets you define property graphs on your relational tables, querying them with the SQL/PGQ standard.

Hover over any node to see its properties and highlight connections. Click to lock selection.

Each green node is a Person, each red node is a Movie, and each purple node is a Review. Edges encode relationships like ACTED_IN, DIRECTED, and REVIEWS.

How does Similarity Search work?

Modern AI models convert text, images, and audio into vectors — arrays of numbers that capture semantic meaning. Similar things end up close together in vector space. Oracle AI Database stores these vectors and finds closest matches via similarity search.

Click anywhere in the space to move the pink query point and watch nearest neighbors update. Use the k slider to change how many neighbors to find.

Oracle supports multiple distance metrics: Euclidean (straight-line), Cosine (angular similarity), and Dot Product (direction + magnitude).

Inside the HNSW Index

Brute-force similarity search checks every vector — that's O(n) and far too slow for millions of vectors. Oracle uses HNSW (Hierarchical Navigable Small World) indexes to achieve O(log n) approximate nearest neighbor search.

HNSW builds a multi-layer graph. Layer 0contains all points with dense connections. Higher layers contain progressively fewer points with long-range "highway" connections. Searching starts at the top layer and greedily descends, narrowing candidates at each level.

Add points one at a time to watch the index build itself. Then search to see the greedy walk traverse layers.

Notice how the search only visits a fraction of nodes compared to brute force. The hierarchical structure means query time grows logarithmically — making billion-scale vector search practical.

The RAG Pipeline, demystified

Retrieval-Augmented Generation(RAG) is the dominant pattern for building AI applications that need factual, up-to-date answers. Instead of relying solely on the LLM's training data, RAG retrieves relevant documents and feeds them as context.

Oracle AI Database runs the entire RAG pipeline in-database: vector embeddings, similarity search, and context assembly — all without data ever leaving the database. Type a question and watch each stage light up.

Each stage is clickable — freeze the pipeline at any point to inspect the intermediate data. This transparency is what makes Oracle's in-database RAG powerful: you can debug, audit, and optimize every step.

Why ACID matters for AI

Most vector databases sacrifice ACID transactions for speed. This works fine for demos — but in production, concurrent users reading and writing vectors creates real problems: phantom reads, dirty reads, and lost updates.

Oracle AI Database provides full ACID guarantees on vector operations. Below, watch two concurrent users interact with the same data. On the left: Oracle's transactional consistency. On the right: what happens without it.

Try each scenario. The anomalieson the right aren't theoretical — they happen in production when vector data is modified during queries. Oracle's MVCC isolation ensures every read sees a consistent snapshot.

Deep Data Security for Vector Search

Vector databases typically have no concept of row-level security. If you can query, you can see everything. Oracle AI Database applies Deep Data Securitypolicies directly to vector operations — similarity search results are automatically filtered based on the user's security clearance.

Switch between user roles below and click anywhere to run a similarity search. Notice how the same query returns different results depending on who is logged in — and some nearby vectors are completely invisible. The database enforces this at the storage level, not the application layer.

This is critical for enterprises: HR data, financial reports, and legal documents can all live in the same vector store and participate in the same similarity searches — but each user only ever sees what their security label permits. No application-level filtering required.

Neural Networks inside the Database

Traditionally, ML inference requires extracting data from the database, sending it to an external service, and writing predictions back. Oracle AI Database runs ONNX models directly inside the database — data never leaves.

This eliminates network latency, reduces security risk, and simplifies architecture. Toggle between in-database and traditional modes to see the difference.

In-database inference means your ML pipeline is a single SQL statement. No API calls, no serialization overhead, no data exposure — just SELECT predict(model, features) FROM table.

SQL/JSON Path Expressions

Oracle AI Database supports the SQL/JSON path language for querying nested JSON documents. Path expressions let you navigate objects, filter arrays, and extract values — all within SQL.

Type a path expression in the input below and watch matching nodes light up in real time. Try the pre-built examples to explore different path features.

▾{
"store": ▾{
"name": "TechBooks",
"location": ▾{
"city": "Austin",
"state": "TX"
},
"books": ▾[
[0]▾{
"title": "AI Fundamentals",
"price": 29.99,
"category": "AI",
"inStock": true
},
[1]▾{
"title": "Graph Databases",
"price": 45,
"category": "Database",
"inStock": true
},
[2]▾{
"title": "Vector Search",
"price": 39.99,
"category": "AI",
"inStock": false
},
[3]▾{
"title": "SQL Mastery",
"price": 24.99,
"category": "Database",
"inStock": true
}
]
}
}

Path expressions combine with Oracle's JSON Duality Views — query the JSON shape of your relational data using powerful path syntax, with indexes accelerating the search. It's the best of both worlds.

Oracle RAC: Scalability and Resilience

Oracle RAC (Real Application Clusters) provides the foundation for running Oracle AI Database at scale. Multiple active-active instances share the same storage, each capable of reading and writing simultaneously — delivering linear scalability and near-zero downtime.

With over two decades of innovation, RAC 26ai introduces Smart Connection Rebalancing for dynamic workload optimization, linear scaling of AI vector search across instances, Two-Stage Rolling Patching for zero-downtime updates, and Fast Start Reconfiguration that resumes work 6x faster after failures.

Explore each capability below. Cluster Architecture shows the active-active design with Cache Fusion. Smart Rebalancing demonstrates workload-aware session routing. Linear Scalability uses real GloVe-25 benchmark numbers. Zero-Downtime Recovery lets you crash an instance and watch recovery.

Oracle RAC is the ideal platform for AI workloads: isolate CPU-intensive vector search on dedicated instances while OLTP continues uninterrupted on others. The shared-storage architecture means every instance sees the same data — including HNSW indexes — enabling distributed similarity search at scale.