arxiv: 2605.10373 · v1 · submitted 2026-05-11 · 💻 cs.DB · cs.CL

Recognition: no theorem link

Toward Multi-Database Query Reasoning for Text2Cypher

Makbule Gulcin Ozsoy

Authors on Pith no claims yet

Pith reviewed 2026-05-12 04:06 UTC · model grok-4.3

classification 💻 cs.DB cs.CL

keywords Text2Cyphermulti-database reasoninggraph databasesnatural language interfacesdatabase routingquery decompositionresult integrationdistributed databases

0 comments

The pith

Text2Cypher systems must reason over multiple independent graph databases instead of assuming one fixed schema.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

Most Text2Cypher work translates natural language questions into Cypher queries for a single pre-chosen graph database. Real systems, however, store related data across separate databases divided by domain or organization, so one question can require pieces from several sources. The paper therefore argues that future systems need to select the right databases, split the question across them, generate partial queries, and combine the results. It frames this capability as a three-phase process of routing, decomposition, and heterogeneous integration. Without this shift, natural language interfaces stay limited to toy single-database settings.

Core claim

The central claim is that Text2Cypher must move from single-database query generation to multi-database query reasoning, in which the system identifies relevant databases, decomposes a question across them, and integrates partial results from heterogeneous graph sources.

What carries the argument

The three-phase roadmap of database routing, multi-database decomposition, and heterogeneous query reasoning across database types and query languages.

If this is right

Query generation must include an explicit step for choosing which databases contain the needed data.
Questions will be broken into sub-questions that may target different schemas and even different query languages.
Result integration becomes a required final stage after partial queries run.
Natural language interfaces gain applicability to distributed real-world graph environments.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

The same routing-plus-decomposition pattern could extend to other query languages such as SQL or SPARQL.
Benchmarks that explicitly label cross-database questions would be needed to measure progress.
Federated query techniques from database research could supply building blocks for the integration phase.

Load-bearing premise

Relevant information for a user's question is often spread across multiple independent graph databases rather than contained in one.

What would settle it

A collection of natural language questions whose correct answers require data from at least two separate graph databases, together with measurements of whether single-database Text2Cypher systems fail on them while a multi-database routing and integration method succeeds.

Figures

Figures reproduced from arXiv: 2605.10373 by Makbule Gulcin Ozsoy.

**Figure 1.** Figure 1: Example of multi-database query reasoning in a movie production company. Phase 1 uses a single graph database (Movies), Phase 2 combines two graph databases (Movies and Finance), and Phase 3 adds a relational database (Tax), combining Cypher and SQL results. For the Text2Cypher task, to our knowledge, this problem remains largely unexplored. Existing systems assume a single preselected graph database and f… view at source ↗

read the original abstract

Large language models have significantly improved natural language interfaces to databases by translating user questions into executable queries. In particular, Text2Cypher focuses on generating Cypher queries for graph databases, enabling users to access graph data without query language expertise. Most existing Text2Cypher systems assume a single preselected graph database, where queries are generated over a known schema. However, real-world systems are often distributed across multiple independent graph databases organized by domain or system boundaries, where relevant information may span multiple sources. To address this limitation, we propose a shift from single-database query generation to multi-database query reasoning. Instead of assuming a fixed execution context, the system must reason about (i) relevant databases, (ii) how to decompose a question across them, and (iii) how to integrate partial results. We formalize this setting through a three-phase roadmap: database routing, multi-database decomposition, and heterogeneous query reasoning across database types and query languages. This work provides a structured formulation of multi-database reasoning for Text2Cypher and identifies challenges in source selection, query decomposition, and result integration, aiming to support more realistic and scalable natural language interfaces to graph databases.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

This is a short position paper that names the multi-database Text2Cypher problem and sketches three phases but stops at motivation with no algorithms or evidence.

read the letter

The core idea is that Text2Cypher systems should stop assuming one pre-chosen graph database and instead reason about which databases matter, how to split a question across them, and how to combine results. The authors lay out a three-phase roadmap—database routing, multi-database decomposition, and heterogeneous query reasoning—to structure that shift. That framing is the main new element; it turns a practical limitation into a defined setting with named challenges like source selection and result integration. The motivation about real-world data being split across domain-specific graphs is reasonable and worth stating plainly. The paper does a clean job of contrasting the single-DB assumption in existing work with the distributed case. Beyond that, there is little substance. No algorithms are given for any phase, no experiments test whether current single-DB methods break on multi-DB questions, and no formal definitions or examples show what the phases would look like in practice. The abstract and text also skip direct comparison to federated query systems or multi-source SQL work, so it is hard to judge how distinct the roadmap actually is. This paper is mainly for researchers already working on natural-language-to-query translation who want a compact statement of an open problem. A reader looking for concrete methods or results will find almost nothing to use. It could deserve a serious referee at a workshop that accepts vision or position pieces, since the problem setting is clearly stated and the challenges are realistic. For a full conference track I would expect more technical grounding before sending it out. If your group discusses future directions in graph database interfaces, it is worth a quick read to see if the three phases spark follow-up ideas.

Referee Report

1 major / 1 minor

Summary. The paper proposes a shift from single-database Text2Cypher systems (which assume a fixed, preselected graph database and schema) to multi-database query reasoning. It motivates the setting by noting that real-world graph data is often distributed across independent databases, and formalizes the problem via a three-phase roadmap: (i) database routing to identify relevant sources, (ii) multi-database decomposition of the natural-language question, and (iii) heterogeneous query reasoning and result integration across database types and languages. The work identifies open challenges in source selection, decomposition, and integration but presents no algorithms, implementations, or experiments.

Significance. The identification of the multi-database Text2Cypher setting is timely, as distributed graph stores are common in practice. The three-phase roadmap supplies a clear high-level structure and names concrete research challenges, which could usefully guide subsequent work on more realistic NL-to-graph interfaces. Credit is due for explicitly framing the problem beyond the single-database assumption that dominates current literature.

major comments (1)

[Abstract; Roadmap section] The abstract and the section describing the roadmap claim to 'formalize this setting through a three-phase roadmap,' yet the phases are described only at the conceptual level with no formal definitions, input/output specifications, pseudocode, or even high-level algorithmic sketches. This absence is load-bearing because the central contribution is the structured formulation itself; without any operational detail, the roadmap cannot be evaluated for feasibility or used as a basis for implementation.

minor comments (1)

[Abstract] The abstract would benefit from an explicit statement that the paper is a position/roadmap contribution rather than a technical result with validation.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for the positive evaluation of the timeliness of the multi-database Text2Cypher setting and for recognizing the utility of the three-phase roadmap in structuring future research. We respond to the major comment below.

read point-by-point responses

Referee: [Abstract; Roadmap section] The abstract and the section describing the roadmap claim to 'formalize this setting through a three-phase roadmap,' yet the phases are described only at the conceptual level with no formal definitions, input/output specifications, pseudocode, or even high-level algorithmic sketches. This absence is load-bearing because the central contribution is the structured formulation itself; without any operational detail, the roadmap cannot be evaluated for feasibility or used as a basis for implementation.

Authors: We appreciate this observation on the level of detail. The manuscript is a position paper whose central contribution is the identification of the multi-database Text2Cypher setting and its decomposition into three high-level phases (database routing, multi-database decomposition, and heterogeneous query reasoning), together with the explicit enumeration of open challenges in source selection, decomposition, and result integration. The roadmap is deliberately presented at the conceptual level to delineate the problem structure without prescribing particular algorithmic realizations; committing to input/output specifications or pseudocode at this stage would require selecting specific formal models that remain open research questions. We therefore view the current formulation as an appropriate and sufficient formalization for a roadmap that aims to guide subsequent implementation work rather than to deliver an executable system. revision: no

Circularity Check

0 steps flagged

No significant circularity

full rationale

This is a position/roadmap paper that motivates a multi-database Text2Cypher setting and names three high-level phases without any mathematical derivations, equations, fitted parameters, predictions, or self-referential reductions. The central claim is the existence and utility of the proposed setting rather than any derivable technical assertion. No load-bearing steps reduce to inputs by construction, and the paper is self-contained as a forward-looking formulation.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The proposal rests on the domain assumption that real-world graph data is distributed across independent databases and that the key challenges are routing, decomposition, and integration.

axioms (1)

domain assumption Real-world systems are often distributed across multiple independent graph databases organized by domain or system boundaries, where relevant information may span multiple sources.
This premise is stated directly in the abstract as the motivation for the proposed shift.

pith-pipeline@v0.9.0 · 5497 in / 1142 out tokens · 39043 ms · 2026-05-12T04:06:36.723808+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

24 extracted references · 24 canonical work pages

[1]

G. Y. Zhu, W. Shao, X. Zhu, L. Yu, J. Guo, X. Cheng, Text2sql: Pure fine-tuning and pure knowledge distillation, in: NAACL 2025, 2025

work page 2025
[2]

Sennrich, S

K. Sennrich, S. Ahmadi, Conversational lexicography: Querying lexicographic data on knowledge graphs with sparql through natural language, in: Proceedings of the 5th Conference on Language, Data and Knowledge, 2025, pp. 289–300

work page 2025
[3]

M. G. Ozsoy, L. Messallem, J. Besga, G. Minneci, Text2cypher: Bridging natural language and graph databases, in: COLING 2025, 2025

work page 2025
[4]

S. Lyu, L. Ban, Z. Wu, T. Luo, J. Liu, C. Ma, Y. Luo, N. Tang, S. Qi, H. Lin, et al., Text2gql-bench: A text to graph query language benchmark [experiment, analysis & benchmark], arXiv preprint arXiv:2602.11745 (2026)

work page arXiv 2026
[5]

K. Xu, D. Wang, X. Zhang, Q. Zhu, W. Che, Abacus-sql: a text-to-sql system empowering cross- domain and open-domain database retrieval, in: Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 3: System Demonstrations), 2025, pp. 118–128

work page 2025
[6]

Y. Wang, P. Liu, X. Yang, Linkalign: Scalable schema linking for real-world large-scale multi- database text-to-sql, in: Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, 2025, pp. 977–991

work page 2025
[7]

Kosiuk, X

W. Kosiuk, X. Ji, Y. Chung, F. Özcan, M. Hulsebos, Fine-grained table retrieval through the lens of complex queries, arXiv preprint arXiv:2603.07146 (2026)

work page arXiv 2026
[8]

Chung, G

Y. Chung, G. T. Kakkar, Y. Gan, B. Milne, F. Ozcan, Is long context all you need? leveraging llm’s extended context for nl2sql, arXiv preprint arXiv:2501.12372 (2025)

work page arXiv 2025
[9]

Google Cloud, Write queries with gemini assistance, https://cloud.google.com/bigquery/docs/ write-sql-gemini, 2024

work page 2024
[10]

Zhang, D

X. Zhang, D. Wang, L. Dou, Q. Zhu, W. Che, Murre: Multi-hop table retrieval with removal for open-domain text-to-sql, in: Proceedings of the 31st International Conference on Computational Linguistics, 2025, pp. 5789–5806

work page 2025
[11]

J. Zou, D. Fu, S. Chen, X. He, Z. Li, Y. Zhu, J. Han, J. He, Rag over tables: Hierarchical memory index, multi-stage retrieval, and benchmarking, arXiv preprint arXiv:2504.01346 (2025)

work page arXiv 2025
[12]

Bodensohn, C

J.-M. Bodensohn, C. Binnig, Rethinking table retrieval from data lakes, in: Proceedings of the Seventh International Workshop on Exploiting Artificial Intelligence Techniques for Data Management, 2024, pp. 1–5

work page 2024
[13]

F. Luo, H. Lan, H. Luo, Z. Bao, X. Wang, J. S. Culpepper, S. Sadiq, Decomposition-driven multi-table retrieval and reasoning for numerical question answering, arXiv preprint arXiv:2603.07950 (2026)

work page arXiv 2026
[14]

Daviran, D

M. Daviran, D. Rafiei, How far can they map? probing llm capabilities for cross-schema sql gener- ation, https://beyond-sql.github.io/papers/BeyondSQL_2026_Cross_Schema_SQL_Generation.pdf,

work page
[15]

Presented at Beyond SQL Workshop (ICDE 2026)

work page 2026
[16]

J. S. Jan-Micha Bodensohn, C. Binnig, Towards executing sloppy sql queries over tabular data lakes, https://beyond-sql.github.io/papers/BeyondSQL_2026_Executing_Sloppy_SQL_Queries_ over_Tabular_Data_Lakes.pdf, 2026. Presented at Beyond SQL Workshop (ICDE 2026)

work page 2026
[17]

Abramson, Semantic layer: Framework, benefits & use cases (2026 guide), https://qrvey.com/ blog/semantic-layer/, 2026

D. Abramson, Semantic layer: Framework, benefits & use cases (2026 guide), https://qrvey.com/ blog/semantic-layer/, 2026. Accessed: 2026-04-27

work page 2026
[18]

Staff, What is a semantic layer, https://www.databricks.com/blog/what-is-a-semantic-layer,

D. Staff, What is a semantic layer, https://www.databricks.com/blog/what-is-a-semantic-layer,

work page
[19]

Accessed: 2026-04-23

work page 2026
[20]

Fusco, L

G. Fusco, L. Aversano, An approach for semantic integration of heterogeneous data sources, PeerJ Comput. Sci. 6 (2020) e254

work page 2020
[21]

Zhao, Semantic matching across heterogeneous data sources, Communications of the ACM 50 (2007) 45–50

H. Zhao, Semantic matching across heterogeneous data sources, Communications of the ACM 50 (2007) 45–50

work page 2007
[22]

Trajanoska, R

M. Trajanoska, R. Stojanov, D. Trajanov, A multi-agent system for semantic mapping of relational data to knowledge graphs, arXiv preprint arXiv:2511.06455 (2025)

work page arXiv 2025
[23]

List movies released in 2025

A. Rissaki, I. Fountalis, N. Vasiloglou, W. Gatterbauer, Towards agentic schema refinement, arXiv preprint arXiv:2412.07786 (2024). Table 1 Illustrative examples of multi-database query reasoning across the three proposed phases. Phase Question Eval Notes Phase1 "List movies released in 2025"✓ Identified the correct database (Movies) and pro- duced a corr...

work page arXiv 2024
[24]

Juhlin, R

P. Juhlin, R. Hussein, N. Schoch, Towards efficient field service engineering for powertrains via llm-generated knowledge graphs, SGKi 2025: Scaling Knowledge Graphs for Industry Workshop, co-located with SEMANTiCS 2025: International Conference on Semantic Systems (2025). Appendix A. Additional Examples on LLM Behavior We provide additional illustrative ...

work page 2025