Databricks Puts Decision Models in SQL: The Build-vs-Buy Call

Any Head of Data staring at a 2026 GenAI line item should read the weekend's Databricks post twice. A new class of "System One" decision models, cheap, fast classifiers that pick from a fixed set of options, is now callable from a SQL cell against governed lakehouse data. That collapses a workflow that most teams currently outsource to a vendor endpoint into a single ai_query call, and it does so without asking anyone to provision a GPU.

What Happened

Over the weekend, a wave of so-called System One decision models landed, with Jev as the flagship. As Databricks described it, these are foundation models tuned to produce well-calibrated decisions from a discrete set of options, meaning they're built for classification and routing rather than open-ended generation. They're described as extremely fast and cheap, which is the qualifier that matters when you're scoring millions of rows.

The open source community followed almost immediately, releasing open-weight variants including Smelf-open-jev, Laya, and Kev. Databricks then wired one of them, SemIf-OpenJev, into a demonstration notebook that classifies hotel reviews as good or bad against data already sitting in the lakehouse.

The mechanics are deliberately boring. A user imports the notebook, picks a model name and schema, selects Serverless GPU, and clicks Run All. The notebook downloads the model files, registers the model through Express Deployments, and stands up a GPU Model Serving endpoint automatically. No infrastructure ticket, no capacity planning meeting, no Terraform review.

The interesting part is the query surface. The endpoint doesn't have to expose a chat-completions API, because ai_query supports arbitrary custom model APIs. That means the SemIf-specific request format flows through untouched, and the response comes back as structured columns containing the selected classification and the option probabilities. From the analyst's chair, a decision model looks like a UDF. From the platform's chair, it looks like one more managed endpoint governed by the same catalog rules as every other object in the workspace. AI Runtime rounds out the story by letting teams customize or post-train these models against their own enterprise context.

Technical Anatomy

The architectural move here is worth naming clearly. Databricks has taken the two hardest parts of running an open-weight model in production, the serving layer and the invocation layer, and wrapped both in primitives that already exist in the platform. Model Serving handles the endpoint. ai_query handles the call. Unity Catalog handles the governance around both. The novelty isn't the model, it's the routing.

Consider what a decision-model workload looked like six months ago. You picked a hosted inference vendor, negotiated a per-token contract, wrote a batch job that pulled rows out of the lakehouse, called the vendor's REST endpoint, parsed the JSON, and wrote results back. Somewhere in that pipeline you had a secrets manager, a rate limiter, a retry policy, and a finance conversation about egress. The Databricks docs now describe a path where the model lives inside the governance boundary and the SQL engine calls it directly, which erases most of that plumbing.

The probability output matters more than the classification. Well-calibrated probabilities mean downstream logic can threshold on confidence, route ambiguous cases to human review, and build monitoring on drift in the distribution rather than just on accuracy. For an analytics team that already has dbt models producing features, adding a decision column becomes an incremental transformation rather than a new subsystem. Anyone running a dbt project can visualize the change: the model call sits where a CASE statement used to sit, except now the case logic is learned.

Serverless GPU is the quiet enabler. On-demand compute means the endpoint doesn't burn money when idle, which is the unit-economics story that makes System One models plausible for wide deployment. A classifier that costs fractions of a cent per row and only spins up when the query runs is a very different budgeting exercise than a dedicated GPU cluster sized for peak throughput.

Who Gets Burned

The most exposed cohort is the middle layer of AI vendors selling hosted classification and routing endpoints. If your product's core value is a REST API in front of a fine-tuned classifier, and your customer's data already lives in Databricks or Snowflake, the friction of your integration just became a competitive liability. The buyer's CFO is going to notice that the same workload runs inside the existing lakehouse contract with no new PO.

The CFO at any series-B fintech or iGaming operator running managed decisioning should be asking their VP Engineering this week a specific question: how much of our current inference spend is on workloads that could be expressed as "pick one of N options against a row in our warehouse". If the answer is more than a quarter of the bill, the 2026 renewal conversation with the current vendor just changed shape, and the use sits with the platform team that can prototype an alternative in a notebook.

Second exposure: internal ML platform teams whose charter was to stand up in-house serving infrastructure. The build-vs-buy math shifts when the "buy" side of the ledger stops meaning a third-party SaaS and starts meaning a feature bundled into the existing data warehouse contract. Head of Platform roles built around Kubernetes-based model serving are going to find themselves justifying complexity that a serverless endpoint erased.

Third exposure: compliance and legal teams at regulated operators who spent Q3 negotiating data processing agreements with external inference vendors. Running the model on governed lakehouse data means the DPA question mostly evaporates, because the data never leaves the trust boundary. That's a win for the GC, and a reason for procurement to reopen files they thought were closed.

Playbook for Data Teams

Start with an inventory. Pull the last ninety days of external inference spend and tag each workload as either generative (long-form output) or decisional (pick one of N). The decisional bucket is your migration candidate list. Anything hitting a hosted classifier for sentiment, intent, routing, fraud triage, or content moderation belongs on that list.

Next, run the importable notebook against a real workload, not a demo dataset. Pick a classification job you already trust the ground truth on, run SemIf-OpenJev over it, and compare the probability distributions against your incumbent vendor's output. Calibration is where these models either earn their keep or don't, and you want that answer before the vendor renewal, not after.

Third, get AI Runtime post-training on the roadmap for Q1. Out-of-the-box open weights will handle generic cases, but the differentiated wins come from tailoring the model to your taxonomy, your edge cases, and your regulatory vocabulary. Teams that treat this as a one-click deployment will get one-click results. Teams that budget for post-training will get defensible accuracy on the workloads that actually matter.

Finally, revisit your governance model. A model endpoint invoked from SQL is a new kind of object in the catalog, and the audit story around who called what model against which rows needs to be explicit before an auditor asks. Better to write that policy this quarter than to retrofit it under deadline.

Key Takeaways

• System One decision models like Jev and its open-weight variants (Smelf-open-jev, Laya, Kev) collapse classification workloads into a SQL primitive on Databricks via ai_query.
• Serverless GPU plus Express Deployments removes the infrastructure and MLOps overhead that made in-house serving a build-vs-buy toss-up.
• Structured output including option probabilities means downstream analytics can threshold on confidence, not just accept a label.
• Hosted classification vendors face renewal pressure as governed lakehouse data pulls inference inside the existing contract boundary.
• Teams evaluating decision-model deployment should now be asking whether their current external inference spend is defensible against a workload that runs natively in their warehouse.