InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation

Aadi Patwardhan; Andrei Ilinescu; Rihan Hai

REVIEW 5 major objections 5 minor 37 references

InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation

T0 review · 5 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read InferQ is a benchmark that compiles general quantum circuits into SQL workloads, shows relational database systems beat Qiskit Aer on peak memory for more than half of 7,705 circuits, and trains lightweight models that predict the better…

desk verdict InferQ is a genuine, reusable benchmark with a serious correctness gap: the emitted SQL is never validated against exact statevector simulation, so the headline numbers rest on an assumption until that check is added. read the letter →

arxiv 2607.29134 v2 pith:RN3U2ACN submitted 2026-07-31 quant-ph cs.AIcs.DB

Andrei Ilinescu , Aadi Patwardhan , Rihan Hai This is my paper · ORCID

classification quant-phcs.AIcs.DB

keywords quantumcircuitsimulationSQLworkloadgenerationrelationaldatabasebenchmarkingtensorcontractionjoinslearnedsimulatorselectionfeatureextractioncompositionaltemplates

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper is trying to establish that SQL-based quantum circuit simulation is a general, measurable regime rather than a curiosity limited to a few structured circuits. To do this, it builds InferQ, a benchmark that assembles circuits from quantum-primitive templates, emits each simulation as an RDBMS-ready SQL workload, and attaches static, graph, SQL, and dynamic features to every instance. On a 7,705-circuit sample, the RDBMS backends achieve lower peak memory than Qiskit Aer on more than half of the circuits, and they complete exact simulation of 40–45-qubit sparse circuits that exceed the in-memory limits of a statevector simulator. Using InferQ's features, simple machine-learning models predict when the database engine will win, with the best models reaching 95.6% accuracy for runtime routing and 97.4% for memory routing. If the claim holds, it turns quantum circuit simulation into a tractable database research problem with real workloads, reproducible data, and concrete optimization targets.

What carries the argument

The load-bearing mechanism is the compilation of a quantum circuit into a single SQL statement whose CTE chain encodes each tensor contraction as a join followed by an aggregate, following the einsum-to-SQL translation [5] and the SQL generation implementation of [11]. InferQ wraps this translation in a Markov-style template selection process: feasibility masking removes impossible successors, and synergy rules reweight the candidate distribution so that generated circuits follow realistic algorithm pipelines such as state preparation followed by Hamiltonian simulation followed by phase estimation. Around the generated circuits, InferQ computes four feature groups — static circuit metrics, qubit-interaction-graph properties, SQL abstract-syntax-tree statistics, and dynamic entropy/sparsity measures — and these features feed lightweight linear and tree-based classifiers that decide whether an RDBMS or a conventional simulator will be faster or more memory-efficient.

What would settle it

Run any of the generated circuits through both the emitted SQL on an RDBMS and an independent exact statevector simulator, then compare the final amplitude vectors entry by entry; a mismatch on any circuit would invalidate the runtime, memory, and routing labels derived from the SQL execution.

Watch

Extended reading notes

Core claim

The paper's central claim is that exposing quantum circuit simulation as join-and-aggregate SQL makes relational database systems competitive simulation backends, especially for peak memory, across a broad and general class of compositional circuits. InferQ generates circuits by composing parameterized subcircuit templates under history-dependent synergy rules, then translates each circuit into a chain of SQL common table expressions that perform tensor contractions as joins followed by aggregates. In the evaluation, SQLite achieves the lowest peak memory on 66.7% of 162 circuits and the RDBMS backends collectively win on peak memory on 50.6% of the 7,705-circuit dataset, while Qiskit Aer still wins on runtime for most circuits. The paper also shows that features extracted from the circuit and its SQL predict the winning backend accurately enough to support a lightweight learned routing policy, and that for very large sparse circuits the database backends finish exact simulation out of core where an in-memory simulator fails.

Load-bearing premise

The generated SQL queries are assumed to compute exactly the same quantum state as Qiskit Aer's exact simulator, but the paper does not yet verify that agreement and instead lists correctness checks as future work.

Editorial extensions

If this is right

Database researchers can treat each simulation as a query-shape workload, since the emitted CTE chain exposes join order, aggregation, and materialization choices to standard query-optimizer research.
For large sparse circuits beyond 30 qubits, RDBMS backends complete exact simulation by spilling to disk where an in-memory statevector simulator cannot, making out-of-core execution and spill-aware planning concrete optimization targets.
Lightweight models trained on InferQ features make learned routing practical: inference takes about 14 ms per batch, so a simulator front end could decide the backend before the full simulation runs.
Cheap estimators trained on static, graph, and SQL features predict Shannon entropy (R² ≈ 0.89) and sparsity bands (about 77% classification accuracy) without running the exponential-cost simulation.
The pipeline can ingest circuits from established benchmark suites such as SupermarQ, MQT Bench, and QASM Bench, so the same SQL generation and feature extraction applies to named external circuits as well as generated templates.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper's strongest unstated consequence is that validating the SQL translation against an exact simulator would turn the entire 202,975-circuit dataset into ground truth for query-optimization research; until that validation exists, every runtime, memory, and routing label inherits the risk that some SQL executions compute a different state.
The routing accuracies likely reflect the generator's template distribution, so a sharper test would be to train on InferQ circuits and evaluate on external suites, which the ingestion pipeline already enables.
The finding that Pauli gate count predicts sparsity better than qubit count suggests gate mix is the controllable generator knob for producing memory-stress workloads, which a benchmark maintainer could exploit to target DBMS spill behavior.
If CTE materialization is pushed further, intermediate relations become first-class physical-design objects; indexes and partitioning on contraction intermediates could be benchmarked as a systematic extension, a direction the paper sketches but does not claim as a result.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Punchline: InferQ is a substantial and largely well-built benchmark artifact, but the missing end-to-end correctness check on the emitted SQL is the load-bearing gap that must be closed before the benchmark's numbers carry full weight.

What's actually new: This is the first benchmark that systematically turns quantum circuit simulation into SQL workloads at scale. The compositional generator (Markov template selection with synergy rules) is a real step beyond fixed textbook circuits; the four feature families (static, graph, SQL, dynamic) are clearly specified with complexity bounds; and the released 202,975-circuit dataset plus web viewer and code are genuinely reusable artifacts. The evaluation is extensive: 7,705 circuits, four RDBMS engines against Aer, out-of-core runs to 45 qubits, and ML routing. The ablation is the right check on circularity: with only static/graph/SQL features, XGBoost still gets 93% runtime and 97% memory accuracy, so the routing claim is not purely riding on dynamic features.

Soft spots. The biggest one is correctness of the SQL. Section 3.5 delegates to the implementation in [11], and the paper reports runtime and memory but never verifies that the final amplitudes from the SQL match Qiskit Aer. Without that check on at least a sample of circuits per template, a silent translation bug would invalidate every runtime/memory label and every routing result. The authors list correctness as future work, so they know it is missing, but for a benchmark this is a release-blocker, not a nicety. Second, the abstract's 'RDBMSs achieve better peak memory...' is really 'SQLite achieves...': in the 7,705-circuit set, 3,901 of 3,902 memory wins are SQLite. The plural is misleading. Third, the headline 95.6%/97.4% routing uses dynamic features, which require running a simulation to compute; the pre-simulation story is better served by the ablation numbers. Fourth, minor: no error bars, and the out-of-core advantage is demonstrated on deliberately sparse circuits.

Bottom line: This paper deserves a serious referee. It is a valuable systems contribution with real artifacts and mostly sound experiments. I would send it out with the clear expectation that the authors add an SQL-versus-statevector validation (even on a few hundred circuits across templates), correct the overclaim, and separate the pre-simulation routing results from those that use dynamic features.

Referee Report

5 major / 5 minor

Summary. The paper proposes InferQ, a benchmark that generates compositional quantum circuits from a library of templates, emits each simulation task as an RDBMS-ready SQL workload (join-and-aggregate tensor contractions), and attaches four groups of features (static, graph, SQL, and dynamic). It also releases a dataset of 202,975 circuits with a web-based viewer, and evaluates the emitted SQL on PostgreSQL, SQLite, DuckDB, and Umbra against Qiskit Aer. The experiments claim that RDBMSs have lower peak memory than Qiskit Aer on more than half of the 7,705-circuit sample, and that lightweight learned routers using InferQ features achieve 95.6% accuracy for runtime and 97.4% for memory. Additional experiments cover out-of-core execution on large sparse circuits and learned estimators for entropy and sparsity.

Significance. If the SQL workloads are correct, InferQ fills a genuine gap: it converts quantum circuit simulation into concrete relational workloads that database researchers can study with standard techniques (query optimization, physical design, spill-aware planning, learned cost models). The paper's strengths include a reproducible seeded generator with provenance records and content-hash keys, an open dataset and code, a web viewer, and an ablation study showing that static/graph/SQL-only features already achieve strong routing accuracy (Table 10). The SQLite memory results and the out-of-core demonstrations are concrete, falsifiable datapoints that could seed future work even if the broadest claims are toned down. However, the benchmark's value depends critically on end-to-end correctness validation of the emitted SQL, which the paper does not currently provide, and several headline claims are stated more generally than the evidence supports.

major comments (5)

[3.5, 7] The paper never validates that the SQL generated by the sql-einsum pipeline reproduces the exact quantum state. Section 3.5 states that the SQL is constructed 'using the implementation in [11]' and that tensor contractions are converted into relational joins as proposed by Blacher et al. [5], but no experiment compares final amplitudes between an RDBMS backend and Qiskit Aer for any generated circuit. Section 7 lists correctness checks as future work, and Appendix F profiles SQLite versus Aer using runtimes, intermediate sizes, and RSS without comparing amplitudes. Since all runtime/memory labels in Figure 1, Tables 8a-8b, and Table 19 are derived from these SQL executions, an error in the translation (e.g., a missing amplitude, an ordering bug in a CTE chain, or an incorrect einsum index) would invalidate every downstream claim. Please add a validation experiment that compares the final statevector or probability distribution of one RDBMS backend against Qiskit Aer's exact statevector method on a stratified sample of the generated circuits (e.g., reporting max absolute error or fidelity per circuit), and include the results in the paper rather than in future work.
[Abstract, 6.2, Table 19] The abstract's claim that 'RDBMSs achieve better peak memory usage than Qiskit Aer on more than 50% of the circuits' is effectively an SQLite-only result: on the 7,705-circuit set, 3,901 of the 3,902 RDBMS memory wins come from SQLite and all 1,101 runtime wins come from SQLite (Table 19). PostgreSQL, DuckDB, and Umbra do not win on runtime on the 162-circuit set, and only Umbra contributes a single memory win on the larger set. The wording should be changed to name SQLite (or to report per-engine win counts), and the 'more than 50%' figure (50.6%) should be presented with its engine breakdown and, ideally, a confidence interval, since a handful of noisy measurements could flip the count.
[4.4, 6.3.3, Tables 8 and 10] The headline routing accuracies of 95.6% (runtime) and 97.4% (memory) are obtained with the full feature set that includes dynamic features (Shannon entropy, von Neumann entropy, sparsity; Section 4.4, Eqs. 9-11), which are computed from the output state and therefore require completing a simulation. This makes the abstract and Section 6.2's characterization of 'predicting when SQL execution is preferable' circular if interpreted as pre-simulation routing. The manuscript should state explicitly in the abstract and in Q2 that the reported headline accuracies use post-simulation dynamic features, and it should present the static/graph/SQL-only accuracies (Table 10 gives 0.93/0.97 for XGBoost; Table 9 gives 0.932/0.866 for SQL-only) as the numbers for a genuinely pre-simulation selector. The ablation in Table 10 is a useful step, but the main text and abstract currently emphasize the more favorable dynamic-feature numbers without this caveat.
[6.1, Appendix F, Table 17] No error bars, confidence intervals, or distribution statistics are reported for any runtime, memory, or ML accuracy result. Section 6.1 states that mean values across five repetitions are used, and Appendix F reports medians such as 2.03 ms vs. 2.82 ms for SQLite versus Aer winners, but no spread or significance test is given. Because the claims depend on aggregate winner counts that can be sensitive to small magnitude differences (e.g., the 50.6% memory-win fraction and the 46/116 runtime split in Table 17), the paper should report dispersion (e.g., min/max or 95% intervals) for the main comparisons, or explicitly note in the text where the differences are within measurement noise.
[Appendix A, Section 6.2 (Q3)] The out-of-core claim that RDBMS backends 'can still complete simulation via out-of-core execution' is demonstrated only on a specially constructed family of sparse Expander circuits (Appendix A, Section I.1): Hadamards are applied to h seed qubits and then only CNOT layers follow, so the state is a uniform superposition over exactly 2^h amplitudes. This is a narrow, near-stabilizer family and does not support the general takeaway (3) in Section 6.2 as worded. Please add a sentence restricting the out-of-core finding to this family (or to sparse/low-support circuits), or extend the evaluation to a more diverse set of out-of-core circuits; otherwise the general phrasing overstates the evidence.

minor comments (5)

[3.5] The dependence of the SQL generator on [11] is described as 'using the implementation' and 'we extended their package,' but the paper does not specify the exact code revision or how the extension was validated; please pin the dependency and describe what was changed.
[Figure 8] The caption 'Spill r(lrg)=+0.46 r(tot)=+0.66' is unclear because the symbol 'r' is used both for Spearman correlation and for a quantity in the plot; please use an explicit label such as 'Spearman rho' and explain the open vs. filled markers in the caption.
[6.4, Section 6.2] Section 6.4 says estimators are trained on 202,975 circuits with dynamic features, while Section 6.2 uses a 7,705-circuit subset with RDBMS labels; the paper should clarify how many of the 202,975 circuits also have full RDBMS runtime/memory labels and whether the dynamic features for the larger set were obtained by simulation on the same hardware.
[Table 19] The 'RDBMS total' row in Table 19 sums wins across engines without accounting for possible ties; please state whether ties are broken or count as wins for both engines.
[4.4, Eq. (10)] Equation (10) defines the von Neumann entropy across a 'cut along a qubit line k', but the notation rho_A^k = Tr_B^k(rho) does not make explicit that the bipartition separates qubit k from all other qubits; please clarify the reduced density matrix definition.

Circularity Check

2 steps flagged · score 4.0 of 10

Partial circularity: the headline routing accuracies use dynamic features that are only available after the simulation completes, and the SQL workload correctness rests on an unvalidated self-cited generator; the static/graph/SQL ablations provide independent non-circular grounding.

fitted input called prediction [Abstract; Section 4.4; Section 6.2, Table 8; Section 6.3.3, Table 10]
"Moreover, using InferQ features, lightweight machine learning models (linear and tree-based models) can accurately predict when SQL execution is preferable (with accuracy up to 95.6% for runtime and 97.4% for memory). ... dynamic features depend on the circuit’s output state and cannot be derived from circuit structure alone."

The headline routing accuracies are obtained with the full feature set that includes dynamic features (Section 4.4, Table 10). The paper states that dynamic features are computed from the saved statevector after simulation has completed. Therefore the claimed 'prediction' of which backend wins in runtime or memory is not available before executing the simulation whose cost is being predicted; it is a post-hoc classification rather than a pre-simulation routing decision. The paper's own ablation without dynamic features (Static + Graph + SQL) still achieves 0.93 runtime and 0.97 memory accuracy, so an independent non-circular routing signal exists, but the headline numbers overstate a forward-looking routing capability.
self citation load bearing [Section 3.5; Section 7; Section 5]
"Once a circuit is generated, we construct an equivalent SQL query using the implementation in [11]. We extended their package by making it a dependency to InferQ. ... InferQ can also be extended from circuit generation to end-to-end validation for quantum algorithm design, covering correctness checks, iterative test–debug cycles, and hardware-aware constraints."

The central artifact of the benchmark, the SQL workload that is supposed to simulate each quantum circuit, is generated by the authors' own prior implementation [11] (and by [21] in the Qiskit-selector experiment). The paper asserts that the SQL query is 'equivalent' to the circuit, but it never validates final amplitudes or measurement probabilities against Qiskit Aer; Section 7 explicitly lists correctness checks as future work. All runtime, memory, spill, and routing labels are computed from this self-cited SQL generator, so the benchmark's validity reduces to an unverified self-citation chain. This is load-bearing because a wrong SQL translation would invalidate every reported comparison and learned label.

full rationale

The core benchmark generation is not circular: the template-based compositional circuit generator, the feature extraction pipeline, and the comparison against Qiskit Aer are independently constructed, and the static/graph/SQL-only ablation gives strong routing accuracy without using post-simulation dynamic features. The two circularity concerns are real but partial. First, the headline routing claim uses dynamic features that require a completed simulation, making that specific 'prediction' post-hoc rather than pre-simulation; the paper's own ablation shows the non-dynamic features carry most of the signal, so the central routing finding does have independent content. Second, the correctness of the emitted SQL workloads relies on the authors' prior implementation [11] without an end-to-end equivalence check in this paper, which is a load-bearing self-citation rather than an independently verified result. The missing SQL-vs-Qiskit amplitude validation is primarily a correctness risk, not a circularity, but it compounds the self-citation concern. Overall, the benchmark and its static-feature results stand on their own, while the headline dynamic-feature routing and unvalidated SQL generator prevent a clean non-circular verdict.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The central claims rest mainly on the correctness of prior SQL-simulation code, the representativeness of the hand-designed template set, and the comparability of performance metrics. The two hand-chosen parameters (beta, tau) affect the generated workload and dynamic features. No new physical entities are introduced.

free parameters (2)

synergy rule weight beta = 2 (example); user-configurable
Eq. 5 in Section 3.2; hand-chosen to bias template transitions, shapes the distribution of generated circuits.
sparsity threshold tau = not specified
Eq. 11 in Section 4.4; determines which amplitudes count as non-zero in dynamic features, but its value is never given.

assumptions (5)

domain assumption The einsum-to-SQL translation (from [5] and [11]) is a correct and faithful representation of quantum circuit simulation.
Invoked in Section 3.5 when constructing SQL workloads; no correctness validation is reported for the generated circuits.
ad hoc to paper The template set (StatePrep, QFT, QPE, GroverIter, etc.) and synergy rules generate circuits representative of real quantum algorithms.
Section 3.2, Table 1; hand-designed, no distributional comparison against real quantum program corpora is provided.
domain assumption Peak memory and runtime measurements across engines are comparable and accurate (e.g., RSS for SQLite vs Aer, spill proxies for DuckDB/SQLite).
Sections 6.1 and Appendix I.2; engines use different metrics (query-level temp bytes vs OS-level I/O proxy), and no calibration is shown.
domain assumption Dynamic features (Shannon/von Neumann entropy, sparsity) are computed from a correct saved statevector.
Section 4.4, Eq. 9-11; depends on the simulator backend (which may be an RDBMS or Qiskit Aer) producing the true state.
standard math Standard quantum mechanical axioms (unitary gates, Born rule, statevector representation) used as background.
Section 2.1; not derived, standard background.

how reviews work

0 comments

Cite this review

Pith. "Pith review of InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation." pith.science (2026). https://pith.science/paper/RN3U2ACN

@misc{pith2026260729134,
  author       = {Pith},
  title        = {Pith review of: InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/RN3U2ACN}},
  note         = {Machine review of arXiv:2607.29134}
}

read the original abstract

Recent work suggests that relational database management systems (RDBMSs) can execute quantum circuit simulation by compiling the simulation into SQL workloads (primarily join-and-aggregate tensor contractions). While early results are promising, they largely focus on a narrow set of highly structured circuits and offer limited support for systematic database research, such as query optimization, physical design, and engine-level evaluation across a broad range of circuits. We present InferQ, a database-oriented benchmark for quantum circuit simulation. InferQ generates general, compositional circuits by assembling subcircuits from a set of circuit templates, emits each simulation task as an RDBMS-ready SQL workload, and extracts circuit and query features (static, graph, SQL, and dynamic) for workload characterization. InferQ also releases a large dataset of 202,975 circuits online, with a web-based viewer to support searching, filtering, and downloading circuits and feature records. In experiments across RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra) and the widely used Qiskit Aer simulator, we find that RDBMSs achieve better peak memory usage than Qiskit Aer on more than 50% of the circuits generated by InferQ. Moreover, using InferQ features, lightweight machine learning models (linear and tree-based models) can accurately predict when SQL execution is preferable (with accuracy up to 95.6% for runtime and 97.4% for memory), enabling data-centric simulator selection and opening the door to principled optimization of SQL-based quantum circuit simulation.

Figures

Figures reproduced from arXiv: 2607.29134 by the authors.

**Figure 1.** Across 7,705 circuits, share of cases where RDBMSs (executing the emitted SQL workload) or Qiskit Aer achieves the lowest runtime and the lowest peak memory. Detailed experimental settings are in Section 6. results further clarify why exposing simulation as database workloads is useful. Running the generated SQL inside DBMSs makes simulation subject to database execution and optimization choices, enabling better me… view at source ↗

**Figure 2.** Quantum gates represented as matrices. |0⟩ 𝐻 |0⟩ |0⟩ [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

Figures from the paper (60 more)

**Figure 2.** Figure 2: Quantum gates represented as matrices. Contributions. We make the following contributions: • We propose InferQ, a benchmark that produces quantum circuit simulation workloads in relational form (SQL), enabling direct evaluation inside RDBMS engines. • We design a temp…

**Figure 3.** Figure 3: GHZ state preparation circuit: it takes the all-zero [PITH_FULL_IMAGE:figures/full_fig_p003_3.png]

**Figure 3.** Figure 3: GHZ state preparation circuit: it takes the all-zero state [PITH_FULL_IMAGE:figures/full_fig_p005_3.png]

**Figure 4.** Figure 4: InferQ benchmark’s quantum circuit generation pipeline, and running example in Section 3.6. Circuit Generation (Section 3) Feature Extraction Simulation Static Graph SQL Dynamic [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 4.** Figure 4: InferQ benchmark’s quantum circuit generation pipeline, and running example in Section 3.6. Equations 4–6 keep the generation process simple: feasibility masking removes disallowed templates that do not fit the current circuit, while synergy rules encourage quantum sub…

**Figure 5.** Figure 5: InferQ feature extraction workflow. Static, graphbased, and SQL-derived features are extracted prior to simulation, whereas dynamic features can only be obtained after the simulation completes. sequence, both the subcircuit structure and the numerical gate parameters…

**Figure 6.** Figure 6: InferQ’s web-based UI for exploring dataset and [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

**Figure 6.** Figure 6: InferQ’s web-based UI for exploring dataset and circuit features. [PITH_FULL_IMAGE:figures/full_fig_p016_6.png]

**Figure 7.** Figure 7: Execution time and memory usage comparison between RDBMSs (SQLite, DuckDB, PostgreSQL, and Umbra) and Qiskit Aer (state vector, stabilizer, matrix product state, density matrix) over 162 circuits generated by InferQ. quantum-state simulation, we use Qiskit 2.0.1 togeth…

**Figure 9.** Figure 9: Runtime versus #qubits. 20 21 22 23 10 KB 100 KB 1 MB 10 MB 100 MB 1.0 GB 10.0 GB Spill (log scale) PostgreSQL 20 21 22 23 DuckDB 20 21 22 23 SQLite Number of qubits Sparse [0, 0.33) Medium [0.33, 0.67) Dense [0.67, 1.0] [PITH_FULL_IMAGE:figures/full_fig_p010_9.png]

**Figure 8.** Figure 8: Out-of-core spill versus intermediate relation sizes. To answer this question, we generated 162 circuits13 using InferQ. For each circuit, we measured wall-clock runtime and peak memory when simulating it with (i) RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra) e…

**Figure 10.** Figure 10: Spill versus #qubits on sampled InferQ circuits. 0.0 0.5 1.0 100 B 1 KB 10 KB 100 KB 1 MB 10 MB 100 MB 1.0 GB CTE size ρ(tot)=+0.71 ρ(lrg)=+0.73 PostgreSQL 0.0 0.5 1.0 ρ(tot)=+0.62 ρ(lrg)=+0.65 DuckDB 0.0 0.5 1.0 ρ(tot)=+0.54 ρ(lrg)=+0.61 SQLite Output density (0=spar…

**Figure 11.** Figure 11: Intermediate CTE sizes versus output density on sampled InferQ circuits. database-oriented studies of SQL-based simulation report strong results on a small set of highly structured circuits (e.g., sparse statepreparation workloads) [6, 13]. Using InferQ, we move beyo…

**Figure 12.** Figure 12: Importance of top 10 InferQ numeric features for [PITH_FULL_IMAGE:figures/full_fig_p012_12.png]

**Figure 11.** Figure 11: Intermediate CTE sizes versus output density on sampled InferQ circuits. models as selectors: logistic regression, linear SVM, Decision Tree, random forest (RF), and XGBoost. For each circuit, we have logged runtime and peak memory for Qiskit Aer and the RDBMS backend…

**Figure 13.** Figure 13: Importance of top 10 InferQ numeric features for [PITH_FULL_IMAGE:figures/full_fig_p012_13.png]

**Figure 12.** Figure 12: Importance of top 10 InferQ numeric features for SVM and XGBoost trained for optimizing execution [PITH_FULL_IMAGE:figures/full_fig_p021_12.png]

**Figure 14.** Figure 14: Predicted vs Actual value for the dynamic feature [PITH_FULL_IMAGE:figures/full_fig_p013_14.png]

**Figure 13.** Figure 13: Importance of top 10 InferQ numeric features for SVM and Random Forest trained for optimizing [PITH_FULL_IMAGE:figures/full_fig_p022_13.png]

**Figure 15.** Figure 15: Distribution of dynamic features over 202k entries [PITH_FULL_IMAGE:figures/full_fig_p013_15.png]

**Figure 14.** Figure 14: Predicted vs Actual value for the dynamic feature RF regression estimators for subset (1000 entries) [PITH_FULL_IMAGE:figures/full_fig_p023_14.png]

**Figure 16.** Figure 16: Confusion matrix with counts and normalization [PITH_FULL_IMAGE:figures/full_fig_p013_16.png]

**Figure 15.** Figure 15: Distribution of dynamic features over 202k entries in InferQ with Dynamic features. [PITH_FULL_IMAGE:figures/full_fig_p023_15.png]

**Figure 17.** Figure 17: Spill volume of RDBMS engines (PostgreSQL, [PITH_FULL_IMAGE:figures/full_fig_p015_17.png]

**Figure 16.** Figure 16: Confusion matrices with counts and normalization for the random forest classifier used for sparsity [PITH_FULL_IMAGE:figures/full_fig_p024_16.png]

**Figure 18.** Figure 18: Runtime of RDBMS engines (PostgreSQL, DuckDB, [PITH_FULL_IMAGE:figures/full_fig_p016_18.png]

**Figure 17.** Figure 17: Spill volume of RDBMS engines (PostgreSQL, DuckDB, SQLite). Filled points ( [PITH_FULL_IMAGE:figures/full_fig_p028_17.png]

**Figure 19.** Figure 19: Runtime versus spill volume for RDBMS engines [PITH_FULL_IMAGE:figures/full_fig_p016_19.png]

**Figure 18.** Figure 18: Runtime of RDBMS engines (PostgreSQL, DuckDB, SQLite). [PITH_FULL_IMAGE:figures/full_fig_p029_18.png]

**Figure 20.** Figure 20: Spill volume with varying numbers of qubits (log scale). [PITH_FULL_IMAGE:figures/full_fig_p017_20.png]

**Figure 19.** Figure 19: Runtime versus spill volume for RDBMS engines (PostgreSQL, DuckDB, SQLite). [PITH_FULL_IMAGE:figures/full_fig_p029_19.png]

**Figure 21.** Figure 21: Maximum and total intermediate CTE sizes against output state sparsity (log scale). [PITH_FULL_IMAGE:figures/full_fig_p017_21.png]

**Figure 20.** Figure 20: Spill volume with varying numbers of qubits (log scale). [PITH_FULL_IMAGE:figures/full_fig_p030_20.png]

**Figure 22.** Figure 22: Execution time versus spill volume for sampled InferQ circuits (log-log). [PITH_FULL_IMAGE:figures/full_fig_p017_22.png]

**Figure 21.** Figure 21: Maximum and total intermediate CTE sizes against output state sparsity (log scale). [PITH_FULL_IMAGE:figures/full_fig_p030_21.png]

**Figure 23.** Figure 23: Additional DB comparison on 11 small InferQ circuits with varying output density. Top row: runtime; bottom row: peak memory. The plots group circuits by qubit count, output-density bin, and gate count. SQL, we made a preliminary SciDB implementation by translating eac…

**Figure 22.** Figure 22: Execution time versus spill volume for sampled InferQ circuits (log-log). [PITH_FULL_IMAGE:figures/full_fig_p030_22.png]

**Figure 24.** Figure 24: Expander circuit structure: Hadamards on [PITH_FULL_IMAGE:figures/full_fig_p023_24.png]

**Figure 25.** Figure 25: Generated-corpus gate mix and depth/width coverage. Color in b indicates the number of circuits in each bin on a [PITH_FULL_IMAGE:figures/full_fig_p025_25.png]

**Figure 24.** Figure 24: Expander circuit structure: Hadamards on [PITH_FULL_IMAGE:figures/full_fig_p040_24.png]

**Figure 26.** Figure 26: Generated-corpus static circuit-feature distributions. Dashed lines mark medians. [PITH_FULL_IMAGE:figures/full_fig_p025_26.png]

**Figure 25.** Figure 25: Generated-corpus gate mix and depth/width coverage. Color in b indicates the number of circuits in [PITH_FULL_IMAGE:figures/full_fig_p042_25.png]

**Figure 27.** Figure 27: Generated-corpus interaction-graph feature distributions. Dashed lines mark medians. [PITH_FULL_IMAGE:figures/full_fig_p026_27.png]

**Figure 26.** Figure 26: Generated-corpus static circuit-feature distributions. Dashed lines mark medians. [PITH_FULL_IMAGE:figures/full_fig_p042_26.png]

**Figure 28.** Figure 28: Importance of various SQL features for SVM and [PITH_FULL_IMAGE:figures/full_fig_p026_28.png]

**Figure 27.** Figure 27: Generated-corpus interaction-graph feature distributions. Dashed lines mark medians. [PITH_FULL_IMAGE:figures/full_fig_p043_27.png]

**Figure 31.** Figure 31: Bar chart displaying the imbalance between the [PITH_FULL_IMAGE:figures/full_fig_p028_31.png]

**Figure 28.** Figure 28: Importance of various SQL features for SVM and XGBoost trained for optimizing execution time. [PITH_FULL_IMAGE:figures/full_fig_p044_28.png]

**Figure 32.** Figure 32: Schema for storing extracted circuit features. [PITH_FULL_IMAGE:figures/full_fig_p029_32.png]

**Figure 29.** Figure 29: Importance of various SQL features for SVM and RF trained for optimizing memory. [PITH_FULL_IMAGE:figures/full_fig_p044_29.png]

**Figure 33.** Figure 33: Confusion matrices, normalised over the true classes, for each model’s performance on the test set. SV = [PITH_FULL_IMAGE:figures/full_fig_p029_33.png]

**Figure 30.** Figure 30: Cumulative execution time versus number of circuits processed. The figure shows cumulative genera [PITH_FULL_IMAGE:figures/full_fig_p045_30.png]

**Figure 31.** Figure 31: Bar chart displaying the imbalance between the classes being the best simulation method for [PITH_FULL_IMAGE:figures/full_fig_p048_31.png]

**Figure 32.** Figure 32: Schema for storing extracted circuit features. [PITH_FULL_IMAGE:figures/full_fig_p048_32.png]

**Figure 33.** Figure 33: Confusion matrices, normalised over the true classes, for each model’s performance on the test set. [PITH_FULL_IMAGE:figures/full_fig_p049_33.png]

Review history (3 revisions) →

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 26 canonical work pages

[11]

Rihan Hai, Shih-Han Hung, Tim Coopmans, Tim Littau, and Floris Geerts. 2025. Quantum Data Management in the NISQ Era.PVLDB18, 6 (2025), 1720–1729

work page 2025
[5]

Mark Blacher, Julien Klaus, Christoph Staudt, Sören Laue, Viktor Leis, and Joachim Giesen. 2023. Efficient and Portable Einstein Summation in SQL.Proceedings of the ACM on Management of Data (PACMMOD)1, 2, Article 121 (jun 2023), 19 pages

work page 2023
[1]

Scott Aaronson and Daniel Gottesman. 2004. Improved simulation of stabilizer circuits.Physical Review A70, 5 (Nov. 2004). doi:10.1103/physreva.70.052328

doi:10.1103/physreva.70.052328 2004
[2]

Daniel S Abrams and Seth Lloyd. 1999. Quantum algorithm providing exponential speed increase for finding eigenvalues and eigenvectors.Physical Review Letters83, 24 (1999), 5162

work page 1999
[3]

Almudever, and Sebastian Feld

Medina Bandic, Carmen G. Almudever, and Sebastian Feld. 2023. Interaction graph-based characterization of quantum benchmarks for improving quantum circuit mapping techniques.Quantum Machine Intelligence5, 2 (Oct. 2023). doi:10.1007/s42484-023-00124-1

doi:10.1007/s42484-023-00124-1 2023
[4]

Profiling quantum circuits for their efficient execution on single- and multi-core architectures

Medina Bandic, Pablo le Henaff, Anabel Ovide, Pau Escofet, Sahar Ben Rached, Santiago Rodrigo, Hans van Someren, Sergi Abadal, Eduard Alarcon, Carmen G. Almudever, and Sebastian Feld. 2024. Profiling quantum circuits for their efficient execution on single- and multi-core architectures. arXiv:2407.12640 [quant-ph] https://arxiv.org/abs/ 2407.12640

work page Pith review arXiv 2024
[6]

Matthias Boehm, Matteo Interlandi, and Chris Jermaine. 2023. Optimizing Tensor Computations: From Applications to Compilation and Runtime Techniques. InCompanion of the 2023 International Conference on Management of Data (SIGMOD). 53–59

work page 2023
[7]

Gilles Brassard, Peter Høyer, Michele Mosca, and Alain Tapp. 2002. Quantum amplitude amplification and estimation. Contemp. Math.305 (2002), 53–74

work page 2002

Show all 37 references

[8]

Lingjiao Chen, Arun Kumar, Jeffrey Naughton, and Jignesh M Patel. 2017. Towards Linear Algebra over Normalized Data.Proceedings of the VLDB Endowment10, 11 (2017)

2017
[9]

Edward Farhi, Jeffrey Goldstone, and Sam Gutmann. 2014. A Quantum Approximate Optimization Algorithm. https: //arxiv.org/abs/1411.4028

2014 arXiv
[10]

András Gilyén, Yuan Su, Guang Hao Low, and Nathan Wiebe. 2019. Quantum singular value transformation and beyond: exponential improvements for quantum matrix arithmetics. InProceedings of the 51st annual ACM SIGACT symposium on theory of computing. 193–204

2019
[12]

Rihan Hai, Shih-Han Hung, Tim Coopmans, Tim Littau, and Floris Geerts. 2025. Quantum Data Management in the NISQ Era: Extended Version.https://arxiv.org/abs/2409.14111

2025 arXiv
[13]

Aram W Harrow, Avinatan Hassidim, and Seth Lloyd. 2009. Quantum Algorithm for Linear Systems of Equations. Physical Review Letters103, 15 (2009), 150502

2009
[14]

Roman Heinrich et al. 2025. How Good are Learned Cost Models, Really? Insights from Query Optimization Tasks. SIGMOD3, 3 (2025), 172:1–172:27. doi:10.1145/3725309

2025 doi
[15]

Javier Martín Hernández and Piet Van Mieghem. 2015. Classification of graph metrics. https://api.semanticscho lar.org/CorpusID:37136216

2015
[16]

IBM Quantum. 2025. Qiskit: Open-Source Quantum Computing Software. https://www.ibm.com/quantum/qiskit. Official IBM Quantum page for Qiskit, the world’s most popular software stack for quantum computing and algorithms research

2025
[17]

Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai. 2026. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation. arXiv:2607.29134 [quant-ph] doi:10.48550/arXiv.2607.29134

2026 doi arXiv
[18]

Ngo, Xuanlong Nguyen, Dan Olteanu, and Maximilian Schleich

Mahmoud Abo Khamis, Hung Q. Ngo, Xuanlong Nguyen, Dan Olteanu, and Maximilian Schleich. 2020. Learning Models Over Relational Data Using Sparse Tensors and Functional Dependencies.ACM Transactions on Database Systems (TODS)45, 2 (2020)

2020
[19]

Viktor Leis, Andrey Gubichev, Atanas Mirchev, Peter Boncz, Alfons Kemper, and Thomas Neumann. 2015. How good are query optimizers, really?Proceedings of the VLDB Endowment9, 3 (2015), 204–215

2015
[20]

Ang Li, Samuel Stein, Sriram Krishnamoorthy, and James Ang. 2022. QASMBench: A Low-level QASM Benchmark Suite for NISQ Evaluation and Simulation. arXiv:2005.13018 [quant-ph]https://arxiv.org/abs/2005.13018

2022 arXiv
[21]

Tim Littau and Rihan Hai. 2025. Qymera: Simulating Quantum Circuits using RDBMS. InCompanion of the 2025 International Conference on Management of Data (SIGMOD/PODS ’25). ACM, 179–182. doi: 10.1145/3722212.3725126

2025
[22]

Shangyu Luo, Dimitrije Jankov, Binhang Yuan, and Chris Jermaine. 2021. Automatic optimization of matrix imple- mentations for distributed machine learning and linear algebra. InProceedings of the 2021 International Conference on Management of Data (SIGMOD). 1222–1234

2021
[23]

Nantia Makrynioti and Vasilis Vassalos. 2019. Declarative Data Analytics: A Survey.IEEE Transactions on Knowledge and Data Engineering (TKDE)33, 6 (2019), 2392–2411. Proc. ACM Manag. Data, Vol. 4, No. 4 (SIGMOD), Article 278. Publication date: September 2026. 278:26 Andrei Ili...

2019
[24]

Markov and Yaoyun Shi

Igor L. Markov and Yaoyun Shi. 2008. Simulating Quantum Computation by Contracting Tensor Networks.SIAM J. Comput.38, 3 (2008), 963–981

2008
[25]

John M Martyn, Zane M Rossi, Andrew K Tan, and Isaac L Chuang. 2021. Grand unification of quantum algorithms. PRX quantum2, 4 (2021), 040203

2021
[26]

2010.Quantum Computation and Quantum Information

Michael A Nielsen and Isaac L Chuang. 2010.Quantum Computation and Quantum Information. Cambridge university press

2010
[27]

Matteo Paganelli, Paolo Sottovia, Kwanghyun Park, Matteo Interlandi, and Francesco Guerra. 2023. Pushing ML Predictions into DBMSs.IEEE Transactions on Knowledge and Data Engineering (TKDE)35, 10 (2023), 10295–10308

2023
[28]

Qiskit Development Team. 2025. Qiskit Aer Documentation. https://qiskit.github.io/qiskit-aer/ . Online documentation for Qiskit Aer, the high-performance quantum circuit simulator with realistic noise models in the Qiskit ecosystem

2025
[29]

Qiskit Development Team. 2025. Running with multiple-GPUs and/or multiple nodes.https://qiskit.github.io /qiskit-aer/howtos/running_gpu.html. Qiskit Aer documentation on distributed GPU and multi-node execution with cache blocking options

2025
[30]

Nils Quetschlich, Lukas Burgholzer, and Robert Wille. 2023. MQT Bench: Benchmarking Software and Design Automation Tools for Quantum Computing.Quantum7 (July 2023), 1062. doi:10.22331/q-2023-07-20-1062

2023 doi
[31]

Wenbo Sun, Qiming Guo, Wenlu Wang, and Rihan Hai. 2025. TranSQL+: Serving Large Language Models with SQL on Low-Resource Hardware.SIGMOD3, 6, Article 371 (Dec. 2025), 27 pages

2025
[32]

Smith, Joshua Viszlai, Xin-Chuan Wu, Nikos Hardavellas, Margaret R

Teague Tomesh, Pranav Gokhale, Victory Omole, Gokul Subramanian Ravi, Kaitlin N. Smith, Joshua Viszlai, Xin-Chuan Wu, Nikos Hardavellas, Margaret R. Martonosi, and Frederic T. Chong. 2022. SupermarQ: A Scalable Quantum Benchmark Suite. arXiv:2202.11045 [quant-ph]https://arxiv....

2022 arXiv
[33]

Ashish Vaswani, Noam Shazeer, Niki Parmar, Jakob Uszkoreit, Llion Jones, Aidan N Gomez, Łukasz Kaiser, and Illia Polosukhin. 2017. Attention is all you need.Advances in neural information processing systems30 (2017)

2017
[34]

Yisu Remy Wang, Shana Hutchison, Jonathan Leang, Bill Howe, and Dan Suciu. 2020. SPORES: sum-product optimiza- tion via relational equality saturation for large scale linear algebra.Proceedings of the VLDB Endowment13, 12 (2020), 1919–1932

2020
[35]

Jiani Yang, Sai Wu, Dongxiang Zhang, Jian Dai, Feifei Li, and Gang Chen. 2023. Rethinking Learned Cost Models: Why Start from Scratch?Proc. ACM Manag. Data1, 4 (2023), 255:1–255:27. doi:10.1145/3626769

2023 doi
[36]

Binhang Yuan, Dimitrije Jankov, Jia Zou, Yuxin Tang, Daniel Bourgeois, and Chris Jermaine. 2021. Tensor relational algebra for distributed machine learning system design.Proceedings of the VLDB Endowment14, 8 (2021)

2021
[37]

generators

Xuanhe Zhou, Chengliang Chai, Guoliang Li, and Ji Sun. 2020. Database Meets Artificial Intelligence: A Survey.IEEE Transactions on Knowledge and Data Engineering (TKDE)(2020). Proc. ACM Manag. Data, Vol. 4, No. 4 (SIGMOD), Article 278. Publication date: September 2026. InferQ:...

2020

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [11]

Rihan Hai, Shih-Han Hung, Tim Coopmans, Tim Littau, and Floris Geerts. 2025. Quantum Data Management in the NISQ Era.PVLDB18, 6 (2025), 1720–1729

work page 2025

[2] [5]

Mark Blacher, Julien Klaus, Christoph Staudt, Sören Laue, Viktor Leis, and Joachim Giesen. 2023. Efficient and Portable Einstein Summation in SQL.Proceedings of the ACM on Management of Data (PACMMOD)1, 2, Article 121 (jun 2023), 19 pages

work page 2023

[3] [1]

Scott Aaronson and Daniel Gottesman. 2004. Improved simulation of stabilizer circuits.Physical Review A70, 5 (Nov. 2004). doi:10.1103/physreva.70.052328

doi:10.1103/physreva.70.052328 2004

[4] [2]

Daniel S Abrams and Seth Lloyd. 1999. Quantum algorithm providing exponential speed increase for finding eigenvalues and eigenvectors.Physical Review Letters83, 24 (1999), 5162

work page 1999

[5] [3]

Almudever, and Sebastian Feld

Medina Bandic, Carmen G. Almudever, and Sebastian Feld. 2023. Interaction graph-based characterization of quantum benchmarks for improving quantum circuit mapping techniques.Quantum Machine Intelligence5, 2 (Oct. 2023). doi:10.1007/s42484-023-00124-1

doi:10.1007/s42484-023-00124-1 2023

[6] [4]

Profiling quantum circuits for their efficient execution on single- and multi-core architectures

Medina Bandic, Pablo le Henaff, Anabel Ovide, Pau Escofet, Sahar Ben Rached, Santiago Rodrigo, Hans van Someren, Sergi Abadal, Eduard Alarcon, Carmen G. Almudever, and Sebastian Feld. 2024. Profiling quantum circuits for their efficient execution on single- and multi-core architectures. arXiv:2407.12640 [quant-ph] https://arxiv.org/abs/ 2407.12640

work page Pith review arXiv 2024

[7] [6]

Matthias Boehm, Matteo Interlandi, and Chris Jermaine. 2023. Optimizing Tensor Computations: From Applications to Compilation and Runtime Techniques. InCompanion of the 2023 International Conference on Management of Data (SIGMOD). 53–59

work page 2023

[8] [7]

Gilles Brassard, Peter Høyer, Michele Mosca, and Alain Tapp. 2002. Quantum amplitude amplification and estimation. Contemp. Math.305 (2002), 53–74

work page 2002