MDB-Link: Hierarchical Schema Linking for Multi-Database Text-to-SQL

Traditional Text-to-SQL research and benchmarks assume a known target database, overlooking settings in which a query must be routed within a large, heterogeneous database collection. The paper studies schema linking in a multi-database setting, where the system must first locate the target database and then construct a compact, SQL-relevant schema for generation.

This task has a hierarchical structure: a system must first localize a database from a large collection, then identify the relevant tables, and finally ground the columns needed for SQL generation. These decisions are interdependent: choosing the wrong database invalidates all downstream selections, while omitting a bridge table or join key can prevent correct SQL generation even when other selected columns are semantically related.

The authors propose MDB-Link, a hierarchical framework that uses question-relevant column evidence from a global index to localize candidate databases and then narrows the predicted database through table selection and column grounding.

MDB-Link comprises two stages:

1. Offline vector index construction: it normalizes and serializes column-wise records from all candidate databases, embeds them, and stores their vectors and metadata in a persistent local vector database with a searchable index.

2. Online hierarchical schema linking: proceeds through three modules—database localization, table selection, and column-wise grounding.

MDB-Link uses "an adaptive two-round strategy: it first retrieves column evidence across the complete database collection to reduce the risk of missing the target, and then progressively narrows the candidate set so that LLM reranking is applied only to the retained databases."

The algorithm:

• Encodes the question once to obtain a query vector

• Retrieves highly relevant columns (HRCs) from a global column-wise vector index

• Groups column evidence by database and applies support-based pruning

• Uses LLM reranking based on the normalized probability of the positive label (yes/no) for database relevance scoring

Given the predicted database D̂, question q, and optional hint h, table selection predicts a valid set of tables predicted as relevant T̂ ⊆ TD̂. This step is needed because database localization identifies only the target database, which may still contain many irrelevant tables.

This stage identifies the specific columns required to construct the SQL query, including columns used for projection, filtering, aggregation, ordering, and joins. The LLM returns a table-to-column mapping, with all names constrained to the displayed schema context and join keys included only when needed.

Database reranking, table selection, and column-wise grounding follow a common budget-aware schema context construction strategy. The token budget applies to the complete prompt, including the prompt template, question, optional hint, and schema context, rather than to the schema context alone.

Two procedures are used:

• Full-schema-first renderer (for database reranking and table selection): "first attempts to include every table and column of the current database. If the prompt exceeds the input-token budget, it ranks columns by their cosine similarity to q using the global column-wise vector index, retains the highest-ranked column from each table, prioritizes primary- and foreign-key columns, and adds further columns across tables within the budget."

• Selected-table context procedure (for column-wise grounding): first attempts to include every column of the selected tables and otherwise reuses the table-selection records retained for those tables when available.

The paper's contributions are:

1. We formulate multi-database schema linking as a hierarchical grounding problem that requires progressive database-, table-, and column-wise schema-space reduction before SQL generation.

2. "We propose MDB-Link, a hierarchical multi-database schema linking framework that integrates database localization based on global column evidence retrieval, LLM logits-based database reranking, table selection, column-wise grounding, and budget-aware schema context construction."

3. We introduce an evaluation protocol that jointly considers target-database accuracy, column exact match and recall, schema compactness, inference cost, and downstream SQL utility.

The method is evaluated on three multi-database Text-to-SQL benchmarks:

• MMQA: 3,128 samples, 158 databases, 808 tables, 4,220 columns

• Spider2-Snow: 120 samples, 53 databases, 1,938 tables, 102,341 columns

• BIRD (dev): 1,534 samples, 11 databases, 75 tables, 798 columns

Four baselines are compared:

• LinkAlign: a representative and scalable multi-database schema-linking baseline that adopts iterative alignment and filtering

• AutoLink: a state-of-the-art schema-linking method that expands candidate schemas through iterative exploration and an agentic strategy

• Single-Prompt: uses direct LLM prompting without MDB-Link's hierarchical reduction

• Dense Retrieval: an embedding-based retrieval baseline that ranks columns by cosine similarity

• Qwen3-Embedding-0.6B for vector index construction

• Qwen2.5-14B-Instruct and Ministral-3-14B-Instruct for LLM-based modules

• Spider-Agent with Qwen3-Coder-30B-A3B-Instruct for downstream SQL generation

Against LinkAlign under the same backbone, MDB-Link improves LA in every comparison. EM also improves except on Spider2-Snow with Ministral-3-14B, where it decreases from 5.00 to 1.67 even as LA and recall increase.

Key results with Qwen2.5-14B:

• MMQA: EM improves from 16.88 to 51.41; LA from 87.40 to 90.54

• Spider2-Snow: EM from 2.50 to 9.17; LA from 50.00 to 65.00

• BIRD-dev: EM from 12.52 to 38.01; LA reaches 98.89

AutoLink obtains the highest recall but returns 9.5–24.9× more columns than MDB-Link. The paper notes that the predicted schema from AutoLink includes a large ratio of irrelevant columns, which requires a more powerful downstream generation method.

Under Qwen2.5-14B, MDB-Link is faster than LinkAlign and AutoLink on every dataset. On Spider2-Snow, MDB-Link uses more tokens but reduces the average runtime from 409.72 to 369.17 seconds while improving LA, EM, and Recall.

With fixed Spider-Agent settings:

• Spider2-Snow: MDB-Link achieves EX of 8.30 vs. 7.50 for both LinkAlign and AutoLink, while running faster than either

• MMQA: EX improves from 55.40 (LinkAlign) to 63.04; AutoLink attains 69.18 but consumes more tokens

• BIRD-dev: EX improves from 50.00 (LinkAlign) to 55.35; AutoLink achieves 57.69 but uses much fewer tokens (6,077 vs 12,824)

Two ablations are performed:

1. w/o DB reranking: removes the LLM-based database reranker and takes the database that has the maximum columns in HRC as the predicted database

2. w/o table selection: removes the intermediate table-selection stage and grounds columns directly over a budget-aware schema context of the predicted database

Results on Spider2-Snow with Qwen2.5-14B:

• Removing database reranking: reduces LA by 12.50 points, EM by 3.34 points, and Recall by 15.32 points

• Removing table selection: leaves LA unchanged... but lowers EM by 1.67 points and Recall by 10.51 points

The paper concludes: The two modules play complementary roles: database reranking determines where to search, while table selection narrows the within-database search space for more reliable column grounding.

MDB-Link reframes multi-database schema linking as a hierarchical reduction problem rather than flat retrieval over all columns. The paper concludes that multi-database schema linking should jointly optimize correctness, compactness, and downstream SQL utility rather than maximize column recall alone.

The paper acknowledges: datasets containing larger and more complex schemas are still a challenge for schema linking and text-to-SQL. Additionally, "MDB-Link also relies on available schema metadata, including names, descriptions, sample values, and key relations, together with a persistent vector index. In real deployments, such metadata may be incomplete, noisy, or outdated, while changes to database schemas may require the index to be updated. Robustness under these conditions has not yet been systematically evaluated."

Based on the paper, here are the specific improvements I can make to AI systems:

Improvement: Implement a progressive three-stage filtering pipeline (database → table → column) instead of flat retrieval over all columns.

Capability: The AI system can efficiently handle queries across large database collections (e.g., 100,000+ columns) by first localizing the target database, then narrowing to relevant tables, and finally grounding specific columns—reducing search space by orders of magnitude while maintaining accuracy.

Improvement: Use global column evidence retrieval to generate candidate databases, then apply LLM reranking based on normalized probability scores from yes/no classification logits.

Capability: The system can balance recall and precision in database selection—avoiding premature elimination of the correct database while focusing expensive LLM computation only on plausible candidates, improving both accuracy and inference speed.

Improvement: Implement token-budget-aware rendering that prioritizes columns by cosine similarity to the query, with mandatory inclusion of primary/foreign keys and at least one column per table.

Capability: The AI system can generate SQL from schemas that exceed model context windows by intelligently selecting the most relevant schema information, maintaining performance even with very large databases (e.g., 102,341 columns in Spider2-Snow).

Improvement: Optimize schema linking not just for column recall but for downstream SQL execution accuracy, schema compactness, and inference cost simultaneously.

Capability: The system produces minimal yet sufficient schemas that improve end-to-end SQL generation performance (e.g., 8.30% execution accuracy on Spider2-Snow vs 7.50% for baselines) while reducing token consumption and runtime.

Improvement: Structure the system so database reranking and table selection play distinct, complementary roles—reranking determines search direction, table selection narrows within-database space.

Capability: The AI can degrade gracefully when one component fails; removing reranking costs 12.50% localization accuracy, while removing table selection costs 10.51% recall, allowing modular improvements and targeted debugging.

Improvement: Ground columns specifically for SQL operations (projection, filtering, aggregation, ordering, joins) with join keys included only when necessary.

Capability: The system generates more accurate SQL by explicitly identifying which columns serve which SQL roles, reducing errors from missing join conditions or including unnecessary columns that confuse downstream generation.

Improvement: Normalize and serialize column-wise records uniformly across heterogeneous databases before embedding, enabling consistent vector-based retrieval.

Capability: The AI system can handle diverse database schemas (from 11 to 158 databases) without retraining, generalizing across domains and schema styles while maintaining high localization accuracy (98.89% on BIRD-dev).

Improvement: Dynamically allocate computational resources based on database collection size—using dense retrieval for initial filtering and LLM reranking only for retained candidates.

Capability: The system achieves faster inference than baselines (369 seconds vs 410 seconds on Spider2-Snow) while improving accuracy, making it practical for real-time multi-database query routing in production environments.

Traditional Text-to-SQL research and benchmarks assume a known target database, overlooking settings in which a query must be routed within a large, heterogeneous database collection. We therefore study schema linking in a multi-database setting, where the system must first locate the target database and then construct a compact, SQL-relevant schema for generation. We propose MDB-Link, a hierarchical schema-linking framework that retrieves question-relevant columns from a global index, aggregates retrieval evidence to shortlist databases, and uses a budget-aware large language model (LLM) for database reranking, table selection, and column grounding. With Qwen2.5-14B, MDB-Link outperforms LinkAlign on MMQA, Spider2-Snow, and BIRD-dev in database localization and column selection while producing schema subsets close in size to the gold schemas. Exact match improves from 16.88 to 51.41 on MMQA, 2.50 to 9.17 on Spider2-Snow, and 12.52 to 38.01 on BIRD-dev. MDB-Link also runs faster than LinkAlign and AutoLink, demonstrating the effectiveness of hierarchical schema reduction for downstream SQL generation.