Google adds ai.classify and ai.extract SQL functions to AlloyDB AI preview

AI operations move into the query engine

Google Cloud has introduced preview SQL functions for classifying text and extracting structured fields inside AlloyDB AI. The new ai.classify and ai.extract operations are available through version 1.6.1 or later of the google_ml_integration extension on PostgreSQL 18. They connect Gemini-backed processing to operational data without requiring an application to export rows and manage a separate model-call loop.

The conventional pattern for AI-enriching database text involves selecting rows, sending them to an external endpoint, parsing model output, handling retries and writing results back. That creates application code and additional network boundaries around sensitive material. Bringing the function into SQL can simplify orchestration, although the model computation still has latency, cost and governance implications beyond an ordinary deterministic database function.

ai.classify accepts user-defined categories and returns either the single best label or multiple matching labels. Categories can be simple names or include descriptions that provide context. Developers can add few-shot examples and invoke the function over individual text, arrays or a cursor. That flexibility supports one-off analysis as well as batched enrichment across larger result sets.

Classification without hand-built prompt wrappers

Classification directly in SQL can be useful for support tickets, reviews, clinical notes and document queues. A query could assign sentiment, urgency or workflow categories near the record that will consume them. The advantage is not only less code; database permissions and existing data selection logic can constrain which rows enter the operation before model inference begins.

ai.extract targets structured fields rather than labels. The important design question is the output contract: which fields are required, their types and how missing or ambiguous values appear. Model extraction should not silently invent a value to satisfy a schema. Applications need validation, provenance and a route for uncertain records to be reviewed rather than accepted because the SQL statement completed.

Google says smart batching supports production scalability and performance. Batching can reduce per-row overhead and improve model utilisation, but it changes query behaviour. Long batches may hold resources or fail partway, and transactional expectations may not match an external inference call. Teams should understand cancellation, retries and whether repeated execution can produce different labels or extracted values.

Structured extraction still needs contracts

Cost controls belong close to the query. A broad scan over a table of historical text can generate far more inference than the author intended. Database roles should restrict preview functions, queries should filter before invoking AI and scheduled jobs should record row counts, token use and model configuration. Materialised results may be preferable when repeated queries do not require fresh inference.

Data governance remains necessary even when text does not leave the SQL interface. Organisations should confirm the model endpoint, region, retention behaviour and audit trail used by the extension. Sensitive columns may need masking or exclusion. Row-level access controls help only if the function executes with the caller’s intended privileges and derived outputs inherit appropriate protection.

Evaluation should use a labelled dataset representative of production. For classification, teams should examine confusion between categories and the business cost of false positives. For extraction, they should score field-level precision, missing-value handling and consistency across language and document formats. A handful of plausible examples is insufficient for automating decisions that affect customers or compliance.

Preview adoption should remain bounded

The preview status is a reason for deliberate scope. Start with read-only analysis or an enrichment table that can be rebuilt, not a trigger that modifies authoritative records. Pin the extension version and record model behaviour so an upgrade can be compared. Application fallbacks should handle temporary model or service unavailability without blocking unrelated database work.

These functions make AlloyDB a more active participant in AI applications. They can shorten the path between unstructured operational data and a usable signal, especially for teams already standardising on PostgreSQL. The trade-off is that probabilistic computation now appears behind familiar SQL syntax, which may tempt developers to assume deterministic database semantics that the model cannot provide.

The best implementations will expose that distinction clearly. They will treat ai.classify and ai.extract as governed enrichment services, validate outputs and measure their value against a simpler rules-based alternative. Moving inference closer to data can reduce plumbing, but it does not remove responsibility for accuracy, cost, privacy or change management.

Database teams should decide where enriched values live and how long they remain valid. A classification derived from mutable text can become stale after the source changes, while re-running inference may produce a different result. Storing the source version, model identifier, timestamp and confidence or review state alongside the output makes changes explainable. Downstream queries should distinguish machine suggestions from verified business facts. This metadata adds work, but without it an elegant SQL expression can create records whose origin and reliability are impossible to reconstruct during an audit or customer dispute.