Oracle turns NL2SQL model choice and metadata freshness into operating decisions

Oracle has added three operational controls to Enterprise AI NL2SQL: model selection, scheduled semantic-store enrichment and background SQL generation. Together, they move the service beyond a single synchronous endpoint and give platform teams explicit decisions about which model answers a question, how fresh its schema context is and how long-running requests are handled. The features were released August 26, according to the OCI release note.

Treat model choice as a tested configuration

Teams can select a model when enriching a semantic store and can override that choice for an individual Generate SQL request. If no model is selected, Oracle uses openai.gpt-oss-120b. Any on-demand OCI Generative AI model available in the region and accessible to the tenancy can be selected, but dedicated endpoints and model-parameter tuning are not supported, according to the Enterprise AI NL2SQL guide.

The important caveat is in Oracle’s own documentation: the default model has been benchmarked specifically for NL2SQL, while other supported on-demand models have not been benchmarked for NL2SQL-specific accuracy or performance. Oracle recommends evaluating alternatives against the organization’s own schema and workload. In practice, a model switch should therefore go through the same regression set as a prompt, semantic-model or schema change—not be treated as a transparent infrastructure substitution. The job response records which model was used, which gives operators a field to retain alongside accuracy, latency and cost measurements (Oracle guide).

Put semantic freshness on a schedule

Semantic stores can now refresh enriched metadata on an ISO 8601 schedule, with a minimum interval of six hours. Oracle also exposes a delta-refresh job that updates database objects changed since the last enrichment rather than rebuilding everything. Because enrichment uses the selected generative model, teams should version the model choice and refresh schedule together: changing either can change the context used for later SQL generation (Oracle release note).

A practical rollout is to start with daily enrichment, monitor schema-change frequency and failed or stale-table queries, then shorten the interval only where the evidence supports it. Delta refreshes make that less wasteful, but they do not remove the need to test whether changed descriptions and relationships produce the intended SQL.

Design background jobs as a separate path

SQL-generation requests that may exceed a client timeout can now run as background jobs. Clients submit the request, monitor it until success or failure, and retrieve generated SQL from the result. Oracle exposes this path through APIs, SDKs and the CLI, but not through the Console (OCI release note).

That means production callers need durable job IDs, retry rules and explicit failure handling rather than simply increasing an HTTP timeout. The safer deployment pattern is to keep interactive questions on the synchronous path, reserve background generation for known complex workloads, and log the model, semantic-store version and enrichment timestamp with every returned query.