Pith. sign in

REVIEW 4 major objections 5 minor 39 references

Simulating quantum circuits as SQL can win on memory for over half of generated circuits, and simple models predict the faster engine up to 95% accuracy.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

T0 review

2026-08-03 13:02 UTC pith:RN3U2ACN

load-bearing objection A genuinely useful benchmark for SQL-based quantum simulation, but the missing SQL correctness check guts the empirical claims until fixed. the 4 major comments →

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

InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation

Andrei Ilinescu , Aadi Patwardhan , Rihan Hai This is my paper
classification quant-ph cs.AIcs.DB
keywords quantum circuit simulationrelational databasesSQL tensor contractionworkload generationbenchmarklearned routingmemory-efficient simulationout-of-core execution
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

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

The paper tries to establish that quantum circuit simulation can be treated as a database benchmarking problem. It builds a generator that assembles circuits from quantum primitives using a history-dependent Markov process, emits each simulation as a chain of SQL join-and-aggregate tensor contractions, and attaches static, graph, SQL, and dynamic features. On roughly 7,700 generated circuits, relational engines match or beat a standard quantum simulator on peak memory in the majority of cases, and simple linear or tree models pick the better backend with up to 95% accuracy for runtime and 97% for memory. If this is right, database techniques—query optimization, indexing, and spill-aware execution—can be brought directly to bear on quantum simulation, and a data-driven selector can route each circuit to the engine that will use least memory.

Core claim

The central claim is that a broad, compositionally generated family of quantum circuits can be expressed as a relational workload—specifically a chain of common table expressions implementing tensor contractions as joins and aggregates—and that this representation is not only executable but systematically useful. Relational engines achieve lower peak memory than a widely used quantum simulator on more than half of the generated circuits, and they can complete sparse 40–45 qubit circuits out of core when exact in-memory state-vector simulation is impossible. The paper further claims that the extracted features make backend choice predictable: a lightweight tree-based router attains 95.3% accu

What carries the argument

The load-bearing mechanism is a template-based, history-dependent circuit generator: it samples a sequence of quantum algorithm primitives (state preparation, Hamiltonian simulation, QFT, QPE, Grover iterations, and similar) with feasibility masking and synergy reweighting, then instantiates and composes the subcircuits. Around it sits the SQL compilation chain, which converts tensor contractions into a CTE chain of join-and-aggregate queries, and a four-part feature extractor (static, graph, SQL, and dynamic) that maps each circuit to a vector used for routing and prediction. The Markov transition model provides scale and diversity; the CTE chain exposes simulation to database query optimiz

Load-bearing premise

The whole evaluation rests on the assumption that the generated SQL actually computes the same state vector as the quantum circuit; the paper delegates this to an external implementation and leaves correctness checks to future work.

What would settle it

Run the emitted SQL for a stratified sample of InferQ circuits, including dense ones, and compare the final state vector against the exact statevector result from a standard quantum simulator; any significant mismatch would mean the runtime and memory measurements are for a different computation.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Database query optimizers can be studied and improved on reproducible quantum-simulation workloads, including index selection, join ordering, and materialization choices.
  • Out-of-core relational execution extends exact simulation to sparse circuits with 40–45 qubits, beyond the reach of dense in-memory state-vector simulators.
  • A lightweight learned router can replace hand-assigned engine choices, with claimed accuracies up to 95.3% for runtime and 97.4% for memory.
  • Dynamic properties like Shannon entropy and sparsity can be estimated without full simulation using static, graph, and SQL features (a tree regressor reaches R-squared about 0.89 for entropy).
  • Forcing CTE materialization can roughly halve runtime on dense circuits under tight memory limits, pointing to a concrete optimizer lever.

Where Pith is reading between the lines

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

  • (Beyond the paper) The reported memory advantage is likely concentrated in the sparse portion of the generated corpus, since the released distribution is heavily sparse; extending the same win to general dense workloads would need explicit evidence.
  • (Beyond the paper) The benchmark's most direct payoff for database research is as a controlled query-optimizer testbed: template-based generation lets one vary sparsity, interaction graph, and contraction order independently.
  • (Beyond the paper) The learned router should be tested on externally sourced benchmark circuits to see whether the 95% accuracy transfers; the paper provides ingestion support but does not evaluate routing transfer.
  • (Beyond the paper) A correctness audit of the emitted SQL is a precondition for trusting every runtime and memory number; without it, the experiments may be timing a different computation.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. InferQ is a benchmark that generates quantum circuits by composing subcircuits from hand-defined templates via a history-dependent Markov process, emits each circuit as an RDBMS-ready SQL workload (a CTE chain of join-and-aggregate tensor contractions), extracts static, graph, SQL, and dynamic features, and releases 202,975 circuits with a web viewer. The experiments compare PostgreSQL, SQLite, DuckDB, and Umbra against Qiskit Aer on 162 and 7,705 circuits, reporting that RDBMSs, mainly SQLite, achieve lower peak memory on about half or more of the circuits, and that lightweight classifiers trained on InferQ features achieve up to 95.3% runtime-routing and 97.4% memory-routing accuracy. The paper also reports out-of-core execution for 40–45-qubit sparse circuits under a 16 GB memory limit and learned estimators for entropy/sparsity.

Significance. If the emitted SQL truly reproduces the circuit statevector, InferQ fills a real gap: it provides a reproducible, scalable, SQL-native workload generator for database-oriented quantum simulation research, with a large public dataset, seeded generation, feature schema, and cross-engine comparisons. The explicit ablation study and the out-of-core experiments are useful and would enable follow-up work on query optimization and learned routing. These strengths are real and should be credited. However, the benchmark's central empirical claims are conditional on two issues: SQL correctness is assumed rather than verified, and the headline routing accuracies rely on dynamic features that are only available after simulation, so the stated 'data-centric simulator selection' use case is overstated. The 'general, compositional circuit' claim is also broader than the released corpus supports. These are fixable but load-bearing.

major comments (4)
  1. [§3.5, Outlook, §6] SQL equivalence is assumed, not verified. Section 3.5 states 'we construct an equivalent SQL query using the implementation in [13]' and the Outlook explicitly lists 'correctness checks' as future work. No comparison of the SQL result against a reference simulator appears in Section 6. If the CTE join/aggregate chain or the einsum-to-SQL translation contains any bug (qubit ordering, phase, dropped amplitudes), every runtime and peak-memory measurement, and every routing label and dynamic feature derived from the SQL output, describes a computation different from the intended circuit. Please add an automated equivalence check (e.g., compare the SQL result with Qiskit Aer's statevector on a stratified sample covering all templates), report the pass rate, and rerun the affected experiments if any discrepancy is found; expose this check as part of the benchmark pipeline.
  2. [§4.4, Table 8, Table 10] The headline routing accuracies use dynamic features — statevector_saved_shannon_entropy and statevector_saved_sparsity — that are only computable after the simulation has been run. A pre-execution 'simulator selection' system cannot use them. Table 10 quantifies the gap: full-feature XGBoost attains 0.95 runtime / 0.98 memory accuracy, while Static+Graph+SQL (the features available before simulation) attains 0.93 / 0.97. The abstract's 'using InferQ features ... accurately predict when SQL execution is preferable' obscures this dependence. Please either reframe the routing results as post-hoc workload characterization, or report a deployable pre-execution pipeline (static/graph/SQL features only, or dynamic features predicted by the §6.4 estimators) as the headline, clearly separating the two settings.
  3. [§3.2, Figure 15, Appendix I.1] The claim of 'general, compositional circuits' is not yet supported. Generation is restricted to a fixed hand-defined template set, and the released 202k corpus is heavily skewed toward sparse output states (Figure 15); the out-of-core family in Appendix I.1 is explicitly constructed to preserve 2^h support with CNOT-only expansion. Since the memory-win results are driven by sparse states, the >50% peak-memory claim should be stratified by output density and by template family, and the paper should state the coverage limitations. Adding dense-circuit templates or treating external-suite circuits (§E) as a separate, additional stratum would make the 'general' claim testable.
  4. [§6.1, Table 19, Appendix F] The peak-memory comparison underpinning the central claim is not fully specified. It is not stated whether 'peak memory' for each RDBMS is process RSS, container cgroup peak, or a DBMS-reported memory counter, nor how the comparison handles SQLite's file-backed temporary storage in the tuned profiles (Appendix G, Table 18). Appendix F reports median peak RSS of 203 MB for SQLite and 206 MB for Aer, but Figures 1 and 7 do not reference the measurement method. Please state the exact memory metric and measurement tool for each engine, and confirm that the same definition is used throughout.
minor comments (5)
  1. [Eq. (9), Section 4.4] The entropy definition uses (p_i + ε) log2(p_i + ε), but ε and τ are never given values, and the normalization effect of the smoothing is not discussed. Specify defaults and state how the entropy is affected by the ε term.
  2. [Figure 7] The figure legend is hard to parse: 'ducksql', 'psql', and the four Qiskit Aer methods are not clearly mapped to the bars, and the win percentages are not tied to a table in the main text. Consider a grouped bar chart with a separate table.
  3. [Section 6.2 and Section 5] The paper refers to 7,705 circuits for routing training and 202,975 in the released dataset. Clarify whether the 7,705 circuits are a subset of the 202,975, and why routing is evaluated only on the smaller set.
  4. [Appendix I.2] For DuckDB and SQLite, spill is measured with proc_io_write_bytes, an OS-level proxy that may include non-spill I/O. This is acknowledged, but the potential bias should be quantified or discussed in the main out-of-core analysis.
  5. [Appendix H] The sentence 'each circuit is compiled into a single SQL statement of the form WITH ... SELECT' is central to the workload definition but appears only in an appendix. Move a concise version to Section 3.5.

Circularity Check

1 steps flagged

SQL-equivalence premise is delegated to co-authored [13] and correctness is deferred to future work, making the RDBMS memory/routing measurements conditional on an unverified self-cited artifact; no prediction reduces to a fit.

specific steps
  1. self citation load bearing [Section 3.5 (SQL query generation); Outlook; Sections 6.2 and Appendix G]
    "Once a circuit is generated, we construct an equivalent SQL query using the implementation in [13]. We extended their package by making it a dependency to InferQ. The package uses the einstein summation (einsum) representation of a quantum circuit with tensor algebra. It then converts tensor contractions into relational joins as proposed by Blacher et al. [6]. ... As future work, we plan to further optimize RDBMS-based simulation ... InferQ can also be extended from circuit generation to end-to-end validation for quantum algorithm design, covering correctness checks, iterative test–debug cycle"

    The benchmark's central value proposition is that each emitted SQL workload 'expresses the simulation task.' Section 3.5 asserts equivalence only by invoking the implementation in [13], whose authors include Rihan Hai, a co-author of this paper. The Outlook explicitly defers 'correctness checks' to future work, and no statevector-versus-SQL comparison is reported anywhere in Section 6. Therefore the headline empirical results (RDBMS peak-memory wins on >50% of circuits, routing accuracies up to 95.3%/97.4%, out-of-core completions) are measured over SQL artifacts whose correctness is imported from the authors' own prior work and never independently established. This makes the central premise load-bearing self-citation rather than a demonstrated, self-contained derivation.

full rationale

The paper's empirical claims are genuine measurements on generated workloads, not derivations from its own equations. I find no place where an equation is defined in terms of its target or where a fitted parameter is simply renamed as a prediction. The principal load-bearing weakness is the SQL-equivalence assumption: Section 3.5 delegates query generation to [13] (a PVLDB paper co-authored by Rihan Hai), and the Outlook explicitly lists 'correctness checks' as future work. Without a comparison of the emitted SQL's result against Qiskit Aer's statevector, all runtime, memory, spill, and routing measurements may describe a computation different from the intended circuit. This is a self-citation load-bearing gap rather than a by-construction reduction, so it warrants score 4 rather than 6+: the benchmark's experimental content and ML routing evaluations are independent artifacts that would stand or fall on the unverified SQL equivalence. I also weighed the routing models' use of dynamic features (Shannon entropy, sparsity, von Neumann entropy) computed from the saved statevector. These features are post-hoc and the advertised accuracies include them, but the paper uses a proper held-out test split and reports ablations (Static+Graph+SQL without dynamic features still reach 0.93 runtime / 0.97 memory accuracy; SQL-only features reach 0.92 runtime / 0.84 memory accuracy), so the classifier does not reduce to a fit by construction. That issue is a deployment caveat, not a circular derivation.

Axiom & Free-Parameter Ledger

3 free parameters · 4 axioms · 0 invented entities

The central benchmark rests on a few user-chosen constants (synergy weights, entropy/sparsity thresholds, tuned DBMS profiles) and on two untested domain assumptions: SQL-compiler correctness and circuit-generality. No new physical entities are introduced.

free parameters (3)
  • Synergy rule weights β = β=2 in Example 3.1; others user-configurable, not systematically set
    Soft preferences in the Markov template-selection distribution; arbitrary user choices that shape the circuit distribution and therefore all downstream measurements.
  • Entropy smoothing ε and sparsity threshold τ = not numerically specified in the paper
    Eqs. (9)–(11) introduce ε for numerical stability and τ for the sparsity indicator; both are hand-chosen and affect the dynamic features used in routing.
  • DBMS tuning profiles (Table 18) = e.g., PostgreSQL work_mem 55–256 MB, DuckDB memory_limit 7.4–10.8 GB, SQLite cache 64–128 MB
    Automatically tuned by MLOS on a 162-circuit pilot set; these fitted engine parameters influence the win counts in Figure 1 and the memory-wins headline.
axioms (4)
  • domain assumption The Qymera einsum-to-SQL compiler produces a correct and equivalent simulation of the quantum circuit.
    Section 3.5 relies on [13] to emit 'an equivalent SQL query'; correctness has not been verified by the authors and is listed as future work in the Outlook.
  • domain assumption Qiskit Aer's per-circuit best method, with GPU acceleration disabled, is a fair conventional-simulator baseline for runtime and peak memory.
    Section 6.1 and Appendix F choose the fastest/lowest-RSS Aer method per circuit; this is a reasonable but nontrivial baseline choice that shapes all win counts.
  • domain assumption The template library and synergy rules generate circuits representative of 'general, compositional' quantum algorithms.
    Section 3 and Appendix J show the generator skews heavily sparse; without external validation the claim of generality over real quantum workloads is unproven.
  • ad hoc to paper Equation (9) with (p_i + ε) log(p_i + ε) is a valid Shannon-entropy estimate.
    Adding ε to every probability and taking the log of (p_i+ε) does not sum to 1 and is nonstandard; it is nevertheless treated as 'Shannon entropy' in feature importance.

pith-pipeline@v1.3.0-daily-deepseek · 37181 in / 13379 out tokens · 135830 ms · 2026-08-03T13:02:32.129180+00:00 · methodology

0 comments
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.3% 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 Aadi Patwardhan, Andrei Ilinescu, Rihan Hai.

Figure 1
Figure 1. 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 work￾loads is useful. Running the generated SQL inside DBMSs makes simulation subject to database execution and optimization choices, enabling… view at source ↗
Figure 2
Figure 2. Figure 2: Quantum gates represented as matrices. |0⟩ 𝐻 |0⟩ |0⟩ [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: GHZ state preparation circuit: it takes the all-zero [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
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] view at source ↗
Figure 5
Figure 5. Figure 5: InferQ feature extraction workflow. Static, graph￾based, and SQL-derived features are extracted prior to simu￾lation, whereas dynamic features can only be obtained after the simulation completes. sequence, both the subcircuit structure and the numerical gate parameters are exactly reproducible across runs. 3.6 Running Example [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: InferQ’s web-based UI for exploring dataset and [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 7
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 together with Qiskit Aer 0.17.0. For database-backed simulation, we generate SQL using the sql-einsum code generator12 and build on the RDBMS simu… view at source ↗
Figure 9
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] view at source ↗
Figure 10
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=sparse, 1=dense) Sparse [0, 0.33) Medium [0.33, 0.67) Dense [0.67, 1.0] Total CTEs Largest CTE [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 11
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 state￾preparation workloads) [6, 13]. Using InferQ, we move beyond [PITH_FULL_IMAGE:figures/full_fig_p010_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Importance of top 10 InferQ numeric features for [PITH_FULL_IMAGE:figures/full_fig_p012_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Importance of top 10 InferQ numeric features for [PITH_FULL_IMAGE:figures/full_fig_p012_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Predicted vs Actual value for the dynamic feature [PITH_FULL_IMAGE:figures/full_fig_p013_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Distribution of dynamic features over 202k entries [PITH_FULL_IMAGE:figures/full_fig_p013_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Confusion matrix with counts and normalization [PITH_FULL_IMAGE:figures/full_fig_p013_16.png] view at source ↗
Figure 17
Figure 17. Figure 17: Spill volume of RDBMS engines (PostgreSQL, [PITH_FULL_IMAGE:figures/full_fig_p015_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: Runtime of RDBMS engines (PostgreSQL, DuckDB, [PITH_FULL_IMAGE:figures/full_fig_p016_18.png] view at source ↗
Figure 19
Figure 19. Figure 19: Runtime versus spill volume for RDBMS engines [PITH_FULL_IMAGE:figures/full_fig_p016_19.png] view at source ↗
Figure 20
Figure 20. Figure 20: Spill volume with varying numbers of qubits (log scale). [PITH_FULL_IMAGE:figures/full_fig_p017_20.png] view at source ↗
Figure 21
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] view at source ↗
Figure 22
Figure 22. Figure 22: Execution time versus spill volume for sampled InferQ circuits (log-log). [PITH_FULL_IMAGE:figures/full_fig_p017_22.png] view at source ↗
Figure 23
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 each tensor contraction into SciDB’s Array Functional Language (AFL)-style array operations. In principle, an entire circuit could be encoded a… view at source ↗
Figure 24
Figure 24. Figure 24: Expander circuit structure: Hadamards on [PITH_FULL_IMAGE:figures/full_fig_p023_24.png] view at source ↗
Figure 25
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] view at source ↗
Figure 26
Figure 26. Figure 26: Generated-corpus static circuit-feature distributions. Dashed lines mark medians. [PITH_FULL_IMAGE:figures/full_fig_p025_26.png] view at source ↗
Figure 27
Figure 27. Figure 27: Generated-corpus interaction-graph feature distributions. Dashed lines mark medians. [PITH_FULL_IMAGE:figures/full_fig_p026_27.png] view at source ↗
Figure 28
Figure 28. Figure 28: Importance of various SQL features for SVM and [PITH_FULL_IMAGE:figures/full_fig_p026_28.png] view at source ↗
Figure 31
Figure 31. Figure 31: Bar chart displaying the imbalance between the [PITH_FULL_IMAGE:figures/full_fig_p028_31.png] view at source ↗
Figure 32
Figure 32. Figure 32: Schema for storing extracted circuit features. [PITH_FULL_IMAGE:figures/full_fig_p029_32.png] view at source ↗
Figure 33
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] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

39 extracted references · 2 canonical work pages

  1. [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. [2]

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

    1999

  3. [3]

    Andrew Adams, Karima Ma, Luke Anderson, Riyadh Baghdadi, Tzu-Mao Li, Michaël Gharbi, Benoit Steiner, Steven Johnson, Kayvon Fatahalian, Frédo Du- rand, et al . 2019. Learning to optimize halide with tree search and random programs.ACM Transactions on Graphics (TOG)38, 4 (2019), 1–12

    2019

  4. [4]

    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

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

  5. [5]

    Almudever, and Sebastian Feld

    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

    Pith/arXiv arXiv 2024

  6. [6]

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

    2023

  7. [7]

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

    2023

  8. [8]

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

    2002

  9. [9]

    Lingjiao Chen, Arun Kumar, Jeffrey Naughton, and Jignesh M Patel. 2017. To- wards Linear Algebra over Normalized Data.Proceedings of the VLDB Endowment 10, 11 (2017)

    2017

  10. [10]

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Haichen Shen, Meghan Cowan, Leyuan Wang, Yuwei Hu, Luis Ceze, et al. 2018. TVM: An Automated End-to-End Optimizing Compiler for Deep Learning. In13th USENIX Symposium on Operating Systems Design and Implementation (OSDI). 578–594

    2018

  11. [11]

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

    Pith/arXiv arXiv 2014

  12. [12]

    András Gilyén, Yuan Su, Guang Hao Low, and Nathan Wiebe. 2019. Quantum sin- gular 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

  13. [13]

    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

    2025

  14. [14]

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

    Pith/arXiv arXiv 2025

  15. [15]

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

    2009

  16. [16]

    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.114 5/3725309

    2025

  17. [17]

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

    2015

  18. [18]

    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

  19. [19]

    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

  20. [20]

    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

  21. [21]

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

    Pith/arXiv arXiv 2022

  22. [22]

    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

    arXiv 2025

  23. [23]

    Shangyu Luo, Dimitrije Jankov, Binhang Yuan, and Chris Jermaine. 2021. Auto- matic optimization of matrix implementations for distributed machine learning and linear algebra. InProceedings of the 2021 International Conference on Man- agement of Data (SIGMOD). 1222–1234

    2021

  24. [24]

    Nantia Makrynioti and Vasilis Vassalos. 2019. Declarative Data Analytics: A Survey.IEEE Transactions on Knowledge and Data Engineering (TKDE)33, 6 (2019), 2392–2411

    2019

  25. [25]

    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

  26. [26]

    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

  27. [27]

    2010.Quantum Computation and Quan- tum Information

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

    2010

  28. [28]

    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

  29. [29]

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

    2025

  30. [30]

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

    2025

  31. [31]

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

    doi:10.22331/q-2023-07-20-1062 2023

  32. [32]

    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

  33. [33]

    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.org/abs/22 02.11045

    Pith/arXiv arXiv 2022

  34. [34]

    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

  35. [35]

    Yisu Remy Wang, Shana Hutchison, Jonathan Leang, Bill Howe, and Dan Suciu

  36. [36]

    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

    work page doi:10.1145/3626769 2023

  37. [37]

    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

  38. [38]

    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). InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Appendices Table 12 provides a compact roadmap of the appendix material. Table 12: Appendix roadmap. Appendix M...

    2020

  39. [2020]

    SPORES: sum-product optimization via relational equality saturation for large scale linear algebra.Proceedings of the VLDB Endowment13, 12 (2020), 1919–1932

    2020

This paper was first reviewed by deepseek-v4-flash on August 3, 2026.