What large database models are and why they matter for SQL data

Most people in AI now recognize acronyms like LLM (large language model) and maybe even LRM (large reasoning model). But there’s a new one that matters a lot if you work with business data: LDM, or large database model.

While LLMs are trained on text from the open web, books, and documents, LDMs are trained directly on the structured tables inside your relational databases. That makes them a powerful way to bring AI to the 99% of enterprise data that never leaves SQL systems.

What is a large database model (LDM)?

A large database model is an AI model trained on selected tables or views inside a relational database. Instead of learning from text like an LLM, it learns from rows and columns: customers, transactions, contracts, products, and so on.

In practice, you point the LDM at one or more tables, choose which columns to include, and the model learns patterns from how values co-occur across rows. It then exposes this intelligence back through SQL, so you can ask questions like:

• “Which customers are most similar to this customer?”
• “Which transactions look least like normal behavior?”
• “Which products are most similar to this product?”

Crucially, all of this happens inside the database. The data doesn’t need to be copied out to a separate AI platform.

Why LDMs matter: the 1% vs 99% data problem

Most of the hype around AI focuses on LLMs, but they typically see only a tiny fraction of enterprise data. Estimates suggest that around 1% of enterprise data ever reaches an LLM. The other 99% sits in relational databases, often protected by strict access control, encryption, and compliance rules.

To use that data with traditional AI workflows, teams usually have to:

• Extract data from production systems
• Load it into analytics or ML platforms
• Transform and clean it
• Secure it all over again in a new environment

This is slow, expensive, and risky. IBM has reported that organizations spend roughly 32–40% of their IT budget just moving data around. And every time data leaves its original, governed environment, it becomes harder to track and secure.

LDMs flip this model: instead of moving data to AI, they bring AI to where the data already lives.

How customer targeting works with and without an LDM

To see the difference, imagine an online beauty retailer. A customer finds a product they like and adds it to their cart or wishlist. The retailer now wants to find other customers who behave like this one, so they can recommend similar products.

The traditional SQL approach

Traditionally, a data scientist might build a customer profile based on past purchases and demographics, then write a SQL query like:

SELECT customer_id
FROM customers
WHERE age BETWEEN 20 AND 40
AND city = 'New York'
AND beauty_spend > 1000;

This returns a list of customers who match the hand-picked filters. But there are some big limitations:

• It’s rigid. Someone has to guess which fields matter (age, city, total spend, etc.).
• It’s incomplete. What about gender, time of day they shop, return behavior, or product categories?
• It’s slow and costly. Data often needs to be extracted, moved, and analyzed in separate tools.

The LDM-powered SQL approach

With an LDM, the query changes from rigid filters to a semantic similarity search. Instead of guessing which columns define “similar customers,” you can ask:

“Give me the customers whose IDs are most similar to this customer ID, using the model trained on this table.”

The LDM has already learned from the selected columns across all rows. It knows which values tend to appear together and how they relate. So when you ask for customers similar to CUST4729, it uses vector representations (embeddings) to find customers whose overall patterns look alike.

You can still add normal SQL filters if you want, for example limiting results to a specific country. The key is that you’re combining semantic AI search with standard SQL in a single query.

How large database models actually work

Under the hood, LDMs follow a clear process to turn relational data into something a neural network can learn from. Here’s the high-level flow.

1. Select tables and classify columns

First, you choose a table (or view) in the relational database, such as:

• customers (customer profiles)
• transactions (purchase history)
• contracts (agreements and terms)

Each column is then classified as:

• Categorical – discrete values like state, status, city, product_category
• Numeric – continuous values like age, price, amount_spent
• Key – the identifier for the row, such as customer_id or contract_id

2. Turn every value into a token

The clever part of LDMs is how they convert structured data into tokens that can be embedded as vectors.

In text models, an embedding turns a word like “cat” into a vector (a list of numbers). Words with similar meanings, like “kitten,” end up with similar vectors. But numbers in tables are trickier:

• To the model, 37 and 38 are just different tokens, not obviously related.
• Continuous columns often have many rare values (e.g., 37.5, 37.6), which don’t appear often enough to learn good vectors individually.

To fix this, LDMs bin numeric columns. A clustering algorithm groups nearby numeric values into buckets. For example:

• Ages 35–39 might become bucket B7
• Spend between $1,000–$1,500 might become bucket B12

From the model’s point of view, every age in 35–39 is now the same token (B7). We’re telling the model up front that these values are equivalent enough to treat together, instead of forcing it to rediscover that pattern from scratch.

On top of that, every value is tagged with its column name. So:

• New York in the city column becomes a different token from New York in another column (say, shipping_city).

This prevents the model from confusing identical strings that mean different things in different contexts.

3. Turn each row into a “sentence”

Next, each row is converted into an unordered “sentence,” also known as a bag of words. Every token in the row is treated as equally related to every other token in that row, regardless of its original column position.

For example, a row for customer 4729 might become:

• city:New_York
• age:B7 (ages 35–39)
• gender:F
• spend:B12 (spend bucket)
• category:Beauty

Each token combines the column name with the value or bucket ID. Categorical fields keep their labels (like New_York or Beauty), while numeric fields use the bucket IDs from the binning step.

4. Train a self-supervised neural network

A self-supervised neural network then reads through all of these row “sentences” and learns a vector representation for each unique token. The result is a vocabulary where:

• Categorical values (like cities or product categories) have learned embeddings
• Numeric buckets (like age or spend ranges) also have embeddings

Values that appear in similar rows end up near each other in vector space. For example:

• Cities whose customers behave similarly will cluster together
• Spend buckets that correspond to similar buying patterns will be close

5. Expose the model through SQL

Finally, the trained model is loaded back into the database. From there, you can call its capabilities directly in SQL, using the learned vectors to power:

• Similarity – “Which customers look most like this customer?”
• Dissimilarity / anomaly detection – “Which transactions look least like the normal pattern?”
• Clustering – “Which group does this product or contract belong to?”
• Analogy – “Does this relationship look like that other relationship?”
• Commonality / rarity – “Which records show especially common or uncommon patterns?”

All of this runs as standard SQL against the database itself, with the data staying in place rather than being shipped to an external AI service.

Real-world use cases for LDMs

Although the example above focuses on retail, LDMs are already in production across multiple industries. They’re especially useful wherever you have large, structured datasets and need semantic insight without exporting data.

Insurance and financial services

Insurers are using LDMs to:

• Retrieve similar past contracts from millions of records to see which quotes are most likely to be accepted.
• Compare new policies against existing portfolios to spot unusual terms or risk patterns.

Because everything runs inside the database, this works well in highly regulated environments where data residency and auditability matter.

Fraud detection and anomaly spotting

Fraud teams use LDMs to flag transactions that look nothing like typical behavior. Instead of relying only on hand-crafted rules (like “amount > X” or “country in this list”), they can ask the model:

• “Which transactions are most dissimilar from the usual pattern for this customer segment?”

This complements traditional rules-based systems with a more flexible, pattern-based view of the data.

Contract and portfolio analysis

Organizations that manage large numbers of contracts can use LDMs to:

• Find contracts that stand out from the rest of a portfolio
• Group similar agreements together for review or renegotiation

This kind of semantic grouping is hard to do with pure SQL filters but becomes straightforward once you can search by similarity in vector space.

Retail and product similarity search

In food and retail, LDMs can power product similarity search directly on structured product data. For example, you can ask:

• “What’s nutritionally similar to toffee-covered almonds?”

Surprisingly, an LDM might discover that oatmeal is a close match based on nutritional fields, even though the products look nothing alike at first glance. This kind of insight is especially useful for recommendation systems and product discovery.

If you’re interested in how AI is reshaping data work more broadly, it’s worth looking at how it’s changing the role of analysts in general, as covered in this guide to AI for data analysts.

The two big advantages of LDMs

Across all these use cases, two themes show up again and again.

1. The model runs where the data lives

LDMs are designed to run inside the database engine or tightly alongside it. That means:

• No massive data exports to external AI services
• Less duplication of sensitive data across systems
• Easier compliance, governance, and auditing
• Lower infrastructure and data movement costs

This is especially attractive for enterprises with strict regulatory or security requirements, and for organizations already modernizing their data platforms with AI capabilities and agents, as explored in this overview of AI agents and data platforms.

2. SQL users can ask semantic questions

With LDMs, anyone who can write SQL can tap into AI-powered semantic search and pattern detection. You don’t need a separate data science team to build pipelines and models for every new question.

Instead of:

• Exporting data
• Training a custom model
• Deploying and integrating it

…you can write a SQL query that calls the LDM’s similarity, clustering, or anomaly functions directly on the live data.

Commercial examples: IBM SQL Data Insights

One of the earliest commercial products built around an LDM is IBM SQL Data Insights, introduced in 2022 as part of DB2 for z/OS. It embeds LDM capabilities directly into the database so mainframe customers can run semantic queries on their structured data.

In March 2026, IBM followed up with SQL Data Insights Pro, which extended the approach to:

• Handle unstructured text alongside structured columns
• Support incremental model refresh, so the model can update with new data without retraining from scratch

These products illustrate the broader trend: AI is moving closer to the data layer, and LDMs are a key part of that shift.

Bringing it all together

Large database models add a new acronym to the AI vocabulary, but more importantly, they unlock the value of the data that businesses already store in relational databases.

By learning from tables and exposing semantic capabilities through SQL, LDMs let organizations:

• Ask “customers like this one” instead of hard-coding filters
• Spot anomalies and outliers without exporting data
• Explore similarity, clustering, and analogies directly in their existing data platforms

As AI continues to move from experimentation to everyday operations, LDMs offer a practical way to make the 99% of enterprise data that lives in databases part of the AI story—securely, efficiently, and in a language teams already know: SQL.