Quick test. LLM, easy, that’s Large Language Model. LRM? If you’ve ever flipped on extended thinking mode, you know it: Large Reasoning Model.
Now try LDM.
Most people guess “Large Data Model.” Smart guess. Wrong guess.
It stands for Large Database Model (LDM), a specialized AI model designed to learn semantic relationships directly from structured SQL tables rather than from internet-scale text., and it isn’t a slightly different flavor of the models you already use. It’s a different species entirely. An LLM eats books, articles, Wikipedia, and half the public internet. An LDM eats a table. One table, or a view, with the columns you deliberately choose to include.
That sounds like a downgrade. It isn’t. It’s a targeting decision.
IBM presents the idea that only a small fraction of enterprise data is typically exposed to large language model workflows; the article’s “1% / 99%” framing is an IBM estimate and should not be read as an independently audited global statistic.
The practical point is less about the exact percentage and more about the governance boundary: valuable operational data often remains inside controlled databases, where copying it to an external AI pipeline can create additional security, residency, and synchronization work.
And your AI cannot see it.
So the interesting question isn’t “how do we make models smarter?” It’s “how do we get intelligence into the room where the data already lives?” That’s the question LDMs answer, and the answer is stranger and more clever than most explanations let on.
What you’ll get from this article: a precise definition, the five-step mechanism (including the one trick almost nobody explains correctly), a decision framework for whether your tables are even eligible, three documented real-world deployments, the mistakes that quietly wreck LDM projects, and an honest account of what these models cannot do.
Let’s start with the shortcut.
- An LDM is trained on your tables, not the internet. Rows become sentences; values become tokens.
- It removes the guesswork. No analyst hand-picking which three columns define “similar customers.”
- The model runs where the data lives. No extract, no pipeline, no copy sitting outside your controls.
- Numeric values get binned before training. This is the core trick — and the biggest source of bad results when done carelessly.
- It speaks SQL. Semantic queries and standard WHERE clauses combine in one statement.
- It is not a chatbot. Expecting conversation from an LDM is the fastest way to fail with one.
What Is a Large Database Model? (Definition)
In this article, “Large Database Model” refers primarily to the database-embedding approach documented by IBM SQL Data Insights and SQL Data Insights Pro. In that implementation, a selected Db2 table or view is preprocessed into tagged values and clustered numeric or text values; a self-supervised model then learns vector representations of the resulting vocabulary and exposes semantic query functions through Db2.
Other systems may use different preprocessing, model, and execution designs, so do not treat this implementation as a universal LDM specification.
Three properties define the category:
- Scope is narrow and deliberate: You point it at a table. You choose the columns. That selection is the feature engineering.
- Training is self-supervised: Nobody labels anything. The model learns from which values tend to appear alongside which other values.
- Consumption happens in SQL: The output isn’t a chat window. It’s a scalar function you drop into a SELECT statement.
IBM’s infrastructure lead Ric Lewis framed the distinction cleanly in IBM’s introduction to LDMs: these are models tuned to extract insight from large datasets and transaction streams, rather than from human language and text.
That one sentence saves a lot of confusion. LLMs model language. LDMs model co-occurrence in structured records.
An LDM is a small, focused embedding model for one table, and its narrowness is the whole point.
What an LDM Does Not Replace
An LDM is a semantic discovery component, not a complete data-science, governance, or decision system.
It does not automatically replace:
- SQL constraints and relational integrity rules;
- supervised models that require a labeled target and calibrated probabilities;
- causal analysis or randomized experiments;
- access-control policy enforcement and row-level authorization;
- data-quality monitoring and schema management;
- natural-language generation or explanation;
- fraud, credit, underwriting, or compliance decisions without validation and human oversight.
The safest role for an LDM is to generate ranked candidates, similar entities, anomalies, or hypotheses that downstream rules and domain experts can inspect. The closer the output is to an automated high-impact decision, the stronger the validation, audit, and fallback requirements should be.
The 99% Problem: Why Enterprise AI Keeps Hitting a Wall
Every enterprise AI roadmap eventually collides with the same wall. The pilot goes beautifully on documents, wikis, and support tickets. Then someone asks the model a question about actual customers, actual claims, actual transactions, and it has nothing.
Not because the model is weak. Because the data never left the vault.
IBM has cited estimates that a substantial share of IT spending can be consumed by moving and integrating data. The 32–40% figure used here is an IBM/vendor estimate, not an independently audited benchmark, so treat it as directional context rather than a universal cost ratio.
The second cost is subtler and worse. The moment data leaves its regulated environment, it becomes harder to secure and harder to track. You didn’t just spend money. You created a new copy to defend.
So the design brief writes itself: stop moving the data, and move the model instead.
The barrier to enterprise AI isn’t model capability, it’s that 99% of the useful data can’t legally or economically be relocated.
The Rigid Query Problem: Where Traditional SQL Runs Out of Road
Let’s ground this in something concrete.
A customer is browsing beauty products online. They add one to their wishlist. That’s a genuinely valuable signal, and the retailer immediately wants to know: who else behaves like this person?
The classic answer involves a data scientist building a customer profile from historical purchase patterns, then translating that profile into a WHERE clause.
SQL — the rigid approach:
SELECT customer_id
FROM customers
WHERE age BETWEEN 20 AND 40
AND city = 'New York'
AND beauty_spend > 1000;It returns a list. The list looks authoritative. Executives will act on it.
But look at what actually happened. A human being decided that age, city, and total beauty spend are the three attributes that define similarity, chosen out of dozens of available columns. Are those the right three?
Maybe. What about gender? Time of day they shop? Return history? Channel preference? Basket composition? Days since last purchase?
The query cannot tell you, because the query only knows what the analyst already believed.
That’s the rigid list problem. It doesn’t fail loudly. It fails by quietly returning a plausible answer shaped entirely by someone’s prior assumptions.
And the process around it is slow and expensive: extract records, load them into the analytics platform, run the analysis, report back. By the time the segment lands, the customer has bought elsewhere.
SQL — the LDM approach:
SELECT customer_id,
AI_SIMILARITY(customer_id, 'CUST4729') AS score
FROM customers
WHERE country = 'US'
ORDER BY score DESC
FETCH FIRST 100 ROWS ONLY;Notice what’s missing: nobody picked the fields. The model already learned, across every selected column and every row, which values tend to travel together. The database answers from vector representations, not from a human’s shortlist.
And notice what’s still there: a plain WHERE country = ‘US’. Semantic scoring and conventional filtering coexist in one statement. You are not choosing between AI and SQL. You’re getting both in the same execution plan.
IBM implements exactly this pattern through built-in Db2 functions, the AI_SIMILARITY scalar function computes a similarity score between two values and can be used anywhere SQL can be used.
| Dimension | Before — rigid SQL profile | After — LDM semantic query |
|---|---|---|
| Who defines "similar" | An analyst, from memory and intuition | The data, via learned co-occurrence |
| Columns considered | 3–5 hand-picked | Every column included in the AI object |
| Data movement | Extract → load → analyze externally | None — scored in place |
| Skill required | Data scientist in the loop | Anyone who can write a SELECT |
| Output shape | Binary in/out list | Ranked list with a similarity score |
| Governance surface | New copy to secure and audit | Existing controls still apply |
The rigid query doesn’t return a wrong answer, it returns your own assumptions, dressed up as data.
Beyond Text-to-SQL and Fragile RAG Pipelines
Talk to any enterprise data engineer working on AI integrations, and you will hear a familiar frustration. The standard playbook for connecting LLMs to structured data involves either Text-to-SQL translation or external Retrieval-Augmented Generation (RAG) pipelines.Neither solves the underlying architecture problem.
Text-to-SQL agents attempt to translate natural language questions into complex SQL queries on the fly. On paper, it sounds liberating. In production, it frequently shatters on multi-table JOIN operations, hallucinates schema relationships, and remains entirely blind to the implicit historical distributions of your data. External RAG pipelines offer a different workaround: extracting table rows, transforming them into embeddings, and shipping them to an external vector database.
But this approach immediately triggers a governance nightmare. You have created a secondary copy of sensitive records, requiring dual-RBAC maintenance, external data synchronization, and costly egress pipelines, violating the core rule of enterprise security.
LDMs bypass both dead ends. By training neural network embeddings directly within the database engine, the system learns statistical co-occurrences natively. There is no external vector store to synchronize, no fragile translation layer to debug, and zero data movement across the enterprise perimeter.
The in-database design can reduce the need to create application-level copies of the source records for semantic querying. It does not mean that every operational artifact stays in one process: training engines, model files, logs, backups, exports, and administrative interfaces still require their own data-governance review. Describe this as reduced or avoided data movement for the documented workflow, not as a universal “zero movement” guarantee.
“In-Database” Does Not Mean “No Governance Work”
Running semantic scoring close to the database can reduce the number of application-level copies of source rows. It does not eliminate governance work. Teams still need to review model artifacts, training files, logs, backups, exports, administrator access, query results, and any external training or acceleration service.
The practical comparison is not “secure” versus “insecure.” It is a comparison of data boundaries, permissions, synchronization paths, operational ownership, and failure modes. An in-database design may simplify some of those boundaries, but the deployment still needs a data-flow diagram and a security review.
How a Large Database Model Works: The 5 Steps
Here’s the mechanism, end to end. Step two is where it gets genuinely clever, and step two is also where most explanations go wrong.
Step 1: Choose a table and classify every column
Pick a table or view. A customer master. A transaction log. A claims register. Anything with rows and columns.
Then label each column as one of three types:
- Categorical, discrete values. State, status, product category, channel.
- Numeric, continuous values. Age, price, tenure, balance.
- Key, the identifier for the row. Customer ID, policy number, transaction ID.
This classification isn’t bookkeeping. It determines how each column gets processed downstream, and getting it wrong produces a model that trains successfully and answers badly.
Step 2: Turn every value into a token
This is the heart of it, and it runs on embeddings.
An embedding takes something like the word cat and turns it into a vector, a list of numbers. Words with related meanings land in similar directions. Kitten ends up near cat. That part is familiar.
Numbers are where the intuition breaks.
You’d assume 37 and 38 behave like cat and kitten, close numerically, therefore close in vector space. They don’t. To the model, 37 and 38 are just two arbitrary tokens. There is no built-in concept of numeric magnitude. 37 is, structurally speaking, no closer to 38 than it is to kitten.
They could converge indirectly, if 37-year-olds and 38-year-olds happen to behave alike across the rest of the data. But that’s a slow, unreliable way to learn something you already know for free.
Continuous columns bring a second problem: rare values. In a column with 37.5, 37.6, 37.61, each individual value may appear a handful of times across millions of rows, far too rarely for the model to learn a stable vector.
So numeric columns get binned first. A clustering algorithm groups numerically close values into buckets. Age 37 and age 38 land in the same bucket and receive the same token ID. From the model’s perspective they become literally the same thing.
Read that again, because it’s the philosophical core of the technique: you are not asking the model to discover that nearby numbers are related. You are telling it, before training begins.
There’s one more move here. Every token, numeric or categorical, gets tagged with its column name. city:New York is a different token from birthplace:New York. Without that tag, identical strings meaning different things in different columns would collapse into one confused vector.
How Timestamps and Dates Are Handled: Raw timestamps (e.g., 2026-03-14 10:42:01) suffer from high cardinality. LDMs process dates by extracting relative features prior to binning: cyclical tokens (day-of-week, hour-of-day) or recency deltas (days since last transaction). Binning relative deltas allows the neural network to learn that “purchased 3 days ago” is semantically meaningful, whereas static timestamps carry almost zero co-occurrence value.
Step 3: Each row becomes an unordered sentence
Every row is rewritten as a bag of words: an unordered sentence where each token relates equally to every other token, regardless of column position.
Our wishlist customer might look like this:
city:New_York age:B7 gender:F spend:B12 category:beauty
Categorical fields keep their original labels. Numeric fields appear as bucket IDs from step two, B7 might represent ages 35 to 39.
Why unordered? Because column order in a table carries no meaning. Putting city before age says nothing about the customer. Sequence models would waste capacity learning a pattern that isn’t there. This design choice is documented in IBM Research’s work on embeddings in relational databases, which formalized how to represent database entities as low-dimensional vectors without materializing giant denormalized joins.
Step 4: Train the model
A self-supervised neural network reads through every row-sentence and learns a vector for each unique token. No labels. No target variable. The training signal is co-occurrence itself.
The result: every selected categorical value and every numeric cluster gets a position in the model’s vocabulary. Values that show up in similar rows end up near each other. Cities whose customers behave alike drift together in vector space, even though nobody told the model anything about geography.
IBM’s documentation describes this as database embedding combined with deep self-supervised learning, inferring semantic meaning from the unique values in a user table or view.
Step 5: Expose the vectors through SQL
The trained model loads back into the database engine. Now similarity scoring is just another scalar function, available anywhere SQL is available, BI tools, application code, stored procedures, ad-hoc queries.
Data stays in place. The model comes to it.
The pipeline, visualized:
Binning and column-tagging happen before training, they are hand-injected knowledge, not learned behavior, and they decide the quality of everything downstream.
Enterprise Performance & Latency Benchmark
Simulated performance metrics across 10 Million enterprise records (Structured SQL Data).
| Architecture Metric | Traditional ETL + Ext. Model | Vector DB Sync Pipeline | In-Database LDM (Native) |
|---|---|---|---|
| Similarity Scoring Latency | 4.2s (ETL + Inference) | 380ms (API Roundtrip) | < 45ms (In-Memory Engine) |
| Data Movement / Copies | 3 Copies (Source, Lake, ML) | 2 Copies (Database + Vector Store) | Zero (0) Data Movement |
| Access Control Friction | High (Re-apply permissions) | Moderate (Dual RBAC) | Native DB RBAC & Audit Logs |
| Cost / 1M Predictions | ~$120 (Compute + Egress) | ~$45 (Managed Store) | Included in Engine Compute |
The Binning Formula, And Why It Decides Your Results
Since binning carries so much weight, it’s worth being able to reason about it numerically. A simple equal-width binning scheme assigns a bucket like this:
The practical question is always the same: how many buckets? Too few and you erase real distinctions, a 22-year-old and a 58-year-old share a token. Too many and you recreate the rare-value problem you were trying to solve.
Use this to sanity-check a column before you train on it:
Rule of thumb: if a bucket contains too few rows, its vector will be noisy no matter how good your model is. Density beats granularity.
Bucket count is a modeling decision disguised as a configuration setting. Treat it that way.
What You Can Actually Ask: Five Query Types
Once the vectors are live inside the database, five families of questions open up.
IBM documents five SQL Data Insights query families:
- Similarity: find records or entities that resemble a reference value or entity.
- Dissimilarity: identify records that differ from a reference or a learned norm.
- Semantic clustering: test whether an entity belongs to a group defined by other entities.
- Analogy: evaluate whether a relationship between one pair of entities also appears in another pair.
- Commonality: identify common or uncommon patterns relative to a model column or centroid.
The exact function names, arguments, and supported data types are product- and version-specific. Check the current Db2 documentation before copying a query into production.
What's notable is how much of classical analytics collapses into these five. Segmentation, outlier detection, recommendation, entity resolution, and portfolio comparison have historically each required their own model, pipeline, and owner. Here they are five ways of reading the same vector space.
One trained model, five question types, that consolidation is where the real operational savings come from, not from any single query being faster.
The C.O.R.E. Test: Is Your Table Even LDM-Ready?
Here's something the vendor material doesn't tell you: most tables are bad LDM candidates. you can tell in about fifteen minutes, C.O.R.E. is a fifteen-minute filter that saves weeks .
C.O.R.E. is an editorial preflight checklist, not an IBM acceptance test. It is intended to expose obvious risks before a training job: excessive cardinality, weak co-occurrence, sparse buckets, and ambiguous column semantics. The time required depends on table size, profiling access, and the quality of the data dictionary.
I use a four-part check. Run it before you request a training job.
C — Cardinality balance
There is no universal cardinality range that guarantees a useful LDM. Very low-cardinality columns may provide little discrimination, while near-unique values can create sparse vocabulary entries. Profile the frequency distribution, inspect rare-token rates, and validate candidate column sets on a reference query set rather than relying on a fixed “10 to a few thousand” rule.
O — Overlap density
Do values genuinely recur across rows? Embeddings learn from co-occurrence. If almost every row is a unique combination of unique values, there is no co-occurrence to learn from. Quick check: pick three columns and count how many rows share the same triple. If the answer is "almost none," stop.
R — Row volume per token
After binning, does every bucket and category hold enough rows to produce a stable vector? Sparse tokens are the single most common cause of "the similarity results look random."
E — Encoded semantics
Do your columns actually mean what they say? Legacy schemas are full of overloaded fields, a status column that stores a status code and a region prefix, or a notes field carrying structured data by convention. The model will happily learn the encoding as if it were meaning, and produce confident nonsense.
If a table fails two or more of these, no amount of training configuration will rescue it. Fix the table, or pick a different one.
LDM success is decided at table selection, not at training time. C.O.R.E. is a fifteen-minute filter that saves weeks.
LDM Production Readiness Checklist
Before enabling an LDM query in a production workflow, verify the following:
| Area | Questions to answer |
|---|---|
| Data object | Is the training object a table or view with documented ownership, freshness, and access rules? |
| Column semantics | Has every column been classified by meaning rather than by physical SQL type? |
| Leakage | Are identifiers, future outcomes, post-event fields, and sensitive attributes excluded or controlled? |
| Sparsity | Have rare categories, near-unique values, and empty numeric buckets been measured? |
| Baseline | Is there a deterministic SQL segment or existing model to compare against? |
| Evaluation | Do you have labeled reference entities, expert review, and no-answer or failure cases? |
| Privacy | Are model files, embeddings, logs, exports, and query results governed as derived data? |
| Operations | Is there a refresh schedule, model version, rollback path, and monitoring for drift? |
| Decision use | Is the output used for discovery and ranking, or is it being used to make a regulated or high-impact decision? |
Documented Examples and Reference Use Cases
The following examples combine IBM-documented use cases, public explanations, and illustrative query patterns. They should not be read as independently audited production case studies unless the linked source publishes deployment details, evaluation methodology, and measurable outcomes.
Theory is cheap. Here's where LDMs are actually running.
Case 1: Financial services: fraud detection that starts from one bad transaction
The challenge: Rule-based fraud systems catch patterns someone already anticipated. Novel fraud, by definition, doesn't match existing rules. And the strongest signals often hide in free-text payment descriptions that structured rules never touch.
The action: With IBM's SQL Data Insights Pro, which reached general availability on 20 March 2026, a fraud analyst begins with one known suspicious transaction and asks the database to return others that are semantically similar, including signals buried in payment description text, analyzed alongside numeric and categorical fields in a single unified model.
The outcome: IBM's documented result is qualitative rather than a published percentage: analysts move from writing rules to interrogating examples, and the investigation happens without exporting a single record off the platform. Where the impact is measurable is in the governance ledger, no external AI stack, no new data copy, existing access controls intact.
The lesson: Anomaly detection is just similarity search with the sort order reversed. Similarity and dissimilarity queries can support fraud investigation by surfacing unusual or comparable records. They do not constitute a complete fraud-detection system by themselves. Production fraud controls still require labels or investigation workflows, threshold calibration, false-positive review, policy rules, monitoring, and human or automated decision controls.
Case 2: Insurance: predicting which quotes will convert
The challenge: An insurer holds millions of historical contracts. When a new quote arrives, the useful question is: which past contracts does this one resemble, and what happened to them? Traditional scoring models require a labeled training set, a data science team, and a retraining cadence.
The action: An LDM trained on the contracts table lets underwriters retrieve the most similar past contracts directly from millions of records, then use their outcomes as a conversion signal. Similarity queries for market segmentation and behavioral grouping in retail, finance, and insurance are among the named applications in IBM's Db2 function documentation.
The outcome: The measurable shift is in cycle time and staffing: a question that previously required a data scientist to scope, extract, and model becomes a SQL statement an underwriter runs themselves. Public per-customer conversion-lift figures for these deployments have not been released, so treat the ROI as directional rather than benchmarked.
The lesson: The bottleneck in most analytics organizations was never compute. It was the queue in front of the four people allowed to build models.
Case 3: Food and retail: the toffee almond that turned out to be oatmeal
The challenge: Product similarity in food retail is deceptively hard. "Similar" by category, by brand, or by price all miss the thing shoppers often care about, nutritional profile.
The action: A nutritional database was queried semantically: what is nutritionally similar to toffee-covered almonds?
The outcome: The answer came back: oatmeal. This example is recounted in Eric Siegel's Forbes analysis of the rise of large database models, and it's instructive precisely because it's surprising. No category taxonomy would ever place a candied nut next to a breakfast grain. The vector space did, because the underlying nutritional value combinations genuinely co-occur.
The lesson: The highest-value LDM results are the ones a human would not have thought to look for. If your semantic query only confirms what you already believed, you probably didn't need it.
Case 4 (the cautionary one): What the research says embeddings miss
Success stories are only half an education.
A VLDB study characterizing embeddings of relational tables evaluated nine table and language embedding models against eight primitive properties drawn from the relational model. Two findings deserve a place on every LDM project's risk register: functional dependencies are rarely reflected in the learned embeddings, and some models are sensitive to table structure such as column order, even though relational semantics say order shouldn't matter.
Translated into business language: if your table encodes a hard rule, this policy type always implies that coverage tier, do not assume the model learned it. It may have. It may not have. And it will not tell you which.
The lesson: Use LDMs for discovery and ranking. Do not use them where a constraint must hold every time. That's what constraints are for.
LDMs are excellent at surfacing non-obvious neighbors and terrible at guaranteeing rules. Design your use cases around that asymmetry.
The Contrarian Take: Clean Schemas Make Worse LDMs
Here's the claim that gets pushback in every room I've said it in.
Textbook database design can actively hurt LDM performance.
Think about what the third normal form does. It removes redundancy. It splits wide tables into narrow ones joined by keys. It eliminates repeated value combinations, which is exactly the raw material an embedding model learns from.
A perfectly normalized customers table with eight columns and no derived fields gives the model eight tokens per row-sentence and very little co-occurrence structure. A denormalized reporting view with forty columns, including the redundant ones a purist would strip out, gives it a rich, repeating pattern of value combinations to learn from.
This inverts a reflex most data teams have trained into their bones. The instinct says clean the schema first. For LDM training specifically, the better instinct is: build a wide, deliberately redundant view, and train on that.
Two caveats, because this is a sharp tool:
- Redundancy that comes from duplication (the same fact stored twice) adds nothing. Redundancy that comes from context (denormalized attributes that co-vary with behavior) is what you want.
- Wide views raise the stakes on the C.O.R.E. test. More columns means more chances to smuggle in a high-cardinality token dump.
The general principle: normalization optimizes for write integrity and storage. Embedding training optimizes for observable co-occurrence. Those are different objectives and they pull in opposite directions.
What About Multi-Table Schemas and Foreign Keys?
A common question from database architects is: "Our schema has 50 normalized tables connected by foreign keys. Do we have to flatten everything into one mega-view?"
There are two approaches in enterprise practice:
- Materialized Analytics Views (The Practical Way): Creating a denormalized reporting view that joins foreign key relationships into a single entity-centric context (e.g., v_customer_360 joining customers, transactions, and support tickets).
- Relational Graph Embeddings (The Advanced Way): Newer frameworks encode Foreign Key relationships directly as graph edges during tokenization. Foreign keys are treated as relational references rather than standard categorical text, allowing the embedding space to preserve entity hierarchy without full materialization.
A wide, entity-centric view can provide useful context for relational embedding, but it is not automatically better than a base table. A view can introduce leakage, duplicated facts, stale joins, access-control ambiguity, or high-cardinality noise. Compare a base table, a carefully designed view, and a minimal feature set on the same evaluation queries before choosing the training object.
LDM vs. LLM vs. Vector Database vs. Text-to-SQL
Four technologies get confused with each other constantly. They solve different problems.
| LDM | LLM | Vector database | Text-to-SQL | |
|---|---|---|---|---|
| Trained on | Your selected tables/views | Public text corpora | Embeddings generated by external models | Public text + your schema |
| Best at | Similarity across structured records | Language, reasoning, generation | Fast retrieval of pre-made embeddings | Translating questions into queries |
| Data movement | Usually none (runs inside the database engine) | Prompt leaves the perimeter | Requires an embedding pipeline | Schema leaves; results may too |
| Learns from structured relationships | ✅ Native | ❌ Limited | ❌ No (stores embeddings only) | ❌ No |
| Hallucination risk | Very low — returns ranked real records | High without grounding | None | Moderate — wrong joins, missing filters |
| Who can use it | Anyone writing SQL | Anyone | Engineers | Anyone (quality depends on schema complexity) |
| Primary output | Ranked records with similarity scores | Generated text | Nearest vectors | SQL query |
| Weak spot | No language generation or reasoning | Can't see private structured data | Requires external embedding generation and synchronization | Only asks what you can express |
The honest framing: these are complements, not competitors. The most interesting near-term architecture is an agent that uses an LLM for language, calls an LDM for structured similarity, and returns real rows the user can audit.
Don't pick one. Pick which layer each is responsible for, and make the boundaries explicit.
Are Other Companies Building LDMs?
IBM is currently the primary vendor publicly marketing Large Database Models (LDMs) as a distinct commercial product category through SQL Data Insights and SQL Data Insights Pro. Other database vendors offer overlapping capabilities, such as vector search, semantic retrieval, and in-database AI, but generally do not market them as Large Database Models.
That doesn’t mean other database vendors are standing still, it means they are approaching the same problem from different directions.
Several platforms now provide capabilities that complement or partially overlap with the LDM concept:
- Oracle has integrated AI Vector Search directly into Oracle Database, allowing semantic similarity search alongside traditional SQL. However, it relies on externally generated embeddings rather than training a dedicated model from relational tables.
- Microsoft has added native vector search and AI features to SQL Server and Azure SQL, making it easier to combine structured data with embeddings and language models. These features focus on retrieval and semantic search rather than table-specific database models.
- PostgreSQL, through the popular pgvector extension, has become one of the most widely adopted open-source platforms for vector similarity search. It stores and queries embeddings efficiently but does not generate relational embeddings on its own.
- Snowflake has introduced Cortex AI and native vector capabilities that let organizations build AI applications directly inside the data warehouse. The emphasis is on integrating LLMs with enterprise data rather than training specialized database embedding models.
- Databricks combines Delta Lake, vector search, and AI tooling to support semantic retrieval and agentic AI workflows. Like Snowflake, its focus is broader AI infrastructure rather than a dedicated Large Database Model architecture.
The common trend is clear: AI is moving closer to where enterprise data lives. IBM’s LDM approach trains a model directly from relational tables, while other vendors are embedding vector search, retrieval, and AI services inside their databases. Different architectures, but the same long-term direction: reducing data movement by bringing AI capabilities closer to enterprise data, whether through dedicated database models, vector search, or tightly integrated AI services.
A key distinction is that most of these platforms rely on externally generated embeddings or foundation models for semantic search. IBM's commercial LDM approach instead trains a dedicated embedding model directly from selected relational tables, making the database itself the source of the learned semantic representation.
IBM currently leads the commercial LDM category, while Oracle, Microsoft, PostgreSQL, Snowflake, and Databricks are building complementary in-database AI capabilities that solve related, but not identical, problems.
Common Mistakes, And How to Avoid Them
These are the failure modes that show up again and again.
Including the primary key as a trainable column.
A unique identifier appears exactly once. Its vector is meaningless, and it inflates vocabulary size for zero benefit.
Fix: mark keys as keys, never as categorical features.
Treating a numeric column as categorical because it "looks like a code."
Postal codes, product codes, and account numbers stored as integers are categorical, not numeric, binning them creates buckets like "zip codes 10001 to 14999," which is geographic nonsense.
Fix: classify by meaning, not by data type.
Dumping free-text columns into a structured model.
A comments field with millions of unique strings generates millions of single-occurrence tokens. Classic SQL Data Insights was built for structured columns; unstructured text handling is what SQL Data Insights Pro's unified structured-plus-text model was specifically introduced to address.
Fix: exclude free text unless your platform explicitly supports it.
Choosing bucket counts by round numbers.
Ten buckets because ten is tidy.
Fix: choose by row density per bucket, using the calculator above.
Training once and forgetting.
Customer behavior drifts. A model trained on last year's transaction mix will confidently return last year's neighbors.
Fix: schedule refresh. Incremental model refresh, updating against new data without full retraining, is a headline capability in current LDM products for exactly this reason.
Reading similarity as causation.
The model says these customers occupy the same region of vector space. It does not say one caused the other, or that the segment will respond to the same offer.
Fix: treat LDM output as a hypothesis generator that feeds an experiment, not as a conclusion.
Forgetting that the model inherits your data's biases, and now hides them.
When a human wrote WHERE city = 'New York', the assumption was visible in code review. When a model learns that a city correlates with behavior, the assumption is invisible inside a vector.
Fix: audit results by protected attribute even when those attributes weren't explicitly selected. Especially then.
Skipping the baseline.
Teams deploy semantic similarity without ever measuring the rigid query it replaced.
Fix: run both for one cycle. If the LDM can't beat a decent hand-built segment, the problem is your table, not the technology.
Almost every LDM failure traces back to column classification or token sparsity, not to the model itself.
A Reproducible Evaluation Protocol
Do not evaluate an LDM by reading a few plausible results. Build a fixed reference set of entities and questions, then compare the LDM with the current baseline.
- Select a representative time window and freeze the training object definition.
- Remove leakage fields, post-outcome fields, direct identifiers, and columns that would not be available at query time.
- Define reference entities and label relevant neighbors with domain experts or an existing business rule.
- Run the baseline SQL or model and the LDM with the same filters and evaluation window.
- Record recall@k, precision@k, ranking quality, empty-result rate, latency, resource use, and review outcomes.
- Repeat the evaluation after retraining and compare model versions.
- Inspect results by region, product, customer segment, and protected attribute where appropriate.
- Keep raw queries, model identifiers, training-object definitions, and evaluation labels so the result can be reproduced.
A higher similarity score is not automatically a better business result. The acceptance criterion should be tied to the decision the system supports.
The Operational Shift: Incremental vs. Full Retraining
In the early days of enterprise machine learning, model drift was treated as an expensive logistical crisis. When customer behavior shifted, data teams had to schedule full retraining jobs from scratch, consuming massive compute clusters, locking tables, and introducing hours of operational downtime.
Production-grade LDMs solve this through incremental retraining. Rather than tearing down the entire vector space, incremental engines update token vectors exclusively for newly inserted or modified rows within a specified time delta or predicate window.
The system computes delta embeddings in the background, saves the retrained model as an isolated version, and allows DBAs to hot-swap or deploy the updated vector model at a scheduled moment with zero production disruption. Model freshness no longer requires architectural downtime.
Expert Layer: Five Things That Separate Pilots From Production
Vector drift is a silent failure, not a loud one
When a traditional model degrades, accuracy metrics fall and someone gets paged. When an embedding space drifts, nothing breaks. Queries still return exactly 100 rows with plausible-looking scores. The results are just quietly worse.
Build a canary: hold out a set of reference entities whose true neighbors you know from business logic, and re-score them on every refresh. If your known-good pairs stop ranking near each other, the space has moved.
Column selection is your only real hyperparameter
With an LLM, you tune prompts, temperature, context. With an LDM, the overwhelming determinant of quality is which columns you included. This is unfamiliar territory for teams used to model-centric tuning, and it means your best iteration loop is retrain on a different column set, not adjust the training config.
Practical approach: train three variants, a minimal set, your best guess, and a deliberately wide set, and compare them on the same reference queries. The winner is often not the one you'd have predicted.
In-place execution is a compliance feature before it's a performance feature
The usual pitch for running the model inside the database is speed and cost. The bigger institutional win is that your existing access controls keep working. Row-level security, column masking, audit logging, data residency rules, all of it still applies, because the query is still a query.
How the Query Optimizer Handles Vectors (HNSW & Pushdown Filtering)
Do not assume that an LDM engine uses HNSW, vector indexes, or a specific filter-pushdown strategy. Query planning and scoring behavior are product-specific. Verify the implementation and execution plan for the selected database before making a performance or architecture claim.
PII Vector Leakage: Can Embeddings Expose Sensitive Data?
While LDMs do not output text generation (eliminating prompt-injection risks), vector embeddings are mathematical representations of underlying rows. To prevent reverse-engineering sensitive attributes (e.g., Social Security Numbers or exact financial balances), high-risk columns must be designated as non-trainable KEY attributes or masked prior to Step 1. Continuous numerical binning also acts as an inherent noise-injection mechanism to protect raw individual values.
Compare that to the alternative: extract to a vector store, and you now maintain a second copy of sensitive data with its own permission model, its own audit trail, and its own residency question. That second system is not free. In regulated industries it's often the single largest cost of the project, and it never appears in the pilot's budget.
The economics of LDMs are decided in the compliance review, not the benchmark.
Under the Hood: The Three-Tier Engine and Diagnostic Scoring
Understanding the 5-step pipeline is only half the battle; knowing how enterprise-grade engines execute it separates a successful deployment from a silent failure. Modern implementations, such as IBM's SQL Data Insights Pro, rely on a robust three-tier architecture:
- The Model Training Engine: Powered by distributed compute frameworks like z/OS Spark or hardware-accelerated data accelerators capable of processing millions of transactional rows without bottlenecking operational workloads.
- The Data and Query Engine: Embedded directly into the relational database kernel, exposing vector similarity math through native scalar functions (AI_SIMILARITY, AI_ANALOGY, AI_SEMANTIC_CLUSTER) that execute within the standard query planner.
- The Management Layer: REST APIs, CLIs, and unified web interfaces that handle lifecycle administration and model deployment.
Crucially, robust training engines do not leave database administrators guessing about model quality. During preprocessing and training, they compute two vital diagnostic metrics:
- Column Influence Score: Correlates with the ratio of valid versus NULL entries, measuring how heavily a specific column dictates the model's semantic weights.
- Discriminator Score: Evaluates a column's statistical capacity to distinguish discrete entities from one another.
If a column yields a near-zero discriminator score, it tells the DBA instantly that the feature carries no signal before the model even trains, turning guesswork into measurable data hygiene.
Where This Fits in the Wider Shift
LDMs aren't an isolated curiosity. They're one expression of a broader migration: AI capability moving into the data layer.
The same pattern is visible across the industry. PostgreSQL gained vector types through pgvector. SQL Server 2025 introduced native vector-based semantic search against local and cloud-hosted models. Oracle, MongoDB, and the major cloud warehouses have all shipped similarity search inside the engine.
Meanwhile, academic work on relational embeddings has matured, the EmbDI framework presented at SIGMOD demonstrated that embeddings derived from relational structure produce meaningful results for schema matching and entity resolution in both supervised and unsupervised settings.
The convergence point is agentic AI. Autonomous agents acting on business processes need grounded, auditable access to structured records, not a summary, not a retrieved paragraph, but rows. An LDM gives an agent a way to ask "find me things like this" against a system of record without ever taking the data out.
That's the direction of travel. The model goes to the data. Not the other way around.
In-database AI is becoming a category rather than a single product. Large Database Models are one implementation of that broader trend, focused specifically on learning semantic relationships directly from structured relational data. LDMs are its most mature expression for structured data.
Hardware Realities & Re-training Cycles
Unlike LLMs that demand massive clusters of dedicated GPUs, LDMs are computationally lightweight because they model discrete relational vocabularies rather than complex syntax trees.
- CPU-Native Training: Most LDMs train efficiently on standard multi-core enterprise CPUs or built-in mainframe AI accelerators (such as IBM z16 Telum processors).
- Incremental Model Refresh: Production engines utilize incremental training, updating token vectors exclusively for newly inserted or updated rows without running a full re-train job from scratch.
IBM describes SQL Data Insights Pro as using Db2 for z/OS, z/OS Spark or Db2 Analytics Accelerator, and IBM Z acceleration technologies such as Telum and zDLC. That does not establish a universal hardware requirement for every LDM implementation. Estimate training and query resources for the selected product, table size, model, and workload instead of assuming that an LDM needs no accelerator or external compute.
Your First 30 Days: A Practical Rollout Plan
- Days 1–3 — Pick one question, not one table: Choose a specific business question currently answered by a hand-built segment. "Which accounts resemble the ones that churned last quarter?" beats "let's try AI on customer data."
- Days 4–7 — Run the C.O.R.E: test on candidate tables and views. Reject anything failing two or more checks.
- Days 8–10 — Build a wide training view: Denormalize deliberately. Exclude keys and free text. Classify every remaining column by meaning.
- Days 11–14 — Establish the baseline: Write the best rigid SQL segment you can, and record its outcome metric. You will need this number.
- Days 15–20 — Train two or three column-set variants: Score the same reference entities against each.
- Days 21–25 — Blind-review the results with a domain expert: Show them ranked neighbors with no explanation and ask: does this list make sense? Experts spot broken embeddings faster than any metric.
- Days 26–30 — Run the head-to-head: Same campaign, same period, LDM segment against the baseline segment. Report the delta honestly, including if it's negative.
Quick wins along the way: start with dissimilarity queries if you have any anomaly-detection need, they deliver value fastest because the bar is "surface something a rule missed," which is a low bar and a high payoff.
The Short Version
- Limit: an LDM ranks and surfaces relationships. It does not automatically prove causation, enforce relational constraints, explain every score, or replace supervised models and governance controls.
- LDM: In this article, an IBM-style Large Database Model is a database-embedding approach that learns representations from selected relational data.
- Problem addressed: Enterprise data often remains inside controlled systems and is difficult to expose safely to external AI pipelines; the exact “1% / 99%” split is an IBM estimate, not a universal statistic.
- Method: classify columns, preprocess or cluster values according to the product implementation, tag values with column names, train a self-supervised model, and expose semantic query functions.
- Output: similarity, dissimilarity, clustering, analogy, and commonality queries, subject to the supported product and model configuration.
- Commercial scope: IBM’s SQL Data Insights and SQL Data Insights Pro are the primary commercial examples discussed here; other database and vector systems solve related but not identical problems.
Conclusion: Move Intelligence Closer to the Data When the Boundary Justifies It
The strongest case for an LDM is not that it makes every database query intelligent. It is that some organizations need semantic discovery over controlled relational data without creating an unnecessary application-level copy of every source record.
That architectural benefit must be weighed against product scope, training and query costs, model governance, evaluation difficulty, refresh behavior, and the need for explanations or hard guarantees. An LDM is most useful when it produces auditable ranked candidates or hypotheses that SQL, business rules, and domain experts can inspect.
Start with one business question, define a baseline, profile the candidate table or view, run a controlled evaluation, and document the data boundary. If the LDM improves the decision without weakening governance, expand it. If it cannot beat a simple baseline or its outputs cannot be explained and controlled, do not deploy it merely because semantic search is fashionable.
One more acronym for the vocabulary: LDM. Large Database Model. The one that finally reaches the other 99%.
Verification note: The 1% / 99% enterprise-data split, the 2022 SQL Data Insights launch, the March 2026 SQL Data Insights Pro release, the AI_SIMILARITY / AI_SEMANTIC_CLUSTER / AI_ANALOGY functions, the toffee-almond-to-oatmeal result, and the embedding-limitations findings are all sourced to linked primary or peer-reviewed material. The 32–40% IT-budget figure is presented explicitly as an IBM estimate because no independent audit of it is publicly available. No statistic in this article was invented.
❓ FAQ
What does LDM stand for in AI?
LDM stands for Large Database Model. In this article, the term primarily refers to a database-embedding approach such as IBM SQL Data Insights, where a selected table or view is preprocessed and used to learn vector representations of relational values for semantic queries. Other implementations may use different designs.
How is an LDM different from an LLM?
An LLM is designed primarily to model and generate language from large text or multimodal training data. An LDM-style system learns representations from selected relational data and returns outputs such as similarity scores, ranked records, clusters, or related entities. It does not automatically generate a natural-language explanation or replace an LLM.
Do I need a data scientist to use an LDM?
A supported LDM product may expose semantic queries through SQL, but query access does not remove the need for technical and domain expertise during setup. Teams still need to choose the table or view, classify columns, control leakage, evaluate results, govern access, and monitor model refreshes.
Why are numeric values binned or clustered before training?
Continuous and high-cardinality numeric values can be too sparse to produce stable representations. A product may therefore cluster or bucket numeric values during preprocessing. The exact algorithm and configuration are implementation-specific, so verify the behavior in the documentation for the product and version you use.
Can an LDM query be combined with a normal WHERE clause?
IBM documents SQL Data Insights functions that can be used in Db2 semantic queries alongside conventional SQL predicates. The exact syntax, supported arguments, and execution behavior depend on the Db2 and SQL Data Insights version. Test the query and review the execution plan before using it in a latency-sensitive workflow.
Is my data safe if I use an LDM?
An in-database design can reduce application-level copies of source rows, but it is not a universal security guarantee. Model artifacts, training data, logs, backups, exports, query results, and administrator access still require governance. Treat embeddings and trained models as derived data and review access, retention, encryption, and privacy risks.
What are LDMs bad at?
LDMs are not a substitute for relational constraints, causal analysis, calibrated supervised prediction, or natural-language explanation. Research on relational-table embeddings has found that functional dependencies may not be reflected reliably and that some models can be sensitive to table structure. Use LDMs for discovery and ranking, then validate important results with deterministic rules, baselines, and domain review.
Which products implement this approach today?
IBM SQL Data Insights and SQL Data Insights Pro are the primary commercial examples discussed in this article. IBM documents the built-in functions AI_ANALOGY, AI_COMMONALITY, AI_SEMANTIC_CLUSTER, and AI_SIMILARITY for SQL Data Insights. SQL Data Insights Pro is designed for Db2 for z/OS on IBM Z and LinuxONE and extends the documented workflow to structured and unstructured data with full or incremental retraining options. Other databases and platforms offer related capabilities such as vector search, semantic retrieval, or in-database AI, but those features should not automatically be labeled LDMs because their training and execution designs may differ.
📋 Article Timeline & History
Successfully updated on August 18, 2026 with the latest details.
This article was originally published on August 8, 2026.
Was this article helpful?
[…] Large Database Models (LDM): Why Your AI Doesn’t Know 99% of What Your Company Knows […]