top of page
logo

Oracle AI Database: 4 Features I Found Useful for Architects and Developers

Writer: Suresh Vuribindi
Suresh Vuribindi
Jul 6
5 min read

When people talk about Oracle AI Database, AI Vector Search is usually the feature that gets the most attention. It is a significant capability that makes it easier to build AI-powered applications directly on Oracle Database. As I spent more time looking at the 23ai and 26ai releases, what stood out to me was how Oracle is also improving the broader application architecture around the database.

Oracle is steadily moving toward a platform where transactional data, JSON documents, vectors, and business semantics can coexist in the same database. In this post, I’m looking at these features from an architect and developer perspective, with utility industry use cases in mind.

 

These are the four features that I found most interesting and practical.


AI Vector Search

Before vector support became available inside Oracle Database, many AI architectures relied on a separate vector database. That meant additional infrastructure, integrations, and operational overhead. Oracle changed that with AI Vector Search in 23ai and continues to build on it in 26ai. What I like about this feature is not simply that Oracle can store vectors; it is that AI workloads can now live much closer to enterprise data.

For example, imagine building an AI assistant for utility operations. Instead of searching disconnected repositories, it could bring together information such as past equipment issues, repair notes, inspection records, standard procedures, and field work updates stored within the same data platform. A field engineer could ask, “Show me similar transformer failures from the last five years and how they were resolved.” From an architectural perspective, keeping the architecture simpler can make the solution easier to secure, operate, and maintain. AI Vector Search helps move us in that direction.


JSON Relational Duality Views

Many application teams work with both JSON and relational data. JSON is convenient for APIs and mobile apps, while relational tables are still important for reporting, governance, and analytics. The challenge is keeping both models in sync without adding extra complexity. JSON Relational Duality Views help simplify that design by letting applications read and write data as JSON documents, while Oracle stores the same data in normalized relational tables as the single source of truth. The application gets a flexible document-style view of the data, while the database continues to manage consistency, transactions, constraints, and SQL access underneath.


Here is a simple example of how an inspection record could be presented to an application as a JSON document:

{  "inspectionId": 101,  
   "assetId": "TX-2045",  
   "status": "Completed",  
   "findings": [
	   {
		"type": "Oil Leak",      
		"severity": "Medium"
	   }  
   ]
}

To a mobile inspection application, this looks like one simple JSON document. Underneath, Oracle can still manage the related inspection, asset, and findings data in relational tables and produce the JSON document when needed. Developers get a clean document-style payload, while database teams keep relational consistency, SQL access, transactions, and governance without creating another copy of the data.


SQL Domains and Annotations

SQL Domains and Annotations are useful because they help describe what data actually means. A SQL Domain lets you define a reusable business rule or data type once and then apply it consistently across multiple tables. Instead of repeating the same data type, length, allowed values, or validation rule in many places, you can define it as a domain and reuse it wherever that business concept appears. An Annotation adds extra descriptive information to a database object, such as a table, column, view, or domain, so people and tools can better understand its business meaning or intended use.

For example, if several tables store an asset status, a team could define one reusable domain for valid status values such as Active, Retired, or Maintenance. Any column that uses that domain follows the same rule, which reduces inconsistent definitions and makes future changes easier to manage.

CREATE DOMAIN asset_status_d AS VARCHAR2(20)
  CONSTRAINT asset_status_chk
  CHECK (VALUE IN ('ACTIVE', 'RETIRED', 'MAINTENANCE'));

Annotations are useful when the database object name alone does not explain enough. For example, a column named AST_STAT_CD may be familiar to the team that owns the system, but it may not be clear to a new developer, analyst, reporting user, or AI tool. An annotation can add a simple description, such as “Asset Status Code,” along with notes about what the column represents and how it should be used. That extra context makes the data easier to understand, reuse, and govern, especially as more applications and AI tools depend on clear business meaning.

CREATE TABLE asset_inspections (
  inspection_id NUMBER,
  asset_id      VARCHAR2(30),
  status        VARCHAR2(20) DOMAIN asset_status_d
                ANNOTATIONS (
                  display 'Asset Status Code',
                  description 'Current status of the asset'
                )
);

Modern SQL Enhancements

These SQL enhancements may not get as much attention as the AI features, but they are very useful for everyday development. Oracle has added several improvements that make SQL easier to write and maintain, such as cleaner grouping syntax and better support for true-or-false values.

What stands out about these updates is that they improve the small things developers deal with every day: writing summary queries, creating deployment scripts, and returning data from DML statements without extra steps. None of these changes require a major redesign, but together they make SQL code easier to read, test, and maintain.

Here are a few SQL enhancements that stood out to me from a day-to-day developer productivity point of view:

  • GROUP BY ALL: Reduces repetition in summary queries by grouping on the selected non-aggregate columns automatically.

  • Native BOOLEAN in SQL: Makes true-or-false logic clearer without relying on Y/N or 1/0 values.

  • IF EXISTS and IF NOT EXISTS: Helps make deployment and cleanup scripts safer to rerun.

  • Optional FROM clause: Allows simple SQL expressions without selecting from DUAL.

  • Enhanced RETURNING clause: Returns values from DML operations without an extra SELECT.


For example, GROUP BY ALL can make summary queries much easier to read:

-- Prior approach
SELECT asset_type, region, status, COUNT(*)
FROM utility_assets
GROUP BY asset_type, region, status;

-- Oracle 23ai / 26ai style
SELECT asset_type, region, status, COUNT(*)
FROM utility_assets
GROUP BY ALL;

Final Thoughts

The main takeaway for me is that Oracle Database 23ai and 26ai are not just about adding AI features to an existing database. What stands out is how Oracle is moving more of the foundational AI capabilities closer to where enterprise data already lives. Instead of treating every AI use case as something that requires a separate platform, these releases show how more of that capability can become part of the database itself.

That matters because modern architecture can get complicated when every new requirement adds another platform, another integration layer, and another place to secure and govern data. The value of these releases is that they give teams more ways to build smarter applications while keeping the overall design simpler and easier to manage

Comments

bottom of page