Oracle presents a converged database architecture designed to address the challenges of deploying RAG (Retrieval-Augmented Generation) systems and AI agents in production environments. The problem centers on the limitations of multi-store architectures where vector indexes, operational databases, and search systems exist as separate services connected by synchronization pipelines, creating staleness, governance gaps, and consistency issues. Oracle's solution—the Oracle AI Database 26ai—provides native support for relational, document/JSON, graph, vector, spatial, and text data models under a single optimizer, transaction boundary, consistency model, and security domain. The approach eliminates synchronization lag between embeddings and source data, enables cross-model queries with unified access control, and allows atomic transactions spanning multiple data models, thereby reducing the risk of agents acting on stale information and simplifying the operational complexity of production AI systems.
This case study presents Oracle’s architectural approach to supporting AI workloads in production, specifically focusing on Retrieval-Augmented Generation (RAG) systems and AI agents. The text is primarily a technical whitepaper published by Oracle in 2026 that introduces the concept of a “converged database” and argues for its necessity in production AI deployments. While this is vendor material that promotes Oracle AI Database 26ai, it provides substantive technical arguments backed by executable proof scripts and references to academic literature, making it a valuable case study for understanding architectural patterns in LLMOps.
The core thesis is that modern AI workloads—particularly RAG systems and autonomous agents—have requirements that expose fundamental weaknesses in traditional multi-store architectures where vector databases, operational databases, search engines, and graph databases exist as separate services. Oracle argues that what AI workloads genuinely need is retrieval that is simultaneously fresh (no synchronization lag), governed (permissions enforced at retrieval time), and joined (combined with operational context). The converged database architecture attempts to address these requirements by supporting multiple data models within a single database engine that shares transaction boundaries, query optimization, consistency guarantees, and security policies across all models.
Oracle identifies a specific production problem they term “State Vector Dissonance”—when vector embeddings lag behind the source data they represent due to synchronization pipelines between systems. In typical multi-store architectures, operational data lives in one database (e.g., PostgreSQL, DynamoDB), while embeddings are stored in specialized vector databases (Pinecone, Weaviate, Qdrant). Updates to source data trigger change data capture (CDC) processes or application-level synchronization to update embeddings, creating an inevitable staleness window.
For RAG systems answering questions, this staleness can result in incorrect but confident responses based on outdated information. For AI agents with the authority to take actions—such as processing refunds, updating customer records, or making purchasing decisions—the staleness window converts directly into business risk. An agent retrieving stale context about a customer’s account status or order history could make decisions based on facts that are no longer true.
The text cites specific vendor documentation to substantiate these consistency concerns. Pinecone’s documentation provides a data freshness checking mechanism specifically because written data is not immediately visible to queries—updates are eventually consistent. MongoDB Atlas Search runs in a separate Lucene-based process (mongot) fed from the database by change streams, with documented eventual consistency and no read-after-write guarantees. These are not hypothetical limitations but documented operational characteristics of these systems.
Oracle defines convergence through five testable criteria that distinguish it from simply “multi-model” support. Each criterion is demonstrated through executable proof scripts in a companion GitHub repository that runs in continuous integration against Oracle AI Database 26ai Free container:
One Transaction Boundary: A single ACID transaction can span relational inserts, document writes, vector updates, and graph operations, with atomic rollback across all models. The proof script demonstrates inserting a relational order, its line items, a JSON document into a collection, and updating a vector embedding all within one uncommitted transaction. This matters for production AI because it means that when an agent takes an action (e.g., updating a customer record), the corresponding embedding update happens atomically—there is no window where the database and vector index disagree. The text notes that Lu and Holubová’s 2019 ACM Computing Surveys examination of multi-model databases found no evidence of cross-model transaction management in approximately twenty systems surveyed.
One Optimizer: A cost-based query planner produces a single execution plan for statements that touch multiple data models. The proof demonstrates this with a query that traverses a referral graph (finding customers within 1-4 hops), filters by JSON predicates, ranks by vector similarity, and joins relational context—all in one statement with one explain plan. The plan shows the graph pattern unrolled into relational joins, the JSON predicate as a hash anti-join, and vector ranking as a sort operation, all costed together. This matters for production AI workloads because it means complex retrieval patterns—“find similar support tickets for customers in this region with open orders”—can be optimized as a unit rather than assembled through application-level coordination of separate API calls to different services.
One Consistency Model: Read-your-writes consistency holds across all data models and APIs because no replication pipeline sits between them. The proof script writes through the MongoDB-compatible document API and immediately reads through SQL, verifying the write is visible in the same second. For AI agents, this eliminates an entire class of consistency bugs where an agent’s own writes are not visible to subsequent retrieval operations.
One Security and Governance Domain: The same grants, row-level policies, and audit streams apply across SQL, document APIs, vector search, and graph traversal. This addresses a significant production AI challenge: in multi-store architectures, access control must be enforced either in application code (error-prone and easily bypassed) or replicated across multiple systems. With a converged architecture, a user’s (or agent’s) permissions are enforced inside retrieval operations regardless of which API surface is used.
Shared Access Surfaces: SQL, MongoDB-compatible document API, and REST operate on the same data as projections of one engine. The text demonstrates this through JSON-Relational Duality Views, which are documents that represent normalized relational rows, readable and writable through the document API while maintaining full referential integrity underneath.
The implementation runs on Oracle AI Database 26ai, which supports relational tables, native JSON with a binary representation (OSON), property graphs via SQL/PGQ (SQL:2023 Part 16 standard), vector search with native vector data types, and spatial data. The architecture leverages several technical mechanisms:
JSON-Relational Duality Views provide a document interface over normalized relational data. A duality view appears as a JSON document through the MongoDB-compatible API but is actually a projection of underlying relational rows. Updates through the document API modify the base tables, and updates to base tables are immediately visible through the document view. Optimistic concurrency is provided through etags, allowing lock-free concurrent updates. The text notes documented restrictions: duality views require an _id field as document identifier and cannot have Virtual Private Database policies applied directly to the view.
Graph Integration via SQL/PGQ implements the SQL:2023 property graph query standard, where graph patterns are internally translated to SQL and optimized by the same cost-based optimizer as relational queries. The proof demonstrates a graph traversal (finding customers within 1-4 referral hops) appearing in an explain plan as a series of joins over the referral edge table, integrated into a larger query that also includes JSON and vector operations.
Vector Search is implemented as a native data type with VECTOR columns that can be queried using VECTOR_DISTANCE functions. The text demonstrates vector similarity ranking integrated into queries that also filter on relational predicates, JSON properties, and graph patterns. Importantly, because vectors are stored in regular database tables, they participate in the same transaction boundaries as other data—an embedding update can be included in a transaction that also updates the source data.
MongoDB-Compatible API provides wire-protocol compatibility allowing MongoDB client drivers to connect and execute document operations against duality views or native JSON collections. The text notes that $vectorSearch, $search, and $changeStream operators are documented as beta features as of the publication date, though the core document API and duality view mechanisms are general availability.
The text explicitly compares the converged approach against common multi-store patterns and documents the specific consistency and transaction boundaries of alternative systems using vendor documentation. This represents a more rigorous approach than typical vendor marketing:
For MongoDB Atlas, multi-document ACID transactions are real and work across shards, but search and vector search run in mongot (a separate Lucene process) fed by change streams, with documented eventual consistency. The architectural boundary is that transactions apply within the database, but search indexes lag.
For ArangoDB, single-server deployments offer genuine cross-model ACID transactions, but the documentation notes limitations that apply to sharded clusters. The architectural boundary is deployment-dependent.
For PostgreSQL with extensions (pgvector, PostGIS), the extension ecosystem shares one transaction manager, planner, and security model—a genuine architectural strength. The documented seams concern optimization depth: pgvector’s README notes that with HNSW indexes, filtering “is applied after the index is scanned” with iterative scan modes added as mitigation. This means that predicates like “find similar vectors where category = ‘premium’” cannot use the index structure to skip irrelevant vectors; instead, the index returns candidates and filters afterward.
The text acknowledges these are not absolute limitations but engineering trade-offs. Specialized vector databases optimize for standalone similarity serving at massive scale. Converged architectures optimize for retrieval that must be fresh, governed, and joined with operational context—different workload characteristics.
The technical demonstrations run against a realistic commerce domain with 200 customers, 1,000 orders, 300 support tickets with embeddings, a referral and device graph, and store locations. The domain is intentionally designed to naturally require every data model: orders are relational, customer profiles are documents, fraud detection uses graph patterns (referral rings, device fingerprint clusters), support ticket similarity uses vector search, and store proximity uses spatial queries.
A representative production query combines all models: “Find customers within the referral network of customer X (graph traversal), who have open support tickets (relational join), ranked by similarity to a given issue description (vector search), and exclude those who have already received resolution through a specific channel (JSON document predicate).” In a multi-store architecture, this becomes application code coordinating separate API calls to a graph database, a relational database, a vector database, and a document store, with no unified query plan and no transaction boundary. In the converged architecture, it is one SQL statement with one execution plan.
A notable aspect of this case study is the emphasis on reproducibility. Every code sample in the text is an excerpt from the converged-database-lab GitHub repository, executed by GitHub Actions CI on every change and nightly against the gvenzl/oracle-free container (Oracle AI Database 26ai Free). The repository contains five proof scripts with 20 assertions total, all passing as of June 2026. The scripts are documented to run with three commands: docker compose up, pip install requirements, and python validator/run.py.
This level of reproducibility is unusual for vendor case studies and allows independent verification of claims. The stated limits are also documented: Oracle AI Database 26ai Free is capped at 2 CPUs, 2 GB database memory, and 12 GB user data—sufficient for correctness proofs but deliberately unsuitable for performance benchmarks, which is why the text contains no performance numbers. The demonstration embeddings are 8-dimensional and deterministic for CI reproducibility; the text notes that engine behavior is dimension-independent and plans for a real-model flow with in-database ONNX embedding generation in a later module.
The text situates the converged architecture within broader database research and standards evolution. It references Stonebraker and Pavlo’s “What Goes Around Comes Around… And Around…” (SIGMOD Record, June 2024), which surveyed twenty years of data model alternatives and concluded that document databases are “on a collision course with RDBMSs” and that vector databases “are essentially document-oriented DBMSs with specialized ANN indexes.” This provides academic validation for the convergence thesis from researchers outside Oracle.
The SQL standard’s evolution is also cited: SQL:2016 brought JSON operators into the language, SQL:2023 added a native JSON type (feature T801), and SQL:2023 Part 16 introduced Property Graph Queries (SQL/PGQ), bringing graph pattern matching into standard SQL. This shows that convergence is not solely an Oracle architectural choice but reflects broader industry standardization.
The text also engages with historical database research, particularly E.F. Codd’s work on normalization and redundancy. It argues that Codd’s 1969 and 1970 papers framed stored redundancy as a workload-dependent trade-off (query time versus update time and storage space) rather than a prohibition, and that document databases sacrificed data independence to win read locality. The converged approach attempts to restore the separation between logical model (normalized) and physical representation (denormalized projections) using duality views as the mechanism.
For production LLMOps, the converged architecture addresses several operational challenges:
Embedding Staleness: In typical RAG pipelines, embeddings are generated from source documents and stored in a vector database. When source documents change, embeddings must be regenerated and re-indexed, creating a staleness window. With converged architecture, embedding updates can be part of the same transaction as source data updates, eliminating staleness. The text notes plans for in-database ONNX embedding generation, which would allow triggers or procedural logic to automatically maintain embedding consistency.
Permission-Aware Retrieval: AI agents often need to respect user permissions when retrieving context. In multi-store architectures, this requires either duplicating access control logic across systems or enforcing it in application code (which can be bypassed). Converged architecture allows row-level security policies to apply uniformly across SQL queries, document API access, and vector similarity search.
Complex Retrieval Patterns: Production RAG often needs more than pure similarity search—“similar documents that this user has permission to see, related to open cases, within the last 30 days.” Multi-store architectures implement this through application code that orchestrates calls to multiple services and manually joins results. Converged architecture allows these patterns as declarative queries with unified optimization.
Agent Action Safety: When agents take actions (updating records, initiating workflows), the action and its context retrieval should be atomic. If retrieval sees stale data, the agent may act inappropriately. Transaction boundaries spanning operational updates and embedding/context updates reduce this risk.
Simplified Operations: Managing separate vector databases, document stores, graph databases, and relational databases requires separate backup strategies, separate monitoring, separate security audits, and synchronization pipeline maintenance. Convergence reduces operational surface area.
This is vendor material promoting Oracle’s database platform, and several considerations apply:
The text focuses on architectural correctness guarantees rather than performance, which is appropriate for establishing feasibility but leaves important questions unanswered. How does vector search performance compare to specialized systems at scale? The free tier container is deliberately unsuitable for benchmarks, and no performance data is provided. Specialized vector databases like Pinecone and Weaviate have invested heavily in optimizing similarity search at billion-vector scale with sophisticated index structures (HNSW, IVF, product quantization). Whether Oracle’s integrated approach matches this performance is not addressed.
The comparison to other systems is carefully documented with vendor citations but selectively emphasizes convergence advantages. PostgreSQL with pgvector is a genuinely competitive converged approach, and the text’s acknowledgment that it shares transaction, planner, and security model is fair, but the framing of post-filtering as a “seam” may overstate the practical impact for many workloads.
The documented beta status of key MongoDB API features ($vectorSearch, $search, $changeStream) is noted but somewhat buried. For organizations considering migration from MongoDB, these being beta features rather than general availability represents meaningful production risk.
The emphasis on transaction boundaries may not align with all AI workload requirements. Many RAG systems operate against primarily read-only knowledge bases where eventual consistency is acceptable, and the transaction guarantees impose overhead that may not be necessary. The architecture is optimized for workloads where retrieval must be fresh and actions must be safe—a specific subset of AI applications.
The duality view mechanism requires an _id field and carries documented restrictions including no VPD policies directly on views. These are engineering trade-offs, but they limit how seamlessly existing MongoDB applications can migrate.
Despite being vendor material, the case study addresses genuine LLMOps challenges. The problem of embedding staleness in RAG systems is real and well-documented in practitioner discussions. The difficulty of permission-aware retrieval is a recurring theme in enterprise AI deployments. The operational complexity of managing multiple specialized data stores is a common pain point.
The converged architecture represents one coherent approach to these problems, trading the optimization depth of specialized systems for unified guarantees. Whether this trade-off is favorable depends on workload characteristics. For AI applications that need fresh, governed, joined retrieval—enterprise agents acting on operational data, for example—the unified transaction and security model may be compelling. For standalone similarity search over static knowledge bases, specialized vector databases retain advantages.
The reproducible proof methodology with CI-validated assertions is unusually rigorous for vendor content and demonstrates that the architectural claims are at least feasible at the demonstrated scale. Whether they hold at production scale and load is a separate question that would require independent validation.
Snorkel developed a specialized benchmark dataset for evaluating AI agents in insurance underwriting, leveraging their expert network of Chartered Property and Casualty Underwriters (CPCUs). The benchmark simulates an AI copilot that assists junior underwriters by reasoning over proprietary knowledge, using multiple tools including databases and underwriting guidelines, and engaging in multi-turn conversations. The evaluation revealed significant performance variations across frontier models (single digits to ~80% accuracy), with notable error modes including tool use failures (36% of conversations) and hallucinations from pretrained domain knowledge, particularly from OpenAI models which hallucinated non-existent insurance products 15-45% of the time.
Exa.ai has built the first search engine specifically designed for AI agents rather than human users, addressing the fundamental problem that existing search engines like Google are optimized for consumer clicks and keyword-based queries rather than semantic understanding and agent workflows. The company trained its own models, built its own index, and invested heavily in compute infrastructure (including purchasing their own GPU cluster) to enable meaning-based search that returns raw, primary data sources rather than listicles or summaries. Their solution includes both an API for developers building AI applications and an agentic search tool called Websites that can find and enrich complex, multi-criteria queries. The results include serving hundreds of millions of queries across use cases like sales intelligence, recruiting, market research, and research paper discovery, with 95% inbound growth and expanding from 7 to 28+ employees within a year.
Prudential Financial, in partnership with AWS GenAI Innovation Center, built a scalable multi-agent platform to support 100,000+ financial advisors across insurance and financial services. The system addresses fragmented workflows where advisors previously had to navigate dozens of disconnected IT systems for client engagement, underwriting, product information, and servicing. The solution features an orchestration agent that routes requests to specialized sub-agents (quick quote, forms, product, illustration, book of business) while maintaining context and enforcing governance. The platform-based microservices architecture reduced time-to-value from 6-8 weeks to 3-4 weeks for new agent deployments, enabled cross-business reusability, and provided standardized frameworks for authentication, LLM gateway access, knowledge management, and observability while handling the complexity of scaling multi-agent systems in a regulated financial services environment.
