For most of the last decade, adding AI to an enterprise application meant building a second data platform next to your database: a dedicated vector store for embeddings, an ETL pipeline to keep it in sync, and a new security perimeter to audit. Oracle Database 23ai — and its 2026 successor, Oracle AI Database 26ai — takes a different position: put the AI capabilities inside the database you already run. For companies in Slovakia and the Czech Republic with significant Oracle estates, that is a meaningful shift, and it deserves an honest, non-marketing look.
From 23ai to 26ai: the timeline that matters
Oracle Database 23ai reached general availability on 2 May 2024 (version 23.4), with the “ai” suffix replacing the older “23c” name to signal native AI integration. In 2026 the line continues as Oracle AI Database 26ai: available on Oracle Cloud from late 2025 and generally available for on-premises Linux x86-64 in January 2026 (delivered as Release Update 23.26.1 on the same 23.x codebase, so 23ai environments adopt it without recertifying applications).
Both 23ai and 26ai are Long-Term Support releases, with Premier Support running to 31 December 2031. The relevance for Central Europe is the large installed base of Oracle Database 19c — still the backbone of many local banks, utilities and public bodies. 19c Premier Support ends 31 December 2029 (Extended Support to 2032), so 26ai is the natural LTS migration target, and the planning window is now.
One hard requirement to budget for: 23ai and 26ai remove support for the classic non-CDB architecture. Every upgrade must move to the multitenant (container/pluggable database) model.
AI Vector Search: embeddings as a native data type
The headline feature is AI Vector Search. Instead of exporting data to an external engine, Oracle adds a native VECTOR data type, so embeddings live in the same table as the row they describe — and stay consistent with it under full ACID transactions.
A few concepts worth knowing without going down the rabbit hole:
- Storage formats trade precision for size and speed:
FLOAT32(default, highest precision),INT8(≈4× smaller), andBINARY(up to ≈32× smaller) — useful when you have hundreds of millions of vectors. - Two index types. HNSW is an in-memory graph index: very fast, high recall, but it must fit in a dedicated memory area (the Vector Pool) and is sensitive to heavy writes. IVF is a disk-based partitioned index: better for write-heavy and very large datasets, at some cost to latency and recall.
- Standard SQL. You query with
VECTOR_DISTANCE(...)and a metric (cosine, Euclidean, dot product), and addFETCH APPROXIMATE FIRST n ROWS ONLYto use the index. Crucially, you can combine that with ordinaryWHEREclauses and joins — the thing dedicated vector stores struggle with.
Oracle also ships the full Retrieval-Augmented Generation (RAG) pipeline in the database via the DBMS_VECTOR_CHAIN package (chunking, embedding, retrieval, prompting), and an embedded ONNX runtime so you can import an open-source embedding model and generate vectors locally — without sending data to an external API.
More than vectors: the converged database
The 23ai/26ai value proposition is “converged” — relational, JSON, graph and vector in one engine:
- JSON-Relational Duality lets developers read and write the same data as JSON documents (MongoDB-compatible APIs, REST) and as relational tables, with the database keeping both in sync in one transaction.
- Operational Property Graphs (SQL/PGQ) add ISO-standard graph queries on top of relational tables — no separate graph database.
- SELECT AI turns natural language into SQL, augmented with your schema metadata, and works on-premises in 26ai.
Honest comparison: Oracle vs dedicated vector databases
Native vector search is not automatically the right answer. The trade-off:
| Oracle AI Vector Search | pgvector (PostgreSQL) | Pinecone (SaaS) | Milvus (self-hosted) | |
|---|---|---|---|---|
| Best when | Data already in Oracle; ACID + SQL filters matter | Already on PostgreSQL, small–mid scale | Green-field, cloud-native, very high query volume | Massive scale with a dedicated ops team |
| Scale | To billions (IVF / Exadata) | Millions (degrades past tens of M) | Billions | Billions (distributed) |
| Transactions | Full ACID, one security perimeter | Full ACID | Eventual consistency | Tunable |
| Operational overhead | Low on OCI, higher on-prem | Low–moderate | Zero (managed) | High (cluster to run) |
The short version: if your authoritative data already lives in Oracle, keeping vectors next to it removes an entire integration and a second thing to secure. If you’re a cloud-native startup with no relational legacy and enormous query volumes, a dedicated engine may still win. We’re independent — we’ll tell you which case you’re in rather than push a single answer.
What it actually means for licensing and sizing
Here the marketing and the reality need separating:
- AI Vector Search is included at no additional license cost in every edition — Enterprise Edition, Standard Edition 2, and even the free Oracle AI Database Free. (A common misconception is that it’s Enterprise-only; it isn’t.)
- The genuine edition differences are elsewhere: RAC, the Partitioning option (needed for partitioned IVF indexes at scale), Advanced Security/TDE (to encrypt vector data), and CPU/socket limits. SE2 caps at 16 threads and 2 sockets; EE lists at roughly 2.7× the per-processor price of SE2.
- HNSW memory must be sized deliberately. Because the graph is held in memory, you provision the Vector Pool with
VECTOR_MEMORY_SIZE. A rough estimate is1.3 × bytes_per_element × dimensions × rows. For 5 millionFLOAT32vectors of 1,536 dimensions (typical OpenAI size) that’s roughly 40 GB of RAM — not a rounding error. Oracle providesDBMS_VECTOR.INDEX_VECTOR_MEMORY_ADVISORto estimate before you build.
The takeaway: the licence may be free, but the architecture (memory, indexes, RAC behaviour) is where projects succeed or stall. That’s a database-management and licensing question, not a marketing one.
Why this matters specifically in SK & CZ
For regulated organisations here — banks under the NBS/ČNB, utilities, healthcare, public administration — the strongest argument for in-database AI is data residency. Exporting core records to a US-headquartered vector SaaS frequently fails a GDPR or NIS2 review. Generating embeddings with a local ONNX model and searching them inside the database (on-premises, or in the OCI EU Sovereign Cloud) keeps sensitive data inside the existing security boundary.
Concrete, near-term use cases for local Oracle E-Business Suite / Siebel estates: semantic search across service requests and customer history, and APEX-based internal chatbots grounded in your own data via SELECT AI and RAG — without a second platform.
Bottom line
Oracle 23ai/26ai makes a credible case: real AI capability, inside the transactional database you already trust, without a new data-residency problem. It is not magic — HNSW memory, index choice and RAC behaviour need real engineering, and a dedicated vector database is still the better fit for some workloads. The honest path is to map your actual data, scale and compliance needs before committing.
That mapping is exactly what we do, independently and without reselling licences. If you’re weighing AI features on your Oracle estate — or planning the 19c → 26ai move that’s coming anyway — let’s talk.
