Modern data applications increasingly involve heterogeneous data managed in different models and stored across disparate database engines, often deployed as separate installs. Limited research has addressed cross-model query processing in federated environments. This paper takes a step toward bridging this gap by: (1) formally defining a class of cross-model join queries between a graph store and a relational store by proposing a unified algebra; (2) introducing one real-world benchmark and four semi-synthetic benchmarks to evaluate such queries; and (3) proposing a lightweight middleware, MICRO, for efficient query execution. At the core of MICRO is CMLero, a learning-to-rank-based query optimizer that selects efficient execution plans without requiring exact cost estimation. By avoiding the need to materialize or convert all data into a single model, which is often infeasible due to third-party data control or cost, MICRO enables native querying across heterogeneous systems. Experimental results on the benchmark workloads demonstrate that MICRO outperforms the state-of-the-art federated relational system XDB by up to 2.1x in total runtime across the full test set. On the 93 test queries of real-world benchmark, 14 queries achieve over 100 speedup, including 4 queries with more than 100x speedup; however, 4 queries experienced slowdowns of over 5 seconds, highlighting opportunities for future improvement of MICRO. Further comparisons show that CMLero consistently outperforms rule-based and regression-based optimizers, highlighting the advantage of learning-to-rank in complex cross-model optimization.
Figures & tables
Fig. 1 : Example cross-models workload
Fig. 2 : System architecture for MICRO
Operation
Notation
Description
Join
r1⋈r2
Joins two relations r1 and r2 on their common attributes.
Projection
πa1,a2,…(r)
Extracts specified attributes (columns) from a relation r .
Selection
σcondition(r)
Filters tuples from relation r that satisfy a given condition.
TABLE I : Relational algebra operators
Operation
Notation
Schema
Relation Analogous
Selection
γcondition(p)
sch(p)
Projection
ωx1,x2,⋯(r)
⟨x1,x2,⋯⟩
Join
p1⊗p2
sch(p1)∥(sch(p2)∖sch(p1))
Graph Extension
Get-vertices
O(v:L)
⟨v⟩
Expansion
↕v1v2:L[:T](p)
sch(p)∥⟨v2⟩
↕v1v2:L+[:T](p)
sch(p)∥⟨v2⟩
TABLE II : Relational graph operators
Operation
Notation
Output and Schema
Relation-Graph Join
r⋈RGp
graph relation, sch(r)∥(sch(r)∖sch(p))
Graph-Relation Join
p⋈GRr
relation, sch(p)∥(sch(p)∖sch(r))
TABLE III : Cross-model Join Operators
Fig. 3 : (A) An example plan for motivated workload (B) Plan explorer framework; (C) Candidate plans for motivated workload.
Fig. 4 : CMLero: Learned comparator model structure.
Label
Node Properties
#Nodes
Author
id , name , works_count , cited_by_count
3,294,820
Work
id , name , year , type , cited_by_count
8,969,495
Institution
id , name , ror , works_count , cited_by_count
112,271
Field
id , name
10
Subfield
id , name
89
Topic
id , name , works_count , cited_by_count
1,571
TABLE IV: Summary of OpenAlex node types and properties
Relationship
Source Node
Target Node
#Relationships
WORK_AT
Author
Institution
30,573,987
CHILD_OF
Institution
Institution
22,060
CREATED_BY
Work
Author
16,244,003
CREATED_BY
Work
Institution
13,472,802
RELATED_TO
Work
Work
15,800,754
ABOUT
Work
Topic
22,171,963
TABLE V: Summary of some OpenAlex relationship types
Relation
Schema
#Rows
patent
id , year , country , issue_date , title
124,110
pub_cited
publication_name , patent_ids
699,104
inventors
name , patent_ids
210,573
institution
name , ror , patent_ids
5,460
maingroup
astj_topic_id , symbol , patent_ids , ⋯
418
subclass
astj_subfield_id , symbol , patent_ids , ⋯
82
TABLE VI: USPTO relational tables and schemas
Node Label. Property
Relation. Column
Author. name
inventors. name
Work. name
pub_cited. publication_name
Institution. ror
institution. ror
Field. id
class. astj_field_id
Subfield. id
subclass. astj_subfield_id
Topic. id
maingroup. astj_topic_id
TABLE VII: Entity matching for nodes and relational columns
Tag
TagClass
Comment
Forum
Person
Post
Country
City
Company
University
SF-1
16,080
71
1,739,438
100,827
10,295
1,121,226
111
1,343
1,575
6,380
SF-10
16,080
71
18,196,074
667,545
68,673
8,273,491
111
1,343
1,575
6,380
T1
50K, 0.5
1K, 0.8
1M, 0.001
500K, 0.05
50K, 0.3
1M, 0.001
5K, 0.8
5K, 0.8
10K, 0.8
10K, 0.8
T2
100K, 0.1
1K, 0.8
1M, 0.0001
100K, 0.1
50K, 0.3
1M, 0.0001
5K, 0.5
5K, 0.5
50K, 1
50K, 1
TABLE VIII : Statistics of CM-LDBC datasets (It shows Nl for graph nodes and Sl,TRl for relations)
Fig. 5 : (A) Total runtime of all test queries across two benchmarks and five methods; (B) Total runtime of variable-length queries across two benchmarks and five methods; (C) Per-query runtime for XDB and CMLero and highlighted queries with time difference larger than 5 secs.
Fig. 6 : Runtime comparison of pruned vs. retained plans.
OpenAlex-USPTO
SF10-T1
# plans
3192
4524
# pruned plans
13977
21411
collection time
7 hr 15 min
15 hr 20 min
TABLE IX : Training data collection stats.
Data
System
Top-3-HR
AvgQ
Q90
Q95
SF1-T1
Baseline-TS
0.66
7.67
3.54
34.93
Baseline-FVN
0.20
18.96
10.07
24.04
Baseline-RLM
0.67
5.13
2.74
3.54
CMLero
0.82
1.19
1.52
1.65
SF1-T2
Baseline-TS
0.40
8.31
4.72
42.59
Baseline-FVN
0.17
17.42
9.64
25.50
TABLE X : Optimizer comparison on CM-LDBC
Fig. 7 : (A) Runtime of all test queries on SF10-T1 benchmark in distributed environment; (B) Runtime of all test queries on SF10-T1 with different training sizes.
Joining heterogeneous tables requires different forms of correspondence, including exact agreement, syntactic transformation, semantic similarity, and entity-level matching. The appropriate join method is often unknown in advance, while running every candidate method incurs unnecessary cost. We introduce MetaJoin, a label-free framework for adaptive join selection. MetaJoin uses input evidence to choose an initial specialist, then uses specialist-specific output evidence to determine whether that result should be retained, compared with an alternative, escalated, or repaired. This allows join selection to adapt after execution rather than committing to a one-shot routing decision. We also introduce MNN Join, a transformation specialist that searches for string transformations by maximizing mutual-nearest-neighbor coverage between two unaligned columns and uses the same reciprocal structure to validate its output. We evaluate MetaJoin on 670 datasets from six benchmarks. It achieves 0.817 macro row-F1, slightly exceeding a benchmark-level oracle that is given the best standalone specialist for each benchmark (0.812), and outperforms label-free selection policies built from the same specialist portfolio by more than 0.13. Across the 609 datasets in the four transformation-dominant benchmarks, MNN Join outperforms every evaluated transformation baseline. Finally, MetaJoin's accuracy varies by only 0.015 as the controller backbone ranges from 3B to 14B parameters, showing that output validation and repair substantially reduce dependence on the initial routing decision.
Retrieving the right tables is a prerequisite for Text-to-SQL over realistic databases. Dense table retrievers rank schema elements independently, but this ignores a key source of evidence: some required tables are not mentioned in the question and become identifiable only through their join relationships to already relevant tables. We introduce JOINGR, a join-aware table retrieval method that treats the database join graph as the retrieval space. Columns are represented as graph nodes, while intra-table and foreign-key relationships are represented as typed edges. Given a question, JOINGR selects semantically similar anchor tables, traverses join edges with a query-conditioned scorer, and aggregates the resulting edge deposits into table scores. The scorer is a lightweight MLP on top of frozen query, node, and edge embeddings, trained with a pairwise margin loss over gold tables. On BIRD and Spider datasets, JOINGR is competitive with the strongest retrieval baselines. On BEAVER, a challenging enterprise benchmark with multi-hop table requirements, JOINGR substantially improves recall over dense retrieval and re-ranking baselines. Cross-domain experiments show that the learned scorer transfers across benchmarks, indicating that the method captures reusable joingraph traversal behavior.
Sandipan De, Abhijit Chakraborty, Sambaran Bandyopadhyay +1
A durable assumption holds that graph analytics requires a purpose-built graph engine, and that relational systems are ill-suited to connected data. We argue the opposite for the workloads enterprises actually run. A columnar relational engine fronted by a graph query language matches or exceeds native graph engines on analytical graph queries, and - decisively - scales past the point where in-memory graph engines fail. We further argue that the node/edge property graph is not a more faithful model of connected data but a re-encoding of relationships that already exist explicitly in relational tables; reconstructing them at query time is pure overhead. We present ClickGraph and its Databricks-dialect sibling DeltaGraph, systems that translate Cypher directly onto the native relational schema - the tables, columns, and foreign keys as they already exist - and execute in place on ClickHouse, Databricks, or in-process on lakehouse files, with no import and no separate cluster. Because the output is ordinary SQL, an underperforming query is an open optimization surface: it can be rewritten, and the engine itself extended. We support the argument with a peer system's own published benchmark, in which a columnar engine outruns Neo4j by two-to-four orders of magnitude, and with reproducible measurements across the LDBC Social Network Benchmark suite.