Oracle Database 23ai: What Actually Changed and What Matters

Oracle Database 23ai shipped with one of the biggest version bumps in years — both in marketing and in actual features. This post is a developer-focused tour of what changed, what’s worth your time, and what’s still vaporware-adjacent.

If you’ve been running 19c (the previous long-term release) and are weighing a move to 23ai, this is the practical view.

What “23ai” actually means

Oracle skipped 22 entirely. The product was originally called 23c (cloud) and then 23ai once Oracle bundled in AI-adjacent features. The “ai” suffix isn’t pure marketing — there’s real surface area for vector search, in-database ML inference, and SQL-level integration with external models. But it’s also true that “AI” is the new sticker on a release that contains plenty of unrelated improvements.

Treat the version as a major release with three distinct strands:

AI-adjacent features — vector, model integration, AI Smart Scan
Developer experience improvements — JSON-relational duality, Boolean datatype, ergonomic SQL
Performance, security, and admin features — true cache, gradual password rollover, schema-only accounts

The first strand is what you’ll see in conference talks. The second is what makes day-to-day development materially nicer. The third is what your DBA cares about.

SQL-level AI features that matter

The headline is AI Vector Search. Oracle added a native VECTOR datatype, distance functions, and an approximate-index type. You can store embeddings alongside your relational data, query them with familiar SQL, and join against existing tables without an external vector store:

CREATE TABLE documents (
  id     NUMBER PRIMARY KEY,
  body   CLOB,
  embed  VECTOR(1024, FLOAT32)
);

SELECT id, body
FROM   documents
ORDER BY VECTOR_DISTANCE(embed, :query_vector, COSINE)
FETCH FIRST 10 ROWS ONLY;

For applications that already keep their canonical data in Oracle, this is a meaningful simplification. You don’t have to run a parallel Pinecone/Weaviate/Qdrant cluster, sync data into it, and reason about consistency between two stores.

Whether it’s the right choice depends on scale. A vector store purpose-built for similarity search will still outperform Oracle on pure vector workloads at the high end. But for most line-of-business apps with embedding counts in the millions, native vector in Oracle is fast enough and operationally simpler than the alternative.

The Select AI feature lets you ask natural-language questions of your tables, with an LLM handling the SQL translation. Useful for ad-hoc exploration. Not yet a substitute for written queries in production code — and you shouldn’t lean on it for anything that needs deterministic results.

JSON-Relational Duality

This is the feature that most genuinely changes how applications can be written. Duality views let you define a JSON view on top of relational tables, and crucially, the JSON view is updatable. Your application can write a single JSON document and Oracle distributes the changes across the underlying normalized tables.

CREATE JSON DUALITY VIEW orders_dv AS
  SELECT JSON {
    'orderId'  : o.id,
    'customer' : (SELECT JSON {'id': c.id, 'name': c.name}
                  FROM customers c WHERE c.id = o.customer_id),
    'lines'    : (SELECT JSON_ARRAYAGG(
                    JSON {'sku': l.sku, 'qty': l.qty})
                  FROM order_lines l WHERE l.order_id = o.id)
  }
  FROM orders o WITH UPDATE;

This is one of the cleanest answers to “use a document DB or relational DB?” I’ve seen. You get strict referential integrity at the storage layer and document-shaped reads/writes at the application layer. The compromises that usually force the choice — denormalize for the document model, or normalize and stitch in the app — both disappear.

The catch is that duality requires careful schema design upfront. You can’t bolt it onto an existing chaotic schema and expect clean documents to fall out. But for new applications, it’s worth designing the schema with duality in mind from day one.

Developer-experience wins

Three small features that compound:

Boolean datatype. You can finally declare BOOLEAN columns directly in DDL and use them in SQL, without a NUMBER(1) CHECK ... workaround.
IF [NOT] EXISTS on CREATE/DROP. No more wrapper PL/SQL blocks for idempotent DDL.
GROUP BY column aliases. You can group by an alias declared in the same SELECT — a small win that improves readability everywhere.

None of these is a megafeature. Together they remove enough friction that writing SQL in 23ai feels noticeably better than 19c. The kind of difference that’s invisible in slides and obvious in your editor.

What it doesn’t change

A few things worth being clear about:

It’s still Oracle. Licensing, edition tiers, and the operational learning curve are unchanged. If your team didn’t enjoy running Oracle on 19c, 23ai won’t fix that.
AI features don’t replace good schema design. Vector search and Select AI are layers on top of your model — they don’t compensate for a bad one.
Cloud-only features exist. Some advertised capabilities ship first on Autonomous Database and trail to on-prem. Verify availability for your specific edition before planning.

Should you upgrade?

If you’re on 19c, the planning question is when, not whether. 19c remains supported for a while, but 23ai is now the canonical target. Things to weigh:

Application certification. Critical apps need testing on 23ai before any production move.
Driver versions. JDBC, ODP.NET, and node-oracledb all need compatible versions.
Standby strategy. Data Guard configurations need verification with the new release.
Feature-driven moves. If you need vector search, duality views, or specific 23ai-only features, the upgrade conversation starts now. If you don’t, it’s a normal supportable-version-floor migration.

For new projects starting today, 23ai is the right default. The DX improvements alone make it a better authoring experience than 19c, and starting on the current release saves a future migration. The AI features and duality are bets you can take or leave depending on what you’re building — but the floor of 23ai is already higher than 19c was.