Paper deep dive
InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation
Andrei Ilinescu, Aadi Patwardhan, Rihan Hai
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 89%
Last extracted: 8/3/2026, 2:39:32 AM
Summary
The paper introduces InferQ, a database-oriented benchmark for quantum circuit simulation that generates compositional circuits and translates them into SQL workloads for RDBMS execution. It addresses gaps in existing benchmarks by providing a large dataset of 202,975 circuits with extracted features, enabling systematic evaluation of RDBMS engines (PostgreSQL, SQLite, DuckDB, Umbra) against traditional simulators like Qiskit Aer. The study demonstrates that RDBMSs can achieve better peak memory usage than Qiskit Aer for over 50% of circuits and that lightweight machine learning models can accurately predict when SQL execution is preferable based on circuit and query features.
Entities (13)
Relation Signals (10)
InferQ → comparesagainst → Qiskit Aer
confidence 95% · In experiments across RDBMS engines ... and the widely used Qiskit Aer simulator
InferQ → evaluates → DuckDB
confidence 95% · In experiments across RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra)
InferQ → generates → 202,975 circuits
confidence 95% · InferQ also releases a large dataset of 202,975 circuits online
InferQ → uses → SQL
confidence 95% · InferQ ... emits each simulation task as an RDBMS-ready SQL workload
InferQ → evaluates → Umbra
confidence 90% · In experiments across RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra)
InferQ → evaluates → SQLite
confidence 90% · In experiments across RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra)
InferQ → evaluates → PostgreSQL
confidence 90% · In experiments across RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra)
InferQ → outperforms → Qiskit Aer
confidence 90% · RDBMSs achieve better peak memory usage than Qiskit Aer on more than 50% of the circuits
DuckDB → →
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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.
Tags
Links
- Source: https://arxiv.org/abs/2607.29134v1
- Canonical: https://arxiv.org/abs/2607.29134v1
Trouble viewing inline? Open PDF directly →
Full Text
144,644 characters extracted from source content.
Expand or collapse full text
InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Andrei Ilinescu ∗ a.ilinescu@student.tudelft.nl Delft University of Technology Delft, The Netherlands Aadi Patwardhan ∗ a.patwardhan@student.tudelft.nl Delft University of Technology Delft, The Netherlands Rihan Hai r.hai@tudelft.nl Delft University of Technology Delft, The Netherlands 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 optimiza- tion, physical design, and engine-level evaluation across a broad range of circuits. We presentInferQ, a database-oriented bench- mark for quantum circuit simulation.InferQgenerates general, compositional circuits by assembling subcircuits from a set of cir- cuit 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.InferQalso re- leases 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 (Post- greSQL, 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 byInferQ. Moreover, usingInferQfeatures, lightweight machine learning models (linear and tree-based models) can accurately pre- dict when SQL execution is preferable (with accuracy up to 95.3% for runtime and 97.4% for memory), enabling data-centric simula- tor selection and opening the door to principled optimization of SQL-based quantum circuit simulation. 1 Introduction In the current noisy intermediate-scale quantum (NISQ) era, most quantum applications are developed and validated through classi- cal simulation. Quantum programs are typically expressed in the circuit model as a sequence of gates, and the common practice is to execute the circuit on a simulator before running it on quan- tum hardware. Simulators produce the circuit’s (predicted) output, e.g., measurement outcomes or their probabilities. Efficient circuit simulation, therefore, remains a cornerstone for near-term quan- tum algorithm development. For database researchers, this raises a data management question: can circuit simulation be expressed as a relational workload whose execution can benefit from data- base management systems (DBMS) memory management, query optimization, and out-of-core processing? Data management challenge. Recent work [6,13] argues that relational databases can serve as a competitive simulation engine by compiling circuit simulation into relational workloads. A par- ticularly promising result is that DuckDB can scale to millions of qubits for sparse circuits. Concretely, under a 2GB memory limit, ∗ Both authors contributed equally to this research. DuckDB simulates up to 4,000,862 qubits for GHZ-state preparation and up to 53,017 qubits for W-state preparation [14], which are two standard state-preparation routines that initialize many qubits into widely used multi-qubit entangled states. These results raise an obvious question for the database community: when does “an RDBMS as a simulator” actually work? The same study makes clear this scalability is highly workload- dependent: for a dense circuit such as Quantum Fourier Transform (QFT), the maximum supported qubit count is only 14 under the same setting [14]. Moreover, the largest improvements in those experiments arise from circuits with a specific structure. For in- stance, GHZ is a stabilizer circuit, which uses only Clifford gates (Hadamard, CNOT, Phase), and is known to be simulated efficiently on classical computers via the Gottesman–Knill theorem [1]. More- over, a key systems gap is revealed in [6,13]: existing approaches have not fully exploited RDBMS capabilities to handle simulation workloads through mechanisms such as query optimization, in- dexing, and materialization, emphasizing that closing this gap is important for an end-to-end database-driven simulation pipeline. Altogether, these results motivate a database-centric benchmark: to move beyond isolated case studies, the community needs a sys- tematic way to generate diverse simulation workloads and study how SQL representations behave under query optimization and execution. Such a benchmark enables database researchers to study query planning, materialization, indexing, spill behavior, and back- end engine selection for quantum circuit simulation. That is, these results point to a benchmark gap. Why this is different from existing tensor workloads in RDBMS. When a quantum circuit is compiled into SQL, the underlying com- putation can be expressed as tensor algebra: applying gates cor- responds to multiplying and contracting tensors (e.g., updating a state vector by small operators). At a computational level, circuit simulation in RDBMS is a tensor workload: vector-matrix multipli- cation, matrix-matrix multiplication, and tensor contractions. One of the most frequent operations is matrix multiplication. Using SQL, matrix multiplication can be implemented as a join-and-aggregate operation: represent the matrices in long form as퐴(푖,푘,푎 푖푘 )and 퐵(푘, 푗,푏 푘푗 ), compute푊= 퐴퐵by joining rows of퐴and퐵on the shared inner index푘, multiplying matching values, and summing over 푘 : 푤 푖푗 = ∑︁ 푘 푎 푖푘 푏 푘푗 , which corresponds to: SELECT A.i, B.j, SUM(A.val * B.val) AS w_ij FROM A JOIN B ON A.k = B.k GROUP BY A.i, B.j; arXiv:2607.29134v1 [quant-ph] 31 Jul 2026 Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai This style of expressing tensor computation in SQL has been studied in the database community [7,19,24,28,38], including recent work on efficient Einstein summation in SQL [6] and relational abstractions for tensor and linear-algebra workloads in ML [9,23, 32, 35, 37]. However, the simulation workload induced by quantum circuits differs from mainstream ML workloads in several fundamental ways. In transformer models, the core computation is dominated by dense linear algebra over matrices with dimensions in the thou- sands (e.g., attention uses dense푄퐾 ⊤ and푄푉products) [34]. In contrast, a quantum circuit acts on a state vector of dimension 2 푁 : for qubit count푁=50, the state has 2 50 ≈1.13×10 15 amplitudes, which already requires about 16 PiB just to store a dense complex state vector. At the same time, each instruction applies only a tiny operator (typically 2×2 or 4×4 matrices), but it must be applied across this exponentially large index space. The structure of a quan- tum circuit determines a sequence of tensor contractions whose intermediate sparsity and entanglement can change abruptly across the gate sequence. This mismatch creates database-specific difficulties: (i) intermedi- ate results may be enormous unless the representation stays sparse or factored; (i) whether sparsity survives depends on the gate se- quence, and entangling operations can rapidly densify the state and cause abrupt blow-ups; and (i) the computation is a long, dependency-constrained sequence of small updates rather than a few large tensor computations, so “optimize one big join” is not the right mental model. Consequently, optimizing SQL for quan- tum circuit simulation is not a direct reuse of existing in-database tensor/ML techniques: the bottlenecks, cardinality growth, and the importance of circuit structure (sparsity patterns, interaction graphs, composition rules) are qualitatively different. A benchmark that systematically varies these properties is therefore essential for a principled optimizer and execution-engine research in this space. Gaps of existing benchmarks. Existing quantum benchmarks such as SupermarQ [33], MQT Bench [31], and QASM Bench [21] provide valuable circuit suites for the quantum community, but they do not directly target database execution. In particular, they generate circuits as quantum-circuit descriptions (e.g., QASM/Qiskit circuits) meant to be run by quantum toolchains, not as relational workloads. As a result, they are not designed to evaluate how an RDBMS behaves as a simulation engine, e.g., the impact of query optimization, physical design (indexes/partitioning), and execution strategies on circuit-simulation workloads. Our approach. We presentInferQ, a database-oriented benchmark for quantum circuit simulation. Given a small user configuration (Table 2),InferQgenerates compositional circuits by assembling subcircuits from a set of quantum templates. Each circuit is ac- companied by an RDBMS-ready SQL workload that expresses the simulation task as relational operators. This makes quantum circuit simulation directly accessible to database research: each circuit becomes both a quantum artifact and a relational workload whose query shape, intermediate behavior, and backend performance can be analyzed. Moreover, to support data-centric analysis,InferQ also extracts four groups of features: static and graph features from the circuit structure, SQL features from the emitted query work- load, and dynamic features from the simulation. Our experimental 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 better memory management, runtime improvements for certain circuits, and out-of-core execution for large circuits under memory limits. Thus, RDBMS-based simulation enables systematic optimization of quantum circuit simulation through DBMS memory management, spill-aware execution, and backend selection. Contributions. We make the following contributions: •We proposeInferQ, a benchmark that produces quantum circuit simulation workloads in relational form (SQL), enabling direct evaluation inside RDBMS engines. •We design a template-based generator that scales circuit size while preserving realistic structure via compositional circuit generation (Section 3). •From the generated circuits, we extract static, graph, SQL, and dy- namic features per circuit, enabling systematic workload charac- terization and correlation with database performance (Section 4). •UsingInferQworkloads, we quantify when SQL-driven simula- tion is competitive with Qiskit Aer, including memory-efficient and out-of-core cases.InferQfeatures enable accurate, light- weight machine learning based selectors for deciding when to use an RDBMS engine (Section 6). 2 Background 2.1 Quantum Bits, Gates, and Circuits A classical bit stores either 0 or 1. In contrast, a quantum bit (qubit) is a unit vector in a two-dimensional complex vector space, typically described using the computational basis of|0⟩ and|1⟩: |0⟩= 1 0 , |1⟩= 0 1 . An arbitrary single-qubit state can be written as a superposition of these basis states: |휓⟩= 훼|0⟩+ 훽|1⟩, |훼| 2 +|훽| 2 = 1, where훼and훽are complex amplitudes. If we perform measurement on the quantum state|휓⟩, it collapses to a classical bit of 0 or 1. That is, a measurement of|휓⟩against the computational basis yields outcome 0 with probability|훼| 2 and outcome 1 with probability |훽| 2 . InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Circuit Construction |q1⟩ |q2⟩ |q3⟩ S H T 1-qubit Gate 2-qubit Gate Equivalent Matrices S Phase Gate 10 0i H Hadamard Gate 11 1-1 T T (π/8) Gate 10 0 e (iπ/4) CNOT CNOT Gate 1000 0100 0001 0010 1 √2 Example Gate Legend Single-qubit (2×2) Unitary Matrix: Gate S — Phase H — Hadamard T — π/8 gate Two-qubit (4×4) Unitary Matrix : — CNOT Input : C 4 → Output : C 4 Input : C 2 → Output : C 2 Figure 2: Quantum gates represented as matrices. |0⟩ 퐻 |0⟩ |0⟩ Figure 3: GHZ state preparation circuit: it takes the all-zero state|000⟩as input and prepares a maximally entangled state. An푁-qubit state can be expressed as a superposition over all computational basis states indexed by bitstrings: |Ψ⟩= ∑︁ 푥∈0,1 푁 푐 푥 |푥⟩, ∑︁ 푥∈0,1 푁 |푐 푥 | 2 = 1. Fix an ordering of the computational basis states (e.g., lexicographic order). The state vector representation of|Ψ⟩is the column vector of its amplitudes in that order: 푐 0·0 푐 0·1 . . . 푐 1·1 . For example, when푁=2, any two-qubit state|Ψ⟩can be represented as a linear combination of|00⟩,|01⟩,|10⟩, and|11⟩, and|푐 00 | 2 +|푐 01 | 2 +|푐 10 | 2 +|푐 11 | 2 =1. The state vector representation of|Ψ⟩ is 푐 00 푐 01 푐 10 푐 11 . Quantum computation follows the circuit model, which is anal- ogous to classical logic circuits. Computation is performed by ap- plying quantum gates (unitary operators) acting on one or more qubits to transform the quantum state. A matrix푈is unitary if 푈 † 푈= 푈 † = 퐼. As shown in Figure 2, a quantum gate can be represented by a unitary matrix, and withInput∈ C 푛 it indicates that the gate acts on an푛-dimensional state vector of complex am- plitudes (whereCdenotes the complex numbers), e.g., one qubit corresponds toC 2 and two qubits toC 4 . A gate set is called univer- sal if it can approximate any unitary operator to arbitrary precision [27]. A widely used universal set is the Clifford gates (including the Pauli gates (푋,푌,푍), the Hadamard gate퐻, the phase gate푆, the controlled-NOT (CNOT) gate), and the푇gate. Figure 2 illustrates several of these gates and their matrix representations. A quantum circuit is a sequence of quantum gates, and the overall computation corresponds to the composition of their unitary matrices. Circuit depth is the number of sequential layers of quantum gates in a circuit, representing how many time steps are required to execute it when gates that act on different qubits can be applied in parallel. For example, in Figure 3, the circuit depth is 3. We can consider quantum circuits as higher-level operators composed of subcircuits. By abstracting away from hardware and physical implementation details, we can treat such structures modularly. Take the GHZ state preparation circuit in Figure 3 for instance. It can serve as a state preparation subcircuit for larger algorithms, i.e., it prepares an input state for other algorithms. 2.2 Limitations of Existing Benchmarks Several quantum circuit benchmarks are widely used in the quan- tum computing community, including SupermarQ [33], MQT Bench [31], and QASM Bench [21]. While these suites are valuable for evalu- ating quantum circuits, they expose limited support for database- driven and data-centric studies of circuit simulation. Gap 1: No broad DBMS-executable benchmark workloads. Existing benchmarks primarily distribute circuits as OpenQASM 1 and Qiskit QPY 2 files. These formats are well-suited for quantum toolchains, but they do not expose the induced simulation compu- tation as optimizer-visible relational workloads that can be directly executed, inspected, or optimized by an RDBMS. As a result, study- ing circuit simulation inside an RDBMS typically requires substan- tial manual translation and non-trivial quantum expertise. The two recent DB-oriented simulation works discussed above [6,13] are important first steps within this gap: they show that SQL/RDBMS execution can support quantum circuit simulation. However, their workload coverage is limited. [6] targets general Einstein summa- tion and evaluates SQL simulation on Google’s Sycamore quantum- supremacy circuit, while [13] studies W and GHZ state preparation and QFT circuits. Thus, these works motivate DBMS-backed simu- lation, but do not provide a benchmark-scale collection of diverse circuits with reusable SQL workloads and workload features. We address this gap by havingInferQgenerate general, diverse circuits, each coming with an RDBMS-ready SQL workload (Sec- tion 3). This effort is important because it makes the simulation workload visible to database systems: tensor contractions become join-and-aggregate queries whose plans, indexes, materialization choices, and spill behavior can be studied and optimized. Conse- quently,InferQenables evaluating whether DBMS execution can improve memory usage, runtime, and scalability under memory limits, rather than merely translating circuits into another format. Gap 2: Lack of structured compositional circuits. Real quantum programs are typically assembled as pipelines of subroutines such as state preparation, algorithmic cores, estimation procedures, and measurement. However, existing benchmarks largely treat circuits as independent, fixed templates for standalone algorithms. They do not systematically compose building blocks into larger circuits, nor do they model dependencies between subcircuits. In practice, the choice of one subroutine often constrains what can follow (e.g., Hamiltonian simulation followed by phase estimation). We address this gap in Section 3.2 by modeling conditional, history-dependent template composition as a Markov transition process. 1 https://openqasm.com/ 2 https://quantum.cloud.ibm.com/docs/en/api/qiskit/qpy Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 1: Representative circuit templates and example compositions. Current template Full circuit template name Next possible templates DescriptionExample compositions START(start symbol)StatePrep,Oracle/A, Variational Common entry points (prepare input/eigenstate/ansatz), enabling realistic multi-block pipelines. START→StatePrep START → Oracle/A START→Variational StatePrepState Preparation HamSim , ModularExp , GroverIter, Variational Prepares |휓⟩/|푏⟩ or initial superpositions before an algorithmic primitive. StatePrep→ HamSim StatePrep →Variational HamSimHamiltonian SimulationQPE, Variational , Random Controlled time-evolution unitaries are typically read out via QPE (incl. IQFT decoding) in eigenvalue/spectral workflows. HamSim→QPE QFTQuantum Fourier TransformQPE,Measure, Random Fourier-basis transform and dense benchmark block.QFT→QPE QFT→Measure Oracle/A Oracle/Algorithm-퐴 WrapperGroverIter, Variational,Measure Encodes a problem-dependent subroutine 퐴 (e.g., oracle/feature map/encoding) that is naturally followed by Grover-style amplification. 퐴→GroverIter→ AmpEst ModularExpModular ExponentiationQPEOrder-finding and Shor-style structure: modular arithmetic unitaries followed by phase estimation (incl. IQFT) to extract phases/periods. ModularExp→QPE GroverIterGrover IterationGroverIter(repeat), AmpEst, Measure Amplification layers typically repeat and then transition to an estimation wrapper or terminate with measurement. GroverIter→GroverIter GroverIter → AmpEst GroverIter→Measure AmpAmplAmplitude AmplificationMeasureBoosts the probability of a desired or postselected outcome.AmpAmpl→Measure QPEQuantum Phase EstimationAmpAmpl,Measure, Variational , Random Phase readout/decoding stage (typically includes an IQFT); often followed by measurement or optional continuations. QPE→AmpAmpl QPE→Measure QPE→ Variational QPE→ Random VariationalVariational Circuit Layer/ Ansatz Variational(repeat), Measure,Random Layered ansatz patterns; measurement used for objective estimation; can be interleaved for hybrid workloads. Variational→Variational Variational→Measure Variational→Random RandomRandom Circuit BlockRandom,MeasureDiversity/stress-test tail; may extend circuit length or terminate by measurement. Random→Random Random→Measure AmpEstAmplitude Estimation Measure Estimates a success amplitude or probability. It normally terminates the quantum subroutine by measurement and classical post-processing. AmpEst→ Measure MeasureMeasurementENDFinal step that yields classical outcomes and ends the whole circuit generation process. Measure→END END(end symbol)—It marks the end of the template sequence.END Gap 3: Limited scalability for data-centric analysis. Because many existing benchmarks focus on fixed algorithm templates, their scal- ability is inherently limited: the number of instances grows slowly, and structural diversity is constrained. This limits their usefulness for data-centric workflows that require large corpora, such as ap- plying machine learning models, cost modeling, and feature-driven analysis. We address this gap with scalable compositional genera- tion and validate scalability experimentally in Section L.1. We also release a large dataset of 202,975 circuits to support large-scale quantum circuit simulation studies. Gap 4: Limited circuit-as-graph and SQL-level characterization. Quantum circuits are inherently graph-structured: qubits corre- spond to vertices and multi-qubit gates induce interactions as edges [25]. This structure is central to simulation cost and to the shape of the induced SQL workload. Nevertheless, existing bench- marks expose few graph-derived properties and provide limited support for analyzing structural diversity across circuits. We ad- dress this gap by explicitly extracting graph features (Section 4.2) and SQL features for the query representation (Section 4.3). Summary. Overall, existing benchmarks fall short of supporting database-driven and data-centric research on quantum circuit sim- ulation. Addressing these gaps requires a benchmark that produces SQL workloads, supports conditional composition of subcircuits, scales to large and diverse circuits, and exposes graph- and query- level structure for systematic analysis. 3 InferQ Benchmark InferQ has two components. First, it generates quantum circuits via templates. Second, it extracts a structured set of circuit features that support database-oriented analysis of RDBMS-backed simulation. This section presents theInferQbenchmark pipeline (Figure 4). We describe the features in Section 4. Design goal. Quantum algorithms are typically built by composing reusable algorithmic blocks, often called primitives. Examples in- clude state preparation, Hamiltonian simulation, quantum Fourier transform (QFT), quantum phase estimation (QPE), amplitude am- plification and estimation, and variational layers [2,8,11,12,26]. For example, the Harrow–Hassidim–Lloyd (HHL) algorithm [15] can be viewed, at a high level, as a composition of Hamiltonian simulation, QPE, and amplitude amplification. More broadly, many modern quantum algorithms are developed by composing primitive transformations in structured ways [12,26]. Thus, a simulation benchmark should not be limited to a fixed set of textbook circuits, but should support diverse and extensible workloads that can cover recent and future quantum algorithms. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Database benchmarks such as TPC-H 3 , TPC-DS 4 , and the Join Order Benchmark (JOB) [20] use parameterized templates to ob- tain controlled scale, coverage, and reproducibility. Inspired by this design,InferQgenerates circuits from a library of templates rep- resenting quantum primitives (Table 1) and composes them using feasibility constraints and history-dependent transition rules. In InferQ, randomness is used to vary parameters, scale, and primitive combinations, while preserving meaningful composition patterns. Compared with existing quantum benchmarks centered on a fixed set of textbook circuits [21,31,33],InferQis more general and extensible: new primitives and transition rules can be added as quantum algorithms and simulation workloads evolve. This gives InferQbroad benchmark coverage while preserving the structure needed to study realistic quantum-circuit simulation workloads in an RDBMS. 3.1 Overview InferQ targets the compositional structure found in existing quan- tum circuits, where a single circuit is assembled from multiple building blocks (Table 1). 5 This differs from template-only bench- marks that generate isolated, standalone circuits.InferQselects an ordered sequence of circuit templates and instantiates each template into a subcircuit. The resulting subcircuits are then composed into one benchmark circuit. Concretely, InferQ generates one circuit instance as follows: (1)Select templates. Then it sequentially samples a template sequence using the history-dependent distribution. (2)Sample Hyper-Parameters.InferQfirst samples user- configured local hyper-parameters (e.g., qubit count and depth). (3)Generate subcircuits. For each selected template,InferQ samples template parameters and generates the correspond- ing subcircuit. (4)Output circuit. The circuit generation process stops when a stopping rule triggers, thenInferQcomposes all subcir- cuits into a single circuit. This design produces circuits that satisfy user constraints while supporting diverse compositions and realistic template transitions. 3.2 Select Templates InferQ builds a circuit incrementally: at each step, it chooses one circuit template and later instantiates it as a subcircuit. The pur- pose of template selection is to keep this sequence valid while still producing diverse, realistic benchmark workloads. InInferQ, we maintain a set of circuit templates퐹= 푓 1 , . . ., 푓 푀 . Table 1 lists representative templates, such asStatePrep; the full template set is documented online. 6 Given a selected template푓 ∈ 퐹,InferQ instantiates a subcircuit by sampling concrete, circuit-specific pa- rameter values. For example, from the StatePrep template we can generate a GHZ state preparation subcircuit with 10 qubits. 3 https://w.tpc.org/tpch/ 4 https://w.tpc.org/tpcds/ 5 Templates are compositional rather than disjoint: high-level primitives may include lower-level steps, but exposing common operations as reusable blocks supports flexible benchmarking. We use Start/End and keep Measure explicit, so every generated sequence has the uniform formStart→ actual circuit templates→ Measure→ End. 6 https://github.com/InfiniData-Lab/InferQ/blob/main/README.md Addressing Gap 2. Database benchmarks typically instantiate each query template independently, yielding a workload that is a set (or multiset) of queries without sequential dependencies among template choices. In contrast, as discussed in Gap 2, the circuits targeted byInferQare ordered compositions of subcircuits, and the choice of the next subcircuit is often constrained by (and se- mantically coupled to) the current one. InferQ therefore samples templates sequentially: the already-chosen template affects which templates are allowed next and how probabilities over possible choices are updated. Design element 1: Explicit synergy rules.InferQprovides a set of user-configurable synergy rules that encode statistical dependen- cies between templates and bias generation toward semantically co- herent pipelines, e.g.,StatePrep→HamSim→QPE,ModularExp→QPE, andA→GroverIter→AmpEst(Table 1). Intuitively, these rules specify how earlier template choices should increase or decrease the probability of selecting specific templates later, making the sampling distribution explicitly history-dependent. To explain our approach for conditional composition, we first introduce the following definitions and notation. Definitions. LetSdenote the space of subcircuits, and let푇be the number of templates (equivalently, subcircuits) generated for one circuit instance. Let퐵denote the context space, i.e., the current circuit generation status (e.g., remaining allowed templates, and synergy rules in Table 1). A circuit template푓 ∈ 퐹is a parameterized generator 푓 :Θ 푓 × 퐵 →S.(1) Letfeas(푏, 푓) ∈ 0,1be a hard feasibility predicate for choosing template 푓 ∈ 퐹 under context 푏 ∈ 퐵. InferQgenerates an ordered template sequence푓 1 , 푓 2 , . . ., 푓 푇 . At step푡, after selecting푓 푡 and sampling parameters휃 푡 ∈Θ 푓 푡 ,InferQ instantiates the corresponding subcircuit as 푠 푡 = 푓 푡 (휃 푡 ,푏 푡−1 ),(2) where 푏 푡−1 ∈ 퐵 is the current context. At each step푡 ∈ 1, . . .,푇,InferQmaintains a categorical distri- bution푝 푡 over the template set퐹. We write푝 푡 (푓)for the probability assigned to template 푓 ∈ 퐹 , so ∑︁ 푓∈퐹 푝 푡 (푓)= 1.(3) A larger value of푝 푡 (푓)means that template푓is more likely to be selected at step 푡 . Design element 2: Conditional composition as a Markov tran- sition model. At step푡,InferQsamples the next template from a categorical distribution over퐹. Given the current context푏 푡−1 , it proceeds in two steps: (1) Sample a template. First apply feasibility masking and renor- malize: ̄ 푝 푡 (푓)= 푝 푡 (푓) feas(푏 푡−1 , 푓) Í 푔∈퐹 푝 푡 (푔) feas(푏 푡−1 ,푔) , 푓 ∈ 퐹,(4) then sample푓 푡 ∼ ̄ 푝 푡 . Next, InferQ samples local parameters for푓 푡 , instantiates the corresponding subcircuit, appends it to the current circuit prefix, and updates the generation context. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai (2) Reweight to obtain the next distribution. LetRbe the set of synergy rules, where each rule is a triple(푇,푈,훽)with푇 ⊆ 퐹 (trigger),푈 ⊆ 퐹(target), and훽>0. After selecting푓 푡 , define the reweighted (unnormalized) probabilities b 푝 푡+1 (푓)= ̄ 푝 푡 (푓)· Ö (푇,푈,훽)∈R: 푓 푡 ∈푇, 푓∈푈 훽, 푓 ∈ 퐹,(5) and then apply feasibility under the updated context푏 푡 and renor- malize: 푝 푡+1 (푓)= b 푝 푡+1 (푓) feas(푏 푡 , 푓) Í 푔∈퐹 b 푝 푡+1 (푔) feas(푏 푡 ,푔) , 푓 ∈ 퐹.(6) Equations 4–6 keep the generation process simple: feasibility mask- ing removes disallowed templates that do not fit the current circuit, while synergy rules encourage quantum subcircuits (primitives) that commonly appear together. This lets InferQ generate circuits that follow quantum algorithm design principles without enumerat- ing every full circuit by hand. Allowed and disallowed compositions are captured by feasibility masking: a disallowed successor tem- plate receives probability zero in the current generation context and therefore cannot be sampled. The synergy rules are soft preferences over feasible successor circuit templates, guiding the generator to- ward meaningful algorithmic patterns, such as HamSim→QPE, without hard-coding a fixed enumeration of complete circuits. This separation is important because quantum algorithms, quantum hardware, and their simulation needs are evolving rapidly. The cur- rent design keepsInferQconfigurable as new quantum primitives and workloads emerge. Example 3.1 (Single-step reweighting under a synergy rule). As- sume the previously selected template isStatePrep. By Table 1, the feasible successors areHamSim, ModularExp, GroverIter, Variational, with a uniform distribution푝 푡 (·)= 1 4 . LetRinclude(푇,푈,훽)= (StatePrep, HamSim, 2) . Then b 푝 푡+1 (HamSim)= 1 2 , b 푝 푡+1 (ModularExp)= 1 4 , b 푝 푡+1 (GroverIter)= 1 4 , b 푝 푡+1 (Variational)= 1 4 , and after normalization, b 푝 푡+1 (HamSim)= 2 5 , b 푝 푡+1 (ModularExp)= 1 5 , b 푝 푡+1 (GroverIter)= 1 5 , b 푝 푡+1 (Variational)= 1 5 , 3.3 Sample Hyper-Parameters Circuit generation is constrained by the global hyper-parameters in Table 2, which are configured by users.InferQrequires users to provide ranges for key parameters, such as qubit count, depth, repetitions count for repeatable subroutines, and number of qubits used during evaluation. A concrete value is drawn uniformly at random from each range. If a user prefers a fixed value, they set the range endpoints equal (e.g.,min_qubits=max_qubits=10). This range-based interface provides more flexibility for users to construct workloads. For database evaluation over the generated simulation workload, these ranges play the role of scale factors: they control the size and shape of the generated SQL workloads. 3.4 Generate Subcircuits Each selected circuit template푓is instantiated by sampling pa- rameters from its parameter domainΘ 푓 . InInferQ, we write one Table 2: Hyper-parameters. ParameterType Description min_qubitsintMinimum number of qubits per generated circuit. max_qubitsintMaximum number of qubits per generated circuit. min_depthintMinimum target depth of a generated quantum circuit. max_depthintMaximum target depth of a generated quantum circuit. min_repsintMinimum number of repetitions for repeatable subroutines (e.g., Grover iterations or variational layers). max_repsintMaximum number of repetitions for repeatable subroutines. min_eval_qubitsintMinimum number of qubits used during evaluation. max_eval_qubitsintMaximum number of qubits used during evaluation. measureboolWhether measurements are appended to the circuit. seedint Global random seed to ensure full reproducibility of circuit generation. sampled parameter tuple as 휃=(푛 푞 ,푑,푘,푟,휉) ∈Θ 푓 ,(7) where 푛 푞 is the qubit count, 푑 is the depth allocated to this subcir- cuit,푘is the evaluation-qubit count,푟is the repetition count for repeatable template sections, and휉is a tuple of template-specific configuration variables. Moreover,푛 푞 and푑control the circuit size, while푘and푟control the evaluation and repetition settings. That is, these parameters determine the generated circuit structure and, therefore, the number and shape of relational operators in the gen- erated SQL workload. The domainΘ 푓 is derived from the hyper-parameters in Table 2. For example, the per-subcircuit depth푑is sampled uniformly from the defined range between min_depth and max_depth. Quantum- specific choices inside 휉 can be found in Appendix K. 3.5 Output Circuit Generation stops when a maximum number of templates is reached or when a probabilistic stopping condition triggers. This prevents excessively long circuits while keeping circuit length variable across instances. After termination, the instantiated subcircuits푆 1 , . . .,푆 푇 are composed in order to produce the final benchmark circuit: 퐶= 푆 1 ◦ 푆 2 ◦·◦ 푆 푇 .(8) Alongside퐶,InferQoutputs a provenance record that stores the template sequence(푓 1 , . . ., 푓 푇 ), sampled parameters (including rep- etitions and휉), and global resource statistics (e.g., depth and gate counts). This record makes our generated circuit instances easy to inspect, query, and reproduce. This provenance is useful for data- base benchmarking because the same randomized workload can be replayed and compared across engines. SQL query generation. 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 con- tractions into relational joins as proposed by Blacher et al. [6]. Reproducibility guarantee. To make sure all sampling inInferQ is deterministic, we use seeded pseudo-random number generators 7 and maintain a global random seed as part of the hyper-parameters in Table 2. Consequently, with the seed and the generated template 7 Seehttps://docs.python.org/3/library/random#random.seedandhttps:// numpy.org/doc/2.2/reference/random/generated/numpy.random.seed.html. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation 1) Select templates history-dependent draw START → QFT (synergy boosts QPE) QFT → QPE 2) Sample Hyper- Parameters seed= 0 푛 푞 = 7, depth= 80 eval 푘= 4, reps 푟= 1 3) Generate subcircuit bind local params QFT: swaps=off QPE: 푚= 4, swaps=off sample 휃= 1.998 4) Output circuit merge subcircuits 퐶= 푆 1 ◦푆 2 store provenance: (templates, params) Figure 4: InferQ benchmark’s quantum circuit generation pipeline, and running example in Section 3.6. Circuit Generation (Section 3) Feature Extraction Simulation Graph Static SQL Dynamic Figure 5:InferQfeature 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 Figure 4 illustrates one end-to-end circuit instance generated by InferQ. The workflow is intentionally analogous to a database benchmark that (i) samples a scale/configuration, (i) instantiates a small sequence of templates with parameters, and (i) materializes both an artifact and its metadata. Step 1 (Hyper-Parameters). Given a user seed,InferQsam- ples an instance configuration(푛 푞 ,푑,푘,푟,휉). In this example,푛 푞 =7 qubits, depth 푑=80, evaluation 푘=4, and repetition count 푟=1. Step 2–3 (Template selection & subcircuits generation ). Starting from START,InferQsamples a short template sequence using the history-dependent distribution. Here the sequence is QFT →QPE. Each template is then instantiated by binding template- local parameters (e.g., boolean flags and small numeric values such as 휃=1.998). All choices are deterministic given the seed. Step 4 (Merge & provenance). The instantiated subcircuits are composed in order to produce the final circuit artifact퐶= 푆 1 ◦푆 2 . Alongside퐶,InferQstores a provenance record containing the template sequence and all sampled parameters, enabling exact replay and database-style inspection. 4 Circuit Feature Extraction When we push quantum circuit simulation into an RDBMS, it in- duces a sequence of relational operators (e.g., joins and aggregations implementing tensor contractions) over large intermediate relations. In this setting, performance depends on cardinality growth, join selectivity, skew, and the size of intermediate states. However, such properties are not explicit in the quantum circuit representation. To make systematic progress on query optimization, physical design (e.g., indexing/partitioning), and routing (deciding when an RDBMS backend is beneficial), we need a set of circuit features that indicate what the induced relational query workload looks like. Ideally, a feature vector that approximates workload characteristics Table 3: Notation used in circuit feature extraction. NotationDescription 퐶Quantum circuit (ordered list of gate instructions). 퐺Number of circuit instructions (gate count). 푁Number of qubits in the circuit. 푊Circuit width (maximum simultaneously active qubits). 퐺 퐼 = (푉,퐸)Qubit interaction graph induced by multi-qubit gates. 푉Vertex set of퐺 퐼 (qubits; |푉|= 푁 ). 퐸Edge set of퐺 퐼 (qubit interactions; |퐸| is the edge count). 2 푁 State-space dimension (length of a full statevector). p= (푝 1 ,...,푝 2 푁 ) Probability vector derived from the saved statevector. 퐻(p)Shannon entropy ofp (superposition). 휌(p) Sparsity / support density: fraction of entries above threshold (superposition). 푆 (푘) vN von Neumann entropy across qubit line푘 (entanglement). 휀 Small constant for numerical stability in entropy computation. 휏Threshold for treating near-zero entries as zero in sparsity computation. I(·)Indicator function (1 if condition holds, else 0). 푁 AST Total number of nodes in the SQL abstract syntax tree (AST). 푆Number of SELECT statements in the query. 푃Number of predicates appearing in WHERE clauses. 퐽Number of distinct relations participating in join conditions. before executing the full simulation. Therefore, we include a feature extraction component inInferQand aim to cover different sources of cost, including problem size (number of qubits, circuit depth), interaction structure, state evolution, and the generated SQL queries. As shown in Figure 5,InferQmodels each circuit with four types of features: static, graph, dynamic, and SQL features, as listed in Table 4- 7, respectively. Such a separation makesInferQextensible: new features can be added easily. Notably, as shown in Figure 5, feature extraction is an optional post-processing step:InferQcan generate circuits without extract- ing features, and computes them only when needed for analysis. 4.1 Static Features Static features describe basic properties of a quantum circuit. These features are crucial for constructing heuristics for efficient classical simulation. For example, dense state-vector representations are only feasible for circuits with small width and a small number of qubits, as memory requirements grow exponentially with these parameters. For an RDBMS-backed simulator, gate counts and depth largely determine the number and types of relational operators generated. As shown in Table 4, static features can be computed efficiently. We treat a circuit as an ordered list of instructions, where each instruction applies a gate to one or more qubits. This view allows us to analyze the complexity of computing static features. Let퐺 be the number of gates (instructions),푁the number of qubits, and Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 4: Time and space complexities for static features. FeatureTime SpaceDescription num_qubits푂(1) 푂(1)Total number of qubits width푂(퐺) 푂(푊)Maximum simultaneous active qubits depth푂(퐺) 푂(푊)Longest dependency chain circuit_size푂(1) 푂(1)Total gate count pauli_gate_count푂(퐺) 푂(1)Number of Pauli gates (X, Y, Z) two_qubit_gate_count푂(퐺) 푂(1)Number of two-qubit gates two_qubit_gate_percentage 푂(퐺) 푂(1)Ratio of two-qubit gates locality_ratio푂(퐺) 푂(1)Local vs. non-local gate ratio idling_score푂(퐺) 푂(푊)Idle qubit utilization density_score푂(퐺) 푂(퐺)Gate density feature [5] gate_counts푂(퐺) 푂(퐺)Per-gate-type histogram Table 5: Time and space complexities for graph features. FeatureTime SpaceDescription edge_count푂(1) 푂(1)Number of interaction edges max_degree푂(푁) 푂(1)Maximum node degree min_cut푂(푁퐸) 푂(푉 + 퐸)Minimum cut diameter푂(푁 3 ) 푂(푁 2 )Graph diameter radius푂(푁 3 ) 푂(푁 2 )Minimum eccentricity average_degree푂(푁) 푂(1)Mean node degree average_clustering_coefficient 푂(푁 3 ) 푂(1)Local clustering tendency average_shortest_path_length 푂(푁 3 ) 푂(푁 2 )Mean shortest path length central_point_of_dominance 푂(푁퐸) 푂(푁)Graph centralization measure std_dev_adjacency_matrix푂(푁 2 ) 푂(1)Adjacency matrix variance 푊the circuit width (maximum simultaneously active qubits). We assume푊 ≤ 푁 and typically 퐺 ≫ 푁 . We summarize the notation in Table 3. All static features in Table 4 are computable in at most linear time in퐺with modest memory overhead, making them inexpensive yet informative metadata for the InferQ benchmark. 4.2 Graph Features Graph features are computed from the qubit interaction graph, where vertices are qubits and edges represent interactions induced by multi-qubit gates. This abstraction enables the computation of classical graph properties, similar to existing works on quantum circuit compilation [4,5] and graph-based circuit characterization [17]. Graph features make circuit structure directly accessible to data- base analysis: they indicate what the join structure and intermediate- result growth may look like in relational tensor computation. Intu- itively, circuits whose interaction graphs are highly connected (e.g., with diameter-reducing shortcuts, high node degree, and strong centralization) tend to induce more global correlations and fewer separable subproblems, which often translates into harder contrac- tions and less opportunity for decomposition. As summarized in Table 5, graph features can be computed in polynomial time and space with respect to qubit count푁, with worst-case complexity bounded by푂(푁 3 ). Let퐸be the number of edges in the interaction graph. Under a gate set dominated by one- and two-qubit gates, each gate introduces at most one inter- action edge; hence퐸= 푂(퐺), with worst-case space푂(푁 2 )for a weighted, undirected interaction graph. Building an adjacency-list representation takes푂(푁+퐸)time and space. While some features require푂(푁 3 )time in the worst case, they remain practical for the qubit ranges where graph characterization is useful, and can be computed offline. Table 6: Time and space complexities for extracting SQL fea- tures (excluding parsing). FeatureTimeSpaceDescription num_and_clauses푂(푁 AST ) 푂(1)Counts logical AND operators during AST traversal num_joins푂(푆 · 푃 + 퐽 2 ) 푂(퐽 2 )Counts explicit and implicit joins and stores join edges num_select_columns 푂(푁 AST ) 푂(1)Counts column expressions in SELECT clauses num_agg_funcs푂(푁 AST ) 푂(1)Counts aggregate functions (e.g., COUNT, SUM, AVG) num_where_clauses 푂(푁 AST ) 푂(1)Counts WHERE clause nodes in the AST num_eq_predicates푂(푁 AST ) 푂(1)Counts equality predicates used in filters and joins Table 7: Time and space complexities for dynamic features. FeatureTimeSpaceDescription Shannon_entropy푂(2 푁 )푂(2 푁 )Shannon Entropy of stored statevector von_neumann_entropy 푂(푁 · 2 푁 ) 푂(푁 · 2 푁 )Von Neumann Entropy of stored statevector sparsity푂(2 푁 )푂(2 푁 )Sparsity of stored statevector 4.3 SQL Features SQL features are extracted from the generated SQL queries, which are relevant to the performance of RDBMS engines for quantum circuit simulation. Table 6 summarizes the complexities to calculate these features from the circuit SQL query representation. To cal- culate the various joins and other clauses, we view the query tree as an abstract syntax tree (AST) and then do a traversal. Getting to this SQL representation of a quantum circuit is not expensive. Using existing methods [13,22], we can generate these queries by translating the quantum circuit into Einstein summation (einsum) notation representing the tensor contraction sequence. In addition, we highlight InferQ’s extensibility in supporting the addition of new features, which facilitates a wide range of use cases and experimental analyses. 4.4 Dynamic Features As shown in Table 7, dynamic features depend on the circuit’s out- put state and cannot be derived from circuit structure alone. They are crucial for database-backed simulation because relational ap- proaches typically rely on sparse or factorized state representations: if the state remains sparse, relational operators can operate over small relations and avoid exponential blow-up; if entanglement grows quickly, intermediate results densify and the advantage di- minishes. We therefore extract three dynamic features that capture these effects: (i) Shannon entropy, (i) von Neumann entropy, and (i) a sparsity (non-zero support) measure of the saved statevector. Using the vector representation for the quantum state defined in Section 2, we define sparsity and entropies as follows: Letp= (푝 1 , . . .,푝 2 푁 )denote the probability distribution obtained from an 푁-qubit statevector in the computational basis. We compute the Shannon entropy, analogous to its use in classical and quantum information 퐻(p)=− 2 푁 ∑︁ 푖=1 (푝 푖 + 휀) log 2 (푝 푖 + 휀).(9) To quantify entanglement, we compute the von Neumann en- tropy across a partition defined by a cut along a qubit line 푘 , 푆 (푘) vN =−Tr 휌 퐴 푘 log 2 휌 퐴 푘 , 휌 퐴 푘 = Tr 퐵 푘 (휌),(10) InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Figure 6: InferQ’s web-based UI for exploring dataset and circuit features. where the bipartition corresponds to separating qubit line푘from the remaining qubit lines. We define the sparsity 휌(p)= 1 2 푁 2 푁 ∑︁ 푖=1 I(푝 푖 > 휏),(11) which we use synonymously with the support density, i.e., the fraction of basis states carrying non-negligible probability mass. Here, the Shannon entropy퐻(p)and sparsity휌(p)characterize the degree of superposition in the computational basis, with higher values indicating broader support over basis states, while the von Neumann entropy푆 (푘) vN measures quantum entanglement across each qubit line. We store the von Neumann entropy per qubit line to capture individual entanglement, rather than treating the full state as a combined vector, which being a pure state, has total entanglement entropy as zero. Characterizing both superposition and entanglement is essential for understanding the mechanisms underlying quantum advantage. All dynamic features are expensive to compute and require ex- ponential time and memory in푁for exact computation due to the full pass over the length-2 푁 vector. In particular, computing the von Neumann entropy across each of the푁qubit lines incurs an ad- ditional factor of푁on top of the full vector pass against the rest of the system, resulting in푂(푁·2 푁 )time and memory. This motivates an additional use case for InferQ in Section 6.4: enabling accurate dynamic-feature estimators without requiring full simulation of the circuit. 5 Implementation and Artifacts InferQ ships as (i) a Python framework that turns a user config- uration (Table 2) into circuits, features, and an RDBMS-ready SQL workload for simulation, and (i) a web-based UI for interactive dataset exploration (Fig. 6). Concretely, a database researcher can provide a small configuration file (e.g., qubit count) and run the toolkit to obtain SQL queries (plus circuit artifacts in JSON and QPY formats) that is ready to execute in an RDBMS engine. De- tailed descriptions of all circuit templates and the corresponding SQL code are provided in the online documentation. 8 In addition to on-demand generation,InferQreleases a large dataset of 202,975 circuits online 9 . Both database researchers and quantum scientists can search, filter, and download circuits and feature records through the web UI. The framework implements the pipeline described in Section 3 and Section 4. Each circuit is assigned a content-based hash com- puted from its structure and sampled parameters. This hash serves as the primary key and links the circuit artifact, the SQL workload, and all extracted feature records. For each circuit instance,InferQ stores: (i) the generated SQL queries (as.sqlscripts) that repre- sent the simulation workload, (i) the circuit in a portable Qiskit serialization format (e.g.,.qpy), and (i) a JSON record containing the template provenance and extracted features. InferQ includes a metadata analysis function that aggregates circuit statistics from JSON files, such as gate mix, depth, width, and interaction-graph properties. Details are provided in Appendix J and in the online repository. 10 Reproducibility. The code of our benchmark can be found on- line 11 .InferQis designed to be reproducible. Given the same code revision, dependency lockfile, and global seed (Table 2), the frame- work deterministically reproduces the same template sequence, sampled parameters, circuit artifact, emitted SQL, and extracted features. The content-based hash and provenance record make each benchmark instance easy to reference, regenerate, and audit. We will include more implementation and reproducibility details in our technical report. 6 Evaluation In this section, we useInferQto quantify and explain when an RDBMS engine is a competitive simulation engine for general, com- positional quantum circuits. First, in Section 6.2 we compare the InferQ-emitted SQL workloads on four RDBMS engines (Post- greSQL, SQLite, DuckDB, and Umbra) against Qiskit Aer for wall- clock runtime and peak memory. We have also trained lightweight selectors (linear and tree models) that predict when RDBMS should be chosen over Qiskit Aer. We validate the feature design via feature- importance analysis in Section 6.3 and demonstrate additional data- centric tasks enabled by InferQ in Section 6.4. 6.1 Experimental Settings All experiments were run on a single workstation equipped with an Intel Core i9–12900KF (24 threads), 64 GB RAM, and an NVIDIA RTX 3090 GPU, running Ubuntu 20.04.6 LTS with Linux kernel 5.15.0. To ensure a fair comparison between different RDBMS engines and other quantum circuit simulators, we disabled GPU and other hard- ware acceleration; all simulations were executed on CPU. We implemented our prototype in Python 3.12, with all depen- dencies pinned inpyproject.toml. Core numerical routines use NumPy 2.2.5, SciPy 1.15.3, and scikit–learn (≥1.8). For in-memory 8 https://github.com/InfiniData-Lab/InferQ/blob/main/generators/sql- templates.md 9 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/traini ng_data/estimator_training_data.parquet 10 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/distri butions/distributions.py 11 https://github.com/InfiniData-Lab/InferQ/blob/main/README.md Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai 020406080100 Percentage of cases (%) Wins (sim. time) Wins (memory) 21.0%6.8%9.9%27.2%35.2% 66.7%10.5%6.2%8.6%8.0% sqlite state_vector ducksql extended_stabilizer psql matrix_product_state umbra density_matrix 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 thesql-einsumcode generator 12 and build on the RDBMS simu- lator introduced by [13]. PostgreSQL is version 12.22 accessed via psycopg2-binary2.9.10. SQLite is version 3.50.4, and DuckDB is version 1.1.3. Umbra (v0.2-1665-gfeeb4b5d) is accessed through its PostgreSQL-compatible (18.1) server interface usingpsycopg2- binary2.9.10. For the out-of-core experiments, memory limits are enforced with Docker Engine (≥24.0) using per-container cgroups. Unless otherwise stated, we report the mean values across five repetitions for the experiments. 6.2 Use case 1: RDBMS as Simulation Backend Q1: Is an RDBMS an efficient simulation engine? To answer this question, we generated 162 circuits 13 usingInferQ. For each circuit, we measured wall-clock runtime and peak memory when simulating it with (i) RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra) executing the SQL workload emitted by InferQ, and (i) Qiskit Aer using four built-in simulation meth- ods 14 (statevector,extended_stabilizer,matrix_product_state, and density_matrix). Figure 7 reports, for each metric, the fraction of circuits for which a backend achieves the best result (minimum execution time or minimum peak memory) among all evaluated options. As expected, Qiskit Aer attains the best execution time on most circuits. SQLite achieves the lowest peak memory on 66.7% of the circuits (108/162). This suggests that RDBMS engines can be competitive simulation backends, particularly for memory. This result motivates further work on SQL workload optimization. Moreover, it is interesting to explore learning-based routing in simulation, i.e., predicting when an RDBMS engine is likely to outperform conventional simulators. This leads to our next question. Q2: How to decide whether to choose an RDBMS as a simulation engine? We model this choice as a binary selection problem: given a circuit, predict whether an RDBMS engine achieves lower runtime and/or lower peak memory than a conventional simulator. Prior 12 https://github.com/ti2-group/sql-einsum/tree/main/generate_sql_code 13 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/traini ng_data/rdbms_all_methods_training_data.parquet 14 Qiskit Aer Simulation Methods:https://qiskit.github.io/qiskit-aer/tuto rials/1_aersimulator.html#Simulation-Method-Option 200K500K 1M3M CTE size 1 MB 100 MB 1 GB 4 GB Spill r(lrg)=+0.46 r(tot)=+0.66 PostgreSQL 200K500K 1M3M CTE size r(lrg)=+0.32 r(tot)=+0.49 DuckDB 200K500K 1M3M CTE size r(lrg)=+0.38 r(tot)=+0.77 SQLite 40q41q42q43q44q45q LrgTotS-1 Figure 8: Out-of-core spill versus intermediate relation sizes. 404142434445 Number of qubits 2 5 10 20 50 100 Time (s) Runtime Performance (16 GB) PostgreSQL DuckDB SQLite Figure 9: Runtime versus #qubits. 20212223 10 KB 100 KB 1 MB 10 MB 100 MB 1.0 GB 10.0 GB Spill (log scale) PostgreSQL 20212223 DuckDB 20212223 SQLite Number of qubits Sparse [0, 0.33)Medium [0.33, 0.67)Dense [0.67, 1.0] Figure 10: Spill versus #qubits on sampled InferQ circuits. 0.00.51.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.00.51.0 ρ(tot)=+0.62 ρ(lrg)=+0.65 DuckDB 0.00.51.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 CTEsLargest CTE 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]. UsingInferQ, we move beyond InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Table 8: Routing performance on the 20% held-out test set. Models are evaluated using accuracy and normalized confusion- matrix entries. The columns represent true label→ prediction label. Best linear and tree-based models are bolded. (a) Time-optimal routing ModelAccuracyrdbms→rdbmsqiskit→qiskitrdbms→qiskitqiskit→rdbms Logistic Regression0.8870.940.880.060.12 Linear SVM0.9080.930.900.070.10 Decision Tree0.9400.780.970.220.03 Random Forest0.9560.810.980.190.02 XGBoost0.9530.880.960.120.04 (b) Memory-optimal routing ModelAccuracyrdbms→rdbmsqiskit→qiskitrdbms→qiskitqiskit→rdbms Logistic Regression0.9350.930.940.070.06 Linear SVM0.9400.930.950.070.05 Decision Tree0.9620.940.980.060.02 Random Forest0.9730.950.990.050.01 XGBoost0.9740.950.990.050.01 these constrained cases and quantify when an RDBMS is beneficial over a substantially broader set of general circuits. We have created a training dataset of 7,705 circuits 15 and train five standard 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 backends. This yields ground-truth labels (RDBMS wins vs. Qiskit wins) for both objectives. Table 8a shows that these models achieve high accuracy using the features extracted in Section 4, despite class imbalance (since SQLite is faster only for a subset of circuits). XGBoost performs best overall (95.3% accuracy, lower confusion than RF), consistent with its effectiveness for learned cost models [3,10]. The best linear model, linear SVM, too achieves 90.8% accuracy with very low off diagonal confusion entries on the test set, suggesting that much of the time-selection boundary is close to linear in our feature space. Given the strong performance of these lightweight models, we did not evaluate more complex models that require substantially higher training and tuning cost. For memory efficiency (Table 8b), performance is similarly strong: random forest and XGBoost are both best (with above 97.3% accu- racy and less than 5% misclassification per class), while the linear SVM also remains highly competitive (94.0% accuracy). Overall, InferQfeatures in Section 4 make the RDBMS selection decision predictable with simple, practical models. Routing overhead. The learned selector is trained offline on labeled workloads generated by InferQ and deployed only for in- ference. For XGBoost, which provides the best accuracy–efficiency trade-off among the models in Tables 8a and 8b, inference takes only 13.9 ms for runtime routing and 13.5 ms for memory routing per circuit. Appendix C reports the full training and inference times for all models. Our goal is therefore not to add heavyweight ML components to simulation, but to study a lightweight learned rout- ing policy for backend selection, aligned with recent database work on learned decision-making and cost models [16, 36]. The previous experiments compare runtime and peak memory only when all backends finish successfully. For larger circuits, con- ventional in-memory simulators such as Qiskit Aer can fail once the state representation exceeds available memory. RDBMS engines can instead execute queries out of core by spilling intermediate results to disk. This motivates the following question: Q3: Can RDBMS-based simulation complete workloads that no longer fit in memory? 15 Training data (Parquet) available athttps://github.com/InfiniData-Lab/Infe rQ/blob/main/analysis/training_data/rdbms_training_data.parquet. The results reported in Figure 1 also used this dataset. We evaluate Q3 using a family of large, sparse circuits with up to 45 qubits under a 16 GB memory limit and one CPU core. Full experimental details are in Appendix A of the supplementary ma- terial. Under this memory limit, Qiskit Aer’s exactstatevector method fails from 30 qubits onward, while PostgreSQL, DuckDB, and SQLite complete all runs by spilling temporary data to disk. Figure 8 shows that intermediate relations remain MB-scale, but spill reaches GB-scale and correlates more with the total interme- diate volume than with the single largest intermediate, indicating that cumulative joins and group-bys lead to externalization. Fig- ure 9 reports runtime: PostgreSQL is fastest, DuckDB is second, and SQLite is slower but robust. We have also observed that runtime is strongly correlated with spill volume. To understand out-of-core performance and the characteristics of the simulation workload, we have also sampled 17 InferQ circuits (20–23 qubits) with different output state sparsity. Figures 10 and 11 show that sparse outputs usually incur less spill, but output state sparsity alone does not determine spill: several medium-density cir- cuits spill more than dense ones due to intermediate-relation growth and optimizer choices (e.g., join ordering and materialization). Full settings and additional results are reported in Appendix A. Take-away. (1) Across a wide range of general, compositional circuits, RDBMS engines can be competitive simulation engines, especially in peak memory, and in some cases also in runtime. This enables follow-up work on optimizing the emitted SQL to further improve RDBMS performance. (2)InferQenables data-centric routing at scale: it generates diverse circuits, labels each circuit with observed runtime and peak memory, and exposes features that allow simple models to decide when an RDBMS engine should be used. This provides a foundation for learning-based simulator selection and optimiza- tion, trained on InferQ-generated circuits. (3) For large circuits that exceed memory, RDBMS backends can still complete simulation via out-of-core execution. This highlights a distinct advantage of database-backed simulation and enables follow-up work on spill-aware planning and optimization. 6.3 Feature Validation Next, we want to go deeper and understand: Q4: Which properties determine whether an RDBMS engine is an efficient simulation engine? Our goal is to validate that the four feature groups introduced in Section 4 (static, graph, dynamic, SQL) capture the key signals Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 9: Routing performance using only SQL-derived features on the 20% held-out test set. Models are evaluated using accuracy and normalized confusion-matrix entries. The columns represent true label→prediction label. Best linear and tree-based models are bolded. (a) Time-optimal routing ModelAccuracyrdbms→rdbmsqiskit→qiskitrdbms→qiskitqiskit→rdbms Logistic Regression0.7870.880.770.120.23 Linear SVM0.8030.880.790.120.21 Decision Tree0.9150.760.940.240.06 Random Forest0.9320.750.960.250.04 XGBoost0.9240.810.940.190.06 (b) Memory-optimal routing ModelAccuracyrdbms→rdbmsqiskit→qiskitrdbms→qiskitqiskit→rdbms Logistic Regression0.7350.770.710.230.29 Linear SVM0.7370.770.720.230.28 Decision Tree0.8360.810.850.190.15 Random Forest0.8660.820.900.180.10 XGBoost0.8420.840.850.160.15 4202 Importance circuit_size num_joins width edge_count statevector_saved_shannon_entropy num_and_clauses average_degree num_eq_predicates num_select_columns num_where_clauses Linear SVM Feature Importance 0.00.10.20.3 Importance num_agg_funcs pauli_gate_count edge_count num_joins average_clustering_coefficient statevector_saved_sparsity width num_eq_predicates statevector_saved_shannon_entropy num_where_clauses XGBoost Classifier Feature Importance Figure 12: Importance of top 10 InferQ numeric features for SVM and XGBoost trained for optimizing execution time. 321012 Importance average_clustering_coefficient two_qubit_gate_percentage num_eq_predicates num_qubits num_select_columns edge_count num_agg_funcs num_where_clauses statevector_saved_shannon_entropy average_degree Linear SVM Feature Importance 0.000.050.100.150.200.25 Importance num_where_clauses idling_score average_degree num_agg_funcs statevector_saved_sparsity max_degree edge_count width statevector_saved_shannon_entropy num_qubits Random Forest Feature Importance Figure 13: Importance of top 10 InferQ numeric features for SVM and Random Forest trained for optimizing memory. behind the routing outcome in Section 6.2. We therefore analyze feature importance for the best models: XGBoost for runtime and Random Forest for peak memory. We additionally report a Linear SVM to expose the direction of influence via signed coefficients. We also include an ablation study. 6.3.1 SQL-only features. We first restrict to SQL-derived features extracted from output SQL queries representing the generated cir- cuits (Section 4.3, Table 6). Table 9a shows that these SQL-only features already yield strong routing accuracy, especially for time- optimal routing (XGBoost exceeds 92% accuracy on the held-out test set). This indicates that the engine choice is strongly correlated with query shape, without requiring circuit-specific features. We have included more results on dominant SQL signals in Appendix L. 6.3.2 AllInferQfeatures. We then include the full feature set from Section 4. For runtime (Figure 12), for both the Linear SVM and XGBoost, features associated with state growth and interaction intensity are more important, includingshannon_entropy,width, andedge_count, together with the SQL-derived features. With XGBoost, in addition, graph-related features are important, such as average_clustering_coefficient,average_shortest_path_length, andaverage_degree, indicating that irregular interaction structure matters for runtime differences. Table 10: Feature-group ablation for routing (XGBoost) Feature set RuntimeMemory Acc.F1Acc.F1 Static + Graph + SQL + Dynamic 0.95 0.84 0.98 0.98 Static + Graph + SQL0.930.780.970.96 Static + Graph0.920.740.960.95 Static0.920.740.950.94 For peak memory (Figure 13), the Linear SVM and Random For- est agree on the main features:num_qubitsandshannon_entropy dominate, with additional contributions fromwidth,edge_count, de- gree statistics, and sparsity measures. The Random Forest captures non-linear thresholds in these features, separating regimes where sparse relational execution substantially reduces peak memory. 6.3.3 Ablation study. To quantify the contribution of each feature group, we further run a feature-group ablation on the routing task. Table 10 reports the results for XGBoost on the 7705 dataset. The full results with all models are reported in Appendix B. SQL-only features already provide a useful indication, especially for runtime routing, showing that the shape of the generated SQL query work- load is informative. Static, graph and dynamic features improve performance further, while the full feature set gives the best overall accuracy and F1. Take-away. (1) SQL-only features are already strong predictors: the SQL query workload shape (joins, predicates, aggregates) ex- plains much of when an RDBMS should be chosen. This enables follow-up work on SQL-level cost modeling and query optimiza- tion tailored to quantum circuit simulation workloads. (2) When using the full feature set, the top features are consis- tent with the underlying bottlenecks: state growth indicators such as entropies, circuit scale like qubit count and circuit width, and interaction structure (graph features). This supports follow- up work on data-centric models that learn when to use an RDBMS engine and how to optimize execution fromInferQ-generated training data. 6.4Use case 2: Predicting Entropies and Sparsity Dynamic features from Section 4 (Shannon entropy, von Neumann entropy, and sparsity) are only available after simulation, since they are computed from the output state. This limits their use for InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Table 11: Sparsity and Entropy (Dynamic metrics) estimators performance for Random Forest and Linear Regression mod- els. Reported are coefficient of determination (푅 2 ) and root mean squared error (RMSE) comparing predictions to actual values. ModelSparsity ModelEntropy Model Random Forest 푅 2 0.77370.8936 Random Forest RMSE0.19281.9931 Linear Regression 푅 2 0.39340.6956 Linear Regression RMSE0.31563.3714 Figure 14: Predicted vs Actual value for the dynamic feature RF regression estimators for subset (1000 entries) of test set. Figure 15: Distribution of dynamic features over 202k entries in InferQ with Dynamic features. Figure 16: Confusion matrix with counts and normalization for random forest classifier for sparsity band prediction. larger circuits and motivates a second, data-centric use case: learn- ing inexpensive estimators that predict these dynamic properties from static/graph/SQL features. Besides being useful for database researchers (use case 1), these metrics are also fundamental to quan- tum analysis. Q5: Can we estimate complex quantum properties usingInferQfea- tures? We construct estimators forsparsityandshannon_entropyusing 202,975 circuits for which dynamic features are available. 16 We train (i) a Random Forest regressor and (i) a linear regression baseline on an 80/20 train–test split, and evaluate prediction quality using 푅 2 and RMSE as shown in Table 11. As Table 11 shows, Random Forest substantially outperforms the linear model for both targets. Shannon entropy is modeled well by the feature set, while sparsity is harder to regress accurately. This is also visible in the prediction-versus-actual plots in Figure 14. To understand why sparsity is challenging, we inspect its empir- ical distribution (Figure 15). Sparsity is not smoothly distributed. Instead, it concentrates in distinct bands. This suggests treating sparsity as a coarse-grained classification problem. Concretely, we bin sparsity into[0.0,0.1),[0.1,0.2),[0.2,0.4),[0.4,0.6),[0.6,1.01] and train a Random Forest classifier. This yields approximately 77% accuracy, and the normalized confusion matrix is concentrated near the diagonal (Figure 16), indicating thatInferQfeatures capture sparsity even when exact regression is difficult. Finally, feature-importance analysis for the sparsity-band clas- sifier highlightspauli_gate_countas a stronger predictor than num_qubits. This suggests that (in our generated workload) spar- sity is driven more by the gate mix than by state dimension alone, offering a concrete, data-derived signal that can guide both simula- tor design and feature engineering. Take-away. (1)InferQenables learning cheap estimators for expensive dynamic properties (e.g., entropy and sparsity) using only features that do not require simulation. This enables follow-up work on fast, simulation-free predictors of state complexity for larger circuits. (2) The learned models reveal structure in the data (e.g., sparsity bands) and highlight which circuit characteristics are most pre- dictive. This lays a practical foundation for improving estimators (e.g., hybrid classification/regression) and for connecting circuit structure to quantum-state behavior in a data-centric manner. 7 Conclusion InferQ makes SQL-based quantum circuit simulation accessible as a database benchmarking problem: it generates compositional circuits as RDBMS-ready SQL workloads, attaches features that explain relational workload difficulty, and provides both an on- demand toolkit and a large dataset for reproducible analysis. Our evaluation shows that RDBMS engines can be competitive, espe- cially in peak memory across a broad set of general circuits, and that lightweight models trained onInferQfeatures can reliably pre- dict when an RDBMS engine will be preferable. We expectInferQ to enable follow-up work in (i) query optimization and physical design for emitted simulation SQL, and (i) data-centric routing and cost modeling for simulator selection, trained at scale onInferQ- generated circuits and features. 16 Estimator training data (Parquet) available athttps://github.com/InfiniData- Lab/InferQ/blob/main/analysis/training_data/estimator_training_data. parquet. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Outlook. As future work, we plan to further optimize RDBMS- based simulation and develop array-native execution for tensor- aware DBMSs.InferQcan also be extended from circuit genera- tion to end-to-end validation for quantum algorithm design, cover- ing correctness checks, iterative test–debug cycles, and hardware- aware constraints such as native gate sets and device connectivity. Acknowledgments This publication was supported (in part) by Dutch Research Council (VI.Veni.222.439). References [1] Scott Aaronson and Daniel Gottesman. 2004. Improved simulation of stabilizer circuits. Physical Review A 70, 5 (Nov. 2004). doi:10.1103/physreva.70.052328 [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. [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. [4]Medina Bandic, Carmen G. Almudever, and Sebastian Feld. 2023. Interaction graph-based characterization of quantum benchmarks for improving quantum circuit mapping techniques. Quantum Machine Intelligence 5, 2 (Oct. 2023). doi:10.1007/s42484-023-00124-1 [5]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 [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. [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. [8] Gilles Brassard, Peter Høyer, Michele Mosca, and Alain Tapp. 2002. Quantum amplitude amplification and estimation. Contemp. Math. 305 (2002), 53–74. [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). [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. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI). 578–594. [11]Edward Farhi, Jeffrey Goldstone, and Sam Gutmann. 2014. A Quantum Approxi- mate Optimization Algorithm. https://arxiv.org/abs/1411.4028 [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. In Proceedings of the 51st annual ACM SIGACT symposium on theory of computing. 193–204. [13]Rihan Hai, Shih-Han Hung, Tim Coopmans, Tim Littau, and Floris Geerts. 2025. Quantum Data Management in the NISQ Era. PVLDB 18, 6 (2025), 1720–1729. [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 [15]Aram W Harrow, Avinatan Hassidim, and Seth Lloyd. 2009. Quantum Algorithm for Linear Systems of Equations. Physical Review Letters 103, 15 (2009), 150502. [16]Roman Heinrich et al.2025. How Good are Learned Cost Models, Really? Insights from Query Optimization Tasks. SIGMOD 3, 3 (2025), 172:1–172:27. doi:10.114 5/3725309 [17] Javier Martín Hernández and Piet Van Mieghem. 2015. Classification of graph metrics. https://api.semanticscholar.org/CorpusID:37136216 [18]IBM Quantum. 2025. Qiskit: Open-Source Quantum Computing Software.https: //w.ibm.com/quantum/qiskit. Official IBM Quantum page for Qiskit, the world’s most popular software stack for quantum computing and algorithms research.. [19]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). [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 Endowment 9, 3 (2015), 204–215. [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 [22] Tim Littau and Rihan Hai. 2025. Qymera: Simulating Quantum Circuits using RDBMS. In Companion of the 2025 International Conference on Management of Data (SIGMOD/PODS ’25). ACM, 179–182. doi:10.1145/3722212.3725126 [23]Shangyu Luo, Dimitrije Jankov, Binhang Yuan, and Chris Jermaine. 2021. Auto- matic optimization of matrix implementations for distributed machine learning and linear algebra. In Proceedings of the 2021 International Conference on Man- agement of Data (SIGMOD). 1222–1234. [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. [25]Igor L. Markov and Yaoyun Shi. 2008. Simulating Quantum Computation by Contracting Tensor Networks. SIAM J. Comput. 38, 3 (2008), 963–981. [26]John M Martyn, Zane M Rossi, Andrew K Tan, and Isaac L Chuang. 2021. Grand unification of quantum algorithms. PRX quantum 2, 4 (2021), 040203. [27]Michael A Nielsen and Isaac L Chuang. 2010. Quantum Computation and Quan- tum Information. Cambridge university press. [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. [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.. [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.. [31]Nils Quetschlich, Lukas Burgholzer, and Robert Wille. 2023. MQT Bench: Bench- marking Software and Design Automation Tools for Quantum Computing. Quan- tum 7 (July 2023), 1062. doi:10.22331/q-2023-07-20-1062 [32] Wenbo Sun, Qiming Guo, Wenlu Wang, and Rihan Hai. 2025. TranSQL+: Serving Large Language Models with SQL on Low-Resource Hardware. SIGMOD 3, 6, Article 371 (Dec. 2025), 27 pages. [33]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 [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 systems 30 (2017). [35]Yisu Remy Wang, Shana Hutchison, Jonathan Leang, Bill Howe, and Dan Suciu. 2020. SPORES: sum-product optimization via relational equality saturation for large scale linear algebra. Proceedings of the VLDB Endowment 13, 12 (2020), 1919–1932. [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. Data 1, 4 (2023), 255:1–255:27. doi:10.1145/3626769 [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 Endowment 14, 8 (2021). [38]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. AppendixMain content AOut-of-core evaluation and spill behavior. B–CRouting ablations and training/inference overhead. D–ETensor-aware DBMS discussion and support for ex- ternal benchmark suites. F–H SQLite–Aer profiling, DBMS-specific tuning, and physical-design discussion. I–KReproducibility details, generated-workload charac- terization, and subcircuit generation. L–NSQL-only results, preprocessing scalability, imple- mentation details, Qiskit Aer selector, and feature schema. A Out-of-Core Evaluation In this section, we study out-of-core execution for DBMS-backed SQL simulation and address the following question: Q3: Can an RDBMS backend complete simulation queries once the workload no longer fits in main memory? To answer Q3, we conduct two experiments. First, in Section A.1, we generate a family of large circuits with an increasing number of qubits up to 45. Under a fixed memory limit, Qiskit Aer cannot com- plete the simulation, whereas RDBMS engines can spill temporary data to secondary storage and complete execution, demonstrat- ing a clear case when an RDBMS backend is beneficial. Second, in Section A.2, we useInferQto generate circuits with controlled variation in sparsity and study how sparsity, intermediate results, and spill behavior interact. A.1 Large Circuits Simulation Experiment setup. We generate a family of circuits with a fixed structure and similar sparsity, while increasing the qubit count푁 (one circuit for each푁from 1 to 45). These circuits are designed so that the simulation state can be represented compactly as a relation of non-zero entries. These circuits are representative in practice and are a common scenario for structured and sparse quantum circuit simulation workloads (e.g., stabilizer, amplitude amplification, and sparse linear systems). Quantum-specific construction details are provided in Section I.1. We execute the generated SQL queries on PostgreSQL, DuckDB, and SQLite under a 16 GB memory cap. In SQL-based simulation, the tensor-contraction sequence is written as a chain of Common Table Expressions (CTEs), each encoding one contraction step ( join + aggregate). For each query, we record (i) median spill volume over five runs and (i) the maximum and total intermediate relation sizes across the CTE chain. The engine-specific spill configuration is described in Section I.2. Results. Under the 16 GB limit, Qiskit Aer fails to complete exact simulation starting at 30 qubits. This is expected. Recall in Sec. 1 and 200K500K 1M3M CTE size 1 MB 100 MB 1 GB 4 GB Spill r(lrg)=+0.46 r(tot)=+0.66 PostgreSQL 200K500K 1M3M CTE size r(lrg)=+0.32 r(tot)=+0.49 DuckDB 200K500K 1M3M CTE size r(lrg)=+0.38 r(tot)=+0.77 SQLite 40q41q42q43q44q45q LrgTotS-1 Figure 17: Spill volume of RDBMS engines (PostgreSQL, DuckDB, SQLite). Filled points (tot) denote total interme- diate relation size across the CTE chain; open points (lrg) denote the maximum single-step intermediate size. 2.1 we have explained that an푁-qubit state requires 2 푁 complex entries. If we store each complex entry in double precision, this is approximately 16·2 푁 bytes, which reaches roughly 16 GB at푁=30 (ignoring runtime overhead) and grows exponentially thereafter. For the 40–45 qubit circuits evaluated here, Qiskit would require approximately 16–512 TB (this is known as statevector in Qiskit for exact simulation). In contrast, all three RDBMS engines complete all runs because they store the state as tuples and can exploit sparsity: storage scales with the number of non-zero entries rather than with 2 푁 . Figure 17 summarizes out-of-core behavior for the 40–45 qubit circuit simulation under the 16 GB limit. Across engines, interme- diate relation sizes remain in the megabyte range, consistent with RDBMSs’ support for storing sparse tensors. 17 At the same time, total spill volume is often orders of magnitude larger than the sizes of the intermediate relations. This is likely due to the overhead during joins and group-bys (e.g., hash tables, sorting or grouping state, and temporary structures), as well as repeated materialization of intermediates along the CTE chain. We further inspect the Spearman correlation values between spill volume and the maximum single-step intermediate size (푟(lrg)) and the total intermediate size across all CTEs (푟(tot)). In all three engines,푟(tot)> 푟(lrg), indicating that spill is more strongly as- sociated with cumulative intermediate volume than with the peak single-step intermediate. This suggests that optimization opportu- nities include reducing repeated intermediate materialization and improving reuse, for example by caching selected intermediates when they are used multiple times. Figure 18 reports query runtime. Runtime increases rapidly with the number of qubits for all engines. PostgreSQL is consistently the fastest in this experiment, DuckDB is second, and SQLite is the slowest. Figure 19 shows runtime and spill volume are related, indicating that externalization overhead is a major reason for end- to-end query time once operator workspaces spill to disk. 17 We observe different spill behavior across DBMS engines. DuckDB spills the least in this experiment, while SQLite and PostgreSQL are comparable on several circuits. Note that PostgreSQL exposes query-level temporary I/O counters, so we can compute spill volume exactly. DuckDB and SQLite do not expose a stable, query-level temp- bytes-written counter in the same way, so we use a conservative operating-system level proxy for them. Details are provided in Section I.2. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai 404142434445 Number of qubits 2 5 10 20 50 100 Time (s) Runtime Performance (16 GB) PostgreSQL DuckDB SQLite Figure 18: Runtime of RDBMS engines (PostgreSQL, DuckDB, SQLite). 1 MB 100 MB 1 GB4 GB Spill 2 5 10 20 50 100 Time (s) PostgreSQL: r=+1.00 DuckDB: r=+1.00 SQLite: r=+0.94 Spill Impact (16 GB) PostgreSQL DuckDB SQLite Figure 19: Runtime versus spill volume for RDBMS engines (PostgreSQL, DuckDB, SQLite). Takeaways. This experiment demonstrates when DBMS- backed simulation is particularly useful: it enables exact sim- ulation for large circuits that exceed the in-memory limits of Qiskit Aer by combining a sparse tuple-level representation with out-of-core execution. At the same time, spill volume and runtime are closely tied to relational operator workspace and intermediate relation growth, which motivates RDBMS opti- mization opportunities such as join ordering, operator selection, and materialization control to reduce externalization overhead. A.2 Experiment on Varying Sparsity The previous experiment indicates that sparse representations can make DBMS-backed simulation more useful under a memory limit. We therefore conduct a second experiment on InferQ-generated workloads to study how spill volume, intermediate CTE sizes, and query runtime relate to the sparsity of a circuit. This is possible because InferQ can generate circuits with controlled variation in sparsity. We first explain the sparsity of the final output state of a circuit simulation. For an푛-qubit circuit, the output is a length-2 푛 ampli- tude vectorp. We define output density as the fraction of non-zero entries in the vectorp against the vector size|p|: density(p)= | 푖 | 푝 푖 ≠ 0 | |p| . A smaller density indicates fewer non-zero tuples in the DBMS representation, while a density close to 1 indicates a near-dense output. Experiment setup. We construct a sample of 17 InferQ circuits 18 spanning three density bands: Sparse[0,0.33), Medium[0.33,0.67), and Dense[0.67,1.0]. The circuits span a number of qubits from 20 to 23. We execute the SQL simulation on PostgreSQL, DuckDB, and SQLite under a 16 GB memory cap. For each run, we record spill vol- ume, wall-clock runtime, and the maximum and total intermediate CTE sizes observed over the CTE chain. Results. Figure 20 plots spill volume against the number of qubits. Across all engines, circuits in the Sparse band tend to incur the least spill, and PostgreSQL often shows negligible spill for the sparsest cases. This matches the intuition that a sparse output can be represented as a smaller relation, reducing memory pressure and temporary-workspace needs. From Figure 20, we observe that output density alone does not de- termine spill volume. For PostgreSQL and SQLite, several Medium- density circuits spill more than some Dense circuits at similar qubit counts. This indicates that spill is strongly influenced by interme- diate results produced during query execution, which depend on plan choices such as join ordering and materialization behavior, rather than being determined solely by the final output density. Figure 21 reports the maximum and total intermediate CTE sizes as a function of output density. The correlations are consistently positive across engines, and the maximum-intermediate correlation is slightly stronger than the total-intermediate correlation. At the same time, intermediate sizes vary across DBMS engines for the same circuit, which is expected because optimizers may choose different join orders and physical operators, leading to different intermediate growth. Finally, Figure 22 shows runtime versus spill volume. PostgreSQL and SQLite show a very strong positive association between exe- cution time and spill (rank correlations shown in the figure), and DuckDB exhibits a weaker but still positive association. This re- sult indicates that externalization cost is a dominant reason for end-to-end runtime once operators spill to disk. Takeaways. It shows that DBMS out-of-core behavior is gov- erned primarily by intermediate relation growth and operator workspace, which depend on workload structure and DBMS plan choices, rather than only on the density of the final output. It motivates optimizing SQL-based simulation using standard DBMS techniques such as improving join ordering, control- ling materialization, and reducing intermediate blow-up. It also suggests that spill-aware cost models are useful for predicting when a DBMS will benefit from out-of-core execution and when externalization overhead will dominate in future work. 18 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/sample _csvs/final_sparse_sample.csv InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation 20212223 10 KB 100 KB 1 MB 10 MB 100 MB 1.0 GB 10.0 GB Spill (log scale) PostgreSQL 20212223 DuckDB 20212223 SQLite Number of qubits Sparse [0, 0.33)Medium [0.33, 0.67)Dense [0.67, 1.0] Figure 20: Spill volume with varying numbers of qubits (log scale). 0.00.51.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.00.51.0 ρ(tot)=+0.62 ρ(lrg)=+0.65 DuckDB 0.00.51.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 CTEsLargest CTE Figure 21: Maximum and total intermediate CTE sizes against output state sparsity (log scale). 100 MB10.0 GB 0.1 1 10 100 Time (s) ρ = +0.99 PostgreSQL 1 MB10 MB ρ = +0.63 DuckDB 1 MB100 MB ρ = +0.98 SQLite Spill Sparse [0, 0.33)Medium [0.33, 0.67)Dense [0.67, 1.0] Figure 22: Execution time versus spill volume for sampled InferQ circuits (log-log). B Ablation Study of InferQ Feature groups We conduct a feature-group ablation study on the 7705 dataset. Tables 13 and 14 report the performance of five models (Logistic Regression, Linear SVM, Decision Tree, Random Forest, and XG- Boost) for runtime- and memory-optimal routing, respectively. We observe that combining all feature groups yields the best overall performance. In some cases, such as Logistic Regression in Table 14, adding dynamic features also leads to a noticeable improvement. C Training and Inference Time We report the computational cost of each classifier under the all- features setting. Table 15 reports training and inference time sepa- rately for runtime- and memory-optimal routing, with all values in seconds. Training time is measured over 6,164 training samples, whereas inference time is measured over 1,541 test samples; there- fore, the two measurements should be interpreted independently rather than compared directly. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 13: Ablation study for time-optimal method prediction (80% - 20% train-test split). Bold: best overall result (XGB, full feature set); underline: second best (RF, full feature set). Acc: accuracy; F1: macro F1-score. LRSVMDTRFXGB Feature SetAccF1AccF1AccF1AccF1AccF1 SQL0.79 0.54 0.80 0.57 0.91 0.70 0.93 0.750.920.75 Static0.80 0.55 0.80 0.55 0.90 0.68 0.92 0.720.920.74 Static + Graph0.84 0.60 0.81 0.56 0.90 0.66 0.92 0.730.920.74 Static + SQL0.86 0.64 0.86 0.65 0.93 0.76 0.94 0.780.940.80 Static + Dynamic0.86 0.66 0.86 0.65 0.92 0.73 0.94 0.770.940.79 Static + Graph + SQL0.87 0.67 0.84 0.62 0.92 0.74 0.94 0.780.930.78 Static + Graph + SQL + Dyn. 0.89 0.70 0.88 0.69 0.94 0.80 0.950.830.95 0.84 Table 14: Ablation study for memory-optimal method prediction (80% - 20% train-test split). Bold: best overall result (XGB, full feature set); underline: second best (RF, full feature set). Acc: accuracy; F1: macro F1-score. LRSVMDTRFXGB Feature SetAccF1AccF1AccF1AccF1AccF1 SQL0.75 0.72 0.75 0.72 0.83 0.79 0.86 0.820.850.81 Static0.87 0.85 0.87 0.84 0.93 0.92 0.95 0.930.950.94 Static + Graph0.90 0.87 0.89 0.87 0.93 0.91 0.96 0.940.960.95 Static + SQL0.89 0.87 0.89 0.87 0.94 0.93 0.96 0.950.970.96 Static + Dynamic0.94 0.92 0.94 0.93 0.95 0.94 0.97 0.960.970.97 Static + Graph + SQL0.90 0.88 0.90 0.88 0.94 0.92 0.97 0.960.970.96 Static + Graph + SQL + Dyn. 0.94 0.93 0.94 0.93 0.96 0.95 0.98 0.970.98 0.98 Combining these results with the accuracy and F1 results in Tables 13 and 14, we observe that XGBoost provides the best over- all trade-off between predictive performance and inference effi- ciency. Although Decision Trees have the lowest inference time for both routing tasks, requiring 0.0102 s for runtime-optimal rout- ing and 0.0098 s for memory-optimal routing, XGBoost achieves substantially higher accuracy and F1 score while remaining highly efficient at inference time. Compared with Random Forest, the second strongest classifier in predictive performance, XGBoost is considerably faster during inference: 0.0139 s versus 0.1319 s for runtime-optimal routing and 0.0135 s versus 0.1076 s for memory- optimal routing, measured over the same 1,541 inference samples. XGBoost also maintains moderate training cost, requiring 0.36 s and 0.34 s for runtime- and memory-optimal routing, respectively. These results further support our use of XGBoost as the routing model. D Tensor-Aware DBMSs Beyond the RDBMS engines used in the main evaluation, tensor- aware DBMSs such as TileDB and SciDB are natural candidates for quantum circuit simulation. They expose array-oriented stor- age and execution abstractions that appear well matched to tensor contractions. However, using them fairly requires significant ef- fort becauseInferQcurrently emits SQL workloads whose core operations are joins and aggregations. TileDB is an array storage engine for dense and sparse multi- dimensional arrays. 19 A direct TileDB evaluation would require an array-native implementation of the simulator: one would need to choose array schemas, chunk sizes, qubit-index layouts, and contraction kernels, rather than executing the same SQL workload 19 TileDB documentation:https://docs.tiledb.com/main/. TileDB-Py API:https: //tiledb-inc-tiledb.readthedocs-hosted.com/projects/tiledb-py/en/st able/python-api.html. Table 15: Training and inference time under the all-features setting using an 80%–20% train-test split. All values are total elapsed time in seconds. Training was measured over 6,164 samples, while inference was measured over 1,541 samples. Bold: lowest value;underline: second-lowest value within each section and routing setting. Training time over 6,164 samples (s) Model Runtime-Optimal Routing Memory-Optimal Routing LR0.120.07 SVM1.800.90 DT0.100.10 RF0.790.72 XGB0.360.34 Inference time over 1,541 samples (s) Model Runtime-Optimal Routing Memory-Optimal Routing LR0.01540.0139 SVM0.19510.0943 DT0.01020.0098 RF0.13190.1076 XGB0.0139 0.0135 used by PostgreSQL, SQLite, and DuckDB. The closest SQL-oriented possibility,TileDB-MariaDB/MyTile, is deprecated and supports only limited pushdown, which makes it unsuitable as a fair drop- in replacement for our join-and-aggregate SQL workload. 20 We therefore do not include TileDB in the timing comparison. We view a TileDB-native implementation as important future work rather than a direct backend substitution. SciDB is closer to our setting because it provides array operators and a query interface for composing them. 21 SinceInferQemits 20 TileDB-MariaDB/MyTile documentation:https://github.com/TileDB-Inc/Ti leDB-MariaDB. 21 SciDB-Py documentation:https://paradigm4.github.io/SciDB-Py/guide.htm l. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation 3.03.54.04.55.05.56.06.57.0 num_qubits 10 4 10 3 10 2 10 1 10 0 med time Time vs qubits ducksql np-mps np-one-shot psql scidb sqlite umbra sparse (0-0.33) mixed (0.33-0.67) dense (0.67-1.0) 10 4 10 3 10 2 10 1 10 0 med time Time vs sparsity ducksql np-mps np-one-shot psql scidb sqlite umbra 46810121416 num_gates 10 4 10 3 10 2 10 1 10 0 med time Time vs gates ducksql np-mps np-one-shot psql scidb sqlite umbra 3.03.54.04.55.05.56.06.57.0 num_qubits 10 4 10 5 med mem Memory vs qubits ducksql np-mps np-one-shot psql scidb sqlite umbra sparse (0-0.33) mixed (0.33-0.67) dense (0.67-1.0) 10 4 10 5 med mem Memory vs sparsity ducksql np-mps np-one-shot psql scidb sqlite umbra 46810121416 num_gates 10 4 10 5 med mem Memory vs gates ducksql np-mps np-one-shot psql scidb sqlite umbra DB performance trends median +/- min/max band across circuits top: time (s) | bottom: memory (KB) 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 as one nested array expression. In practice, the generated expressions become large and fragile for full circuits, so our pro- totype splits the simulation at tensor contraction boundaries and materializes intermediate arrays. This makes the prototype robust, but it removes some global optimization opportunities available to RDBMSs when they optimize a CTE chain. Thus, please consider the results below as preliminary results rather than as results from a fully optimized SciDB implementation. Experimental setting. Figure 23 reports a comparison on 11 InferQcircuits 22 with 3–7 qubits and 4–17 gates, spanning sparse, mixed, and dense output-density bins. We compare PostgreSQL, DuckDB, SQLite, Umbra, SciDB, and two NumPy baselines:np-one-shot, an exact tensor-contraction baseline, andnp-mps, an MPS-based approximate baseline. Results. We have two main observations from Figure 23. First, among DB-backed methods, SQLite remains the strongest backend. It beatsnp-one-shotin peak memory for all 11 circuits and in runtime for 4 of the 11 circuits. PostgreSQL and Umbra remain competitive in memory but are slower than SQLite. Second, the direct SciDB prototype has substantial overhead: it is consistently 22 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/sample _csvs/small_sample_scidb.csv slower and uses more memory than the RDBMS backends on these small circuits. Thenp-mpsbaseline is often fast, but it is approxi- mate, whereas the DB-backed methods andnp-one-shotare exact strong simulators. Take-away. Tensor-aware DBMSs are promising, but they are not plug-in replacements for the SQL workload studied in this paper. To make TileDB or SciDB competitive for quantum circuit simulation, future work should co-design the simulator with the array engine, including: (i) qubit-index layout and chunking, (i) sparse-versus-dense array selection, (i) contraction fusion to avoid per-step materialization, and (iv) cost models for array- native execution. It is an interesting future direction to explore which types of simulation workloads array DBMSs would be most promising for. E Support for Existing Benchmarks In addition to circuits generated byInferQ, the evaluation pipeline can ingest circuits from established benchmark suites: SupermarQ [33], MQT Bench [31], and QASM Bench [21]. These suites provide work- loads that complement our generated corpus. The compositional circuit simulation workload introduced in Sec. 3 remains necessary for controlled simulation scale, feature-space coverage, and repro- ducible randomized workload generation, while external suites Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 16: External benchmark-suite circuit entries supported by theInferQingestion pipeline. Per-suite counts are before cross-suite deduplication. Benchmark suite# circuit entries SupermarQ8 MQT Bench34 QASM Bench67 Total (after deduplication)85 provide an additional validation source based on named benchmark circuits. All imported circuits are normalized to QiskitQuantumCircuit objects and tagged with their source suite and benchmark name. The ingestion pipeline then applies the same SQL generation, fea- ture extraction, and the rest of the workflow used forInferQ- generated circuits. As a result, external-suite circuits can be queried, filtered, and evaluated together with generated circuits under the same RDBMS, simulator-selection, and out-of-core workflows. The per-benchmark counts in Table 16 are before deduplication. Since the three benchmark suites contain overlapping algorithm families and problem-size variants,InferQalso records a dedu- plicated inventory; after deduplication, the external benchmark inventory covers 85 unique algorithm families. The complete per- suite circuit-family list and ingestion commands are provided in the Benchmark Algorithms table in the online documentation. 23 F Profiling of SQLite and Qiskit Aer To understand why SQLite uses less peak memory than Qiskit Aer on many circuits, we profile both systems on 162 generated circuits. 24 For SQLite, each circuit is compiled into a tensor-contraction pro- gram represented as a chain of Common Table Expressions (CTEs). Each contraction step is implemented as a join followed by an ag- gregation. We record the number of total and contraction CTEs, estimated intermediate-relation sizes, result cardinalities, SQLite execution-plan operators, temporary B-tree usage, automatic-index usage, page-cache overflow counters, peak resident set size (RSS), and wall-clock runtime. For Qiskit Aer, we compare against the fastest Aer method for runtime, rather than fixing a single simulator representation across all circuits. For memory, we compare against the lowest-RSS Aer configuration for the same circuit. The profiling results 25 in Table 17 characterize when each system is faster. Across 162 circuits, SQLite is faster in 46 cases, while Qiskit Aer is faster in 116 cases. SQLite is faster when the relational workload remains small: the median SQLite-winning circuit has 26.5 total CTEs, 22 contraction CTEs, the largest intermediate relation of 256 B, and 16 final result rows. In these cases, SQLite runs in a median of 2.03 ms, compared with 2.82 ms for the fastest Aer method. In contrast, when Aer is faster, the median workload is 23 https://github.com/InfiniData-Lab/InferQ/blob/main/scripts/benchma rk_suites/README.md 24 We have sampled these 162 circuits from the large 7,705 circuits used in Section 6. This profiling comparison is separate from the all-backend tuned winner count reported in Figure 7 and Appendix G. 25 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/memory _profiling/sqlite_vs_qiskit_summary.csv Table 17: Median properties of completed SQLite–Aer profil- ing runs, grouped by the backend with lower runtime. CTE sizes are estimated from intermediate-relation cardinalities and row widths. SQLite fasterAer faster Number of cases46116 Total CTEs26.555 Contraction CTEs2249 Total estimated CTE size2.9 KB10.5 KB Largest intermediate CTE256 B1.0 KB Final result rows16128 SQLite runtime2.03 ms6.63 ms Fastest Aer runtime2.82 ms3.09 ms larger: 55 total CTEs, 49 contraction CTEs, a largest intermediate relation of 1.0 KB, and 128 final result rows. In these cases, SQLite takes a median of 6.63 ms, while Aer takes 3.09 ms. These results show that SQLite’s advantage is not determined by qubit count alone. Some SQLite-winning circuits have more qubits than Aer-winning circuits, but their relational intermediates remain small. The decisive factor is the size and structure of the induced SQL workload. When the tensor-contraction sequence pre- serves sparsity, SQLite materializes only a small number of nonzero amplitudes, and the join-and-aggregate pipeline can complete be- fore Aer’s method setup and simulation overheads dominate. For such circuits, the sparse SQL representation provides a compact representation of the circuit state. The same representation becomes less favorable once the con- traction pipeline grows. Longer CTE chains introduce repeated joins, aggregations, and intermediate execution structures. SQLite query plans use temporary B-trees for grouping in all completed runs and automatic indexes for joins in 154 out of 162 runs. These are standard relational execution mechanisms, but in a long contrac- tion sequence their cumulative cost can dominate the arithmetic. Thus, when Aer is faster, it is not because SQLite fails to repre- sent the computation; rather, the relational execution machinery becomes the bottleneck. The memory measurements follow a different pattern from the runtime measurements. Among the 162 circuits, SQLite uses less peak RSS than the lowest-RSS Aer method in 139 cases. Median peak RSS is 203 MB for SQLite and 206 MB for Aer. This difference is small in absolute terms for these circuits, but it is consistent with SQLite benefiting from storing sparse relational intermediates rather than allocating the simulator representation used by Aer. At the same time, this memory advantage does not automatically translate into a runtime advantage, because SQLite still pays the cost of repeated SQL execution. The SQLite-specific profiling counters support this interpreta- tion. The page-cache overflow counter is zero in all completed runs, and we do not observe external-sort behavior. Thus, the slowdown is not explained by observed out-of-core execution in these runs. Instead, the dominant cost is the repeated construction and con- sumption of temporary B-trees and automatic indexes across the CTE chain. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Unlike the RDBMS backends, Aer’s performance depends strongly on which simulator method is applicable and efficient for each cir- cuit. In the profiling runs, the fastest Aer method varies across circuits:unitaryis fastest in 46 cases,automaticin 42 cases, statevectorin 37 cases,extended\_stabilizerin 26 cases,ma trix\_product\_statein 5 cases,density\_matrixin 4 cases, andstabilizerin 2 cases. This indicates that a single fixed Aer method is not a stable baseline for heterogeneous circuits. Some circuits admit efficient specialized simulation, while others require a more general representation. For peak memory, the lowest-RSS Aer configuration is usuallystatevectorordensity\_matrix: statevectorhas the lowest RSS in 88 cases,density\_matrixin 49 cases,automaticin 14 cases,matrix\_product\_statein 9 cases, and unitary in 2 cases. We do not enable Aer cache blocking in this comparison. Our Aer baseline uses the standard CPU simulator methods, whereas Aer’s cache-blocking options (e.g.,blocking_enableandblocking_qubits) are documented for distributed GPU and/or multi-node simula- tion [30]. They partition the state into chunks to reduce data ex- change across distributed memory spaces, rather than providing a disk-backed CPU cache comparable to an RDBMS buffer man- ager. Enabling these options would therefore change the simulator configuration instead of providing a fair comparison to SQLite’s relational execution. Takeaway. The relative performance of SQLite and Qiskit Aer is governed by both representation and execution strategy. SQLite is memory-efficient when sparsity keeps intermediate relations small, but Aer is faster once repeated joins, aggregations, tem- porary B-trees, and automatic indexes make SQL execution overhead dominate the contraction pipeline. G DBMS-Specific Tuning To understand how DBMS configuration affects simulation per- formance, we have added DBMS-specific tuning for PostgreSQL, DuckDB, and SQLite. 26 We keep the circuit set and InferQ ’s SQL generation pipeline unchanged and only vary DBMS-level configu- ration. Automated tuning via configuration search. We initially ex- plored manual tuning to understand the impact of major parame- ters, but the configuration space is large, engine-specific, and not scalable across thousands of circuits. We therefore adopt an auto- mated configuration-search workflow based on MLOS (Machine Learning for Operating Systems) 27 : the workload is fixed, and the tuner searches over DBMS parameters to minimize runtime. For reproducibility, we document the parameter spaces, seed profiles, and runner details in Section I. Workload-specific tuning. In preliminary experiments, we ob- served that a single global configuration is suboptimal: circuits 26 We did not include Umbra in the DBMS-specific tuning study because its publicly available documentation for the released Docker image only describes basic access through the PostgreSQL-compatible server and command-line interface, and we could not identify a stable, documented set of engine-level tuning parameters needed to define a reproducible configuration-search space:https://hub.docker.com/r/umb radb/umbra 27 https://github.com/microsoft/MLOS induce heterogeneous query shapes (e.g., short vs. long CTE chains) and different bottlenecks (overhead-dominated vs. memory- and I/O-dominated). We therefore introduce workload stratification by circuit size. For the 162-circuit all-engine MLOS validation set, 28 we split circuits by the mediancircuit_size(33 gates): circuits with circuit_size≤33 use asmall_sizeprofile (82 circuits) and the remaining circuits use alarge_sizeprofile (80 circuits). This al- lows the tuner to select configurations appropriate for structurally different workloads of small and large circuits. Table 18 summa- rizes the final profiles. We observed that SQLite did not obtain much performance gain from automatic tuning, so we have tuned it manually 29 . Results. Table 19 reports results after tuning on the 162-circuit dataset, which are also the results for Figure 7. Overall, Qiskit Aer remains the runtime winner on most circuits (128/162). Among the evaluated DBMS backends, only SQLite achieves runtime wins (34/162); DuckDB, PostgreSQL, and Umbra do not win on runtime on this subset. In contrast, SQLite is the peak-memory winner on 108/162 circuits (66.7%), while Qiskit Aer wins peak memory on 54/162 circuits. We have also evaluated the tuned configurations on the full 7,705-circuit dataset (Figure 1). The result is similar: RDBMS backends achieve the lowest runtime on 1,101 circuits (14.3%), and all of these runtime wins come from the SQLite, for which tuning did not have much improvement. For peak memory, RDBMS backends win on 3,902 circuits (50.6%), dominated by tuned SQLite (3,901 wins) with one additional win by Umbra. Relative to the untuned setting, tuning increases SQLite’s peak-memory win count from 3,196 to 3,901 circuits. Take-away. Taken together with Appendix A (out-of-core) and Appendix F (memory profiling), these results suggest two concrete future optimization opportunities for DBMS-backed simulation. i) For large circuits where memory is the bottleneck, DBMS execution is uniquely useful because it can externalize operator workspaces and intermediate relations. For such simulation, end-to-end performance is largely driven by spill and interme- diate growth, motivating spill-aware planning (join ordering, operator selection, and materialization control) and physical design studies over intermediate tables (indexes, partitioning and layout, and caching reused intermediates) as discussed in Appendix H. i) For small circuits where Aer finishes in milliseconds, DBMS runtime is often dominated by fixed overheads (SQL compi- lation, planning, and repeated query execution), motivating workload-level optimizations such as batching, reuse, and han- dling repeated subcircuit computations across many runs. InferQis a convenient tool for future database research in these directions, because it generates controlled workloads (small or large, sparse or dense) and emits database-native SQL along with query-shape and circuit metadata needed for systematic evaluation. 28 https://github.com/InfiniData-Lab/InferQ/blob/main/analysis/traini ng_data/rdbms_all_methods_training_data.parquet 29 Tuning results for the 7705 dataset can be found here:https://github.com/Infin iData-Lab/InferQ/blob/main/analysis/finetuned/rdbms7705_sqlite_stati c_contr/rdbms7705_sqlite_static_contr_results.csv Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 18: Database-specific tuning settings used for the 7,705-circuit evaluation. EngineProfileParameters DuckDB small_size memory_limit=10780MB; threads=2; preserve_insertion_order=false; max_temp_directory_size=256GB DuckDB large_size memory_limit=7409MB; threads=1; preserve_insertion_order=true; max_temp_directory_size=128GB SQLite small_size cache_mb=64; db_path=:memory:; mmap_mb=0; temp_store=MEMORY; threads=1 SQLite large_size cache_mb=128; file-backed database; mmap_mb=128; temp_store=MEMORY; threads=1 PostgreSQL small_size work_mem=256MB;temp_buffers=128MB;effective_cache_size=8GB;hash_mem_multiplier=2.0;max_parallel_workers_per_gather=4; join_collapse_limit=1; from_collapse_limit=1; jit=off PostgreSQL large_size work_mem=55MB;temp_buffers=65MB;effective_cache_size=2GB;hash_mem_multiplier=1.94;max_parallel_workers_per_gather=0; join_collapse_limit=4; from_collapse_limit=1; jit=off Table 19: Tuned DB performance on the 162 circuits. Time and peak-memory wins are counted against the best success- ful Qiskit Aer method per circuit. BackendTime wins Memory wins SQLite34/162108/162 DuckDB0/1620/162 PostgreSQL0/1620/162 Umbra0/1620/162 RDBMS total34/162108/162 Qiskit Aer total128/16254/162 H Indexes, partitioning, and CTE query structure InInferQ, each circuit is compiled into a single SQL statement of the formWITH ... SELECT, where each tensor contraction step is represented as a Common Table Expressions (CTE) and imple- mented as a join followed by an aggregate, consistent with prior SQL-based formulations [6,13]. This CTE-chain representation is useful because it makes the contraction order explicit and exposes the workload to the DBMS optimizer as a sequence of standard relational operators (joins and group-bys). However, it also lim- its classic physical design actions: intermediate CTE results are not persistent relations, so users cannot directly create secondary indexes, define table partitioning, or maintain materialized views over those intermediates. Instead, the engine may build transient internal structures (e.g., SQLite’s automatic indexes and temporary B-tree structures), but these are optimizer-managed and not user- controlled. To enable explicit physical design, we added a second query generator which lowers the same contraction pipeline into a sequence ofCREATE TEMP TABLE ASstatements; each intermediate becomes a first-class relation on which indexes and partitioning can be applied. Note that this is not part ofInferQ’s standard pipeline; we added it to support the experiments in this section. Systemati- cally exploring index and partition selection for these intermediate relations is a natural direction for future work. Implications for physical design. The tuned profiles in Table 18 provide a reproducible baseline that isolates DBMS-level execution effects (memory budgeting, temporary-workspace management, parallel execution, and planner constraints) for this workload. Com- bined withsplitexecution, they also define a concrete path for future physical design studies using standard database methodol- ogy. For example, one can treat intermediate tables as design objects and evaluate: (i) index selection on join keys for contraction steps (e.g., B-tree or hash indexes depending on the engine and operator), (i) partitioning and layout decisions to improve join locality and reduce spill (where the engine supports partitioned tables and par- titionwise planning), and (i) selective materialization and caching of frequently reused intermediates (e.g., repeated subcircuits) as materialized relations. BecauseInferQexposes circuit features and query-shape metadata (e.g., number of contraction steps (CTEs), runtime, and spill proxies), these choices can be studied system- atically as physical design problems across engines and workload regimes. Preliminary Results. We have conducted an experiment similar to Appendix A under a 4 GB memory limit. We choose a dense circuit from existing benchmarks, namely QFT, and vary its qubit count from 3 to 26. Except for DuckDB at 26 qubits, all simulations com- pleted. We observe that the new query generator, which forces CTE materialization, reduces runtime by roughly 2.1×for DuckDB and 1.8× for PostgreSQL; SQLite is essentially unchanged. This shows that CTE materialization can be a potentially effective approach for improving DBMS-backed simulation on dense workloads under tight memory limits. I Additional Configuration Details on Experiments for Reproducibility This section documents how we measure spilling performance and how we execute tuned runs. I.1 Circuit Construction Details We design a circuit family with large qubit counts but fixed sparse values. Each circuit is parameterized by(푛,ℎ), where푛is the num- ber of qubits andℎ< 푛is a small seed size. The construction applies Hadamards only to theℎseed qubits and then applies only CNOT layers, which preserve support size; therefore the final state has exactly 2 ℎ non-zero amplitudes in the computational basis. We eval- uate a sample of Expander circuits with푛 ∈ [40,45], where a dense statevector would require approximately 16–512 TB. An Expander circuit on푛qubits is parameterized by a seed sizeℎ< 푛. We apply Hadamards to the firstℎqubits to create a superposition over 2 ℎ basis states and initialize the remaining qubits to|0⟩. We then apply only CNOT layers, which are reversible linear transformations and preserve the number of basis states in support. Consequently, the final state remains a uniform superposition over an affine subspace of dimensionℎand has exactly 2 ℎ non-zero amplitudes in the com- putational basis (each with magnitude 2 −ℎ/2 ). Figure 24 illustrates the circuit structure. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Figure 24: Expander circuit structure: Hadamards onℎseed qubits followed by CNOT-only layers that expand connectiv- ity while preserving sparse support. Such sparse or highly structured states occur in practice in affine and stabilizer-style subroutines and in workloads where computa- tion is restricted to a low-dimensional subspace. Moreover, even when the final state is dense, intermediate tensors and relations dur- ing contraction can be much smaller than 2 푛 . Separately, amplitude- amplification procedures (e.g., Grover-style iterations) tend to con- centrate probability mass onto a small subset of basis states as they iterate, and sparse Hamiltonians and sparse linear systems (as in eigensolver and HHL-style routines) often induce structured ten- sors. These regimes motivate studying DBMS backends with sparse representations and out-of-core execution. I.2 Spill Configuration for Out-of-core experiments We run SQL queries on PostgreSQL, DuckDB, and SQLite, sweeping Docker memory limit, e.g., 16 GB. All containers use a one-CPU quota, swap is disabled by setting Docker–memory-swapequal to the memory cap, and host page cache is not explicitly dropped between runs. DuckDB uses one thread and setsmemory_limitto the cap minus a 1024 MB headroom pad (3072, 7168, and 15360 MB for the 4, 8, and 16 GB caps, respectively). SQLite uses a 64 MB cache budget for both main and temporary schemas. PostgreSQL uses the tuned PostgreSQL 12.22 container, with the server container capped at the experiment memory limit andtemp_file_limitset to 64 GB. Spill is measured aspostgres_explain_temp_written for PostgreSQL and asproc_io_write_bytesfor DuckDB and SQLite. We report spill volume using engine-specific sources when avail- able, and otherwise use a conservative operating system level proxy. PostgreSQL. We compute exact temporary spill bytes fromEXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) by converting the reported temp written/read blocks to bytes using the 8192-byte block size; we treat this value as the per-query externalization metric. DuckDB. We useproc_io_write_bytesas the primary spill/workspace proxy, and when available we additionally parse DuckDB profil- ing JSON fields such astemporary_storage_bytesandspilled_ bytes for diagnostics only, since the profile schema can vary across versions. SQLite. Similar to DuckDB, here we useproc_io_write_bytesas the spill/workspace proxy. SQLite does not expose a stable query- level temp-byte counter through Python’ssqlite3interface, so we intentionally do not report a DB-native temp metric. I.3 Configuration for DB tuning We add a dedicated runner underscripts/finetuned_rdbmsthat reuses the same InferQ circuits and SQL generation path, but exe- cutes the emitted SQL under engine-specific configurations rather than untuned defaults. The same directory contains an automated tuning script (mlos_tune_rdbms.py) based on MLOS. MLOS keeps the workload fixed (each circuit is compiled once into a SQL query) and searches only over DBMS configuration pa- rameters. For each engine, the tuner evaluates seed profiles (e.g., balanced,fast,spill_safe) and then uses a black-box optimizer backend (e.g., FLAML or SMAC) to propose additional configura- tions. Its objective is the median runtime on a pilot set; timeouts and execution failures receive a large penalty. All trials are recorded in mlos_trials.csv, and the best configuration per engine is stored inmlos_best_configs.json. These winning configurations are then validated on the full discovered circuit set via the fine-tuned runner using–tuning-json. Thus, the reported improvements correspond to DBMS-level physical execution choices rather than changes to the circuit generator or SQL compilation. Operationally, the runner generates SQL once per circuit, records query-shape metadata (e.g., number of CTEs/contraction steps), and then executes the workload under the selected engine profiles with warm-up and timed runs, configurable timeouts, and resume support. To reduce total tuning cost, we optionally use SQLite as a lightweight gate: if SQLite times out for a circuit under the tuned profile, we mark other engines asskipped_sqlite_timeoutfor that circuit (i.e., we do not spend additional compute on circuits already rejected by the gate). This produces a controlled comparison of tuned physical execution while keeping the workload and SQL generation fixed. Table 18 reports the best configurations selected and validated by our tuning workflow. For DuckDB,small_sizeallocates a larger memory budget and modest parallelism for short query plans, while disabling insertion-order preservation to enable spill-capable operator choices;large_sizereduces memory and parallelism to limit concurrent memory pressure and temp-space exposure for deeper plans where planner/executor overhead can dominate. For SQLite,small_sizekeeps the database and temporaries fully in-memory to avoid filesystem overhead, whereaslarge_size uses a file-backed database with a modest mmap window to sta- bilize larger intermediate results while still keeping temporaries in memory. For PostgreSQL,small_sizeincreases per-node mem- ory (work_mem,temp_buffers) and enables parallel workers to accelerate small contractions, while constraining join enumera- tion (join_collapse_limit/from_collapse_limit) to preserve the emitted join order and disabling JIT;large_sizecaps per-node memory and disables parallel gather to reduce worker amplification and make externalization behavior more predictable. Finally, we include Umbra via its PostgreSQL-compatible frontend to broaden the engine comparison to a modern compiled analytical DBMS without changing the SQL workload. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai J Generated Circuit Characterization To make the generated workload distribution transparent and re- producible,InferQrecords per-circuit metadata for each gener- ated circuit and aggregates these fields over the full corpus. Fig- ures 25, 26, and 27 summarize the resulting 202,975-circuit inventory from complementary perspectives: gate mix, static circuit structure, width/depth coverage, and interaction-graph structure. Together, these summaries show that the generator produces a broad work- load rather than a collection of circuits that differ only in size. Gate-mix distribution. Figure 25a reports the top-20 gate types by share of total gate count. The corpus has a substantial entan- gling component:cxalone accounts for 26.6% of all gates, alongside common one-qubit rotations and Clifford-style operations such as ry,x,h, andrz. The remaining top gates include controlled-phase, controlled-Z, multi-controlled-X, swap, and higher-controlled vari- ants, indicating that the generated workload includes both simple local transformations and larger multi-qubit control patterns. Static circuit structure. Figure 26 expands the view from gate identities to circuit-level structure. The generated corpus spans small and moderate-width circuits, with median values of 14 qubits, width 16, depth 59, and circuit size 190. It also varies substantially in two-qubit-gate count and two-qubit-gate percentage, which are important because they influence both tensor contraction structure and the amount of intermediate state growth during simulation. Additional static descriptors such as Pauli-gate count, locality ra- tio, idling score, and density score capture whether a circuit is mostly local or contains broader qubit interactions and idle regions. These distributions make the benchmark more informative than a width/depth grid alone. Depth/width coverage. Figure 25b shows the joint coverage over number of qubits and circuit depth. The heat map reports the num- ber of circuits in each (number of qubits, depth) bin using a loga- rithmic color scale, exposing both dense regions of the generated space and sparsely populated edge cases. The workload includes shallow circuits, deep circuits with depths above 10 3 , and circuit sizes extending to roughly 30 qubits in this corpus. This joint view is useful for interpreting performance results because simulator and DBMS behavior can change sharply when both width and depth increase, even when either feature alone appears moderate. Interaction-graph structure. Figure 27 characterizes the qubit interaction graphs induced by the generated circuits. We construct an interaction graph by treating qubits as vertices and adding an edge when two qubits participate in a multi-qubit operation. The re- sulting features include edge count, maximum and average degree, clustering coefficient, shortest-path statistics, diameter, radius, cut- related measures, central-point dominance, and adjacency-matrix variation. These graph features capture structure that is not visi- ble from gate count, width, or depth alone: two circuits with the same number of qubits and a similar depth can still differ substan- tially in interaction density, path length, graph diameter, or degree distribution. Such differences affect SQL query shape, contraction opportunities, intermediate-result sizes, and simulator behavior. Overall, these summaries make the generated workload trans- parent, reproducible, and analytically useful. WithInferQ, users can inspect the concrete properties that shape simulation perfor- mance, including gate composition, static circuit size, depth/width coverage, and qubit-interaction topology. This allows engine com- parisons to be interpreted in terms of the circuits being simulated and helps identify which circuit families require particular simula- tion strategies. K Subcircuit generation In Section 3 we mentioned how to generate a subcircuit. Here, we provide more details. Each selected circuit template푓is instantiated by sampling pa- rameters from its parameter domainΘ 푓 . InInferQ, we write one sampled parameter tuple as 휃=(푛 푞 ,푑,푘,푟,휉) ∈Θ 푓 ,(12) where푛 푞 is the qubit count,푑is the depth allocated to this subcircuit, 푘is the evaluation-qubit,푟is the repetition count for repeatable template sections, and휉is a tuple of template-specific configuration variables. The domainΘ 푓 is derived from the hyper-parameters in Table 2. For example, the per-subcircuit depth푑is sampled uniformly from the defined range between min_depth and max_depth. The template-specific configuration variables휉captures local design choices supported by푓. Typical examples include whether QFTincludes final swaps, the choice of feature map and ansatz in variational templates, the number of layers in QAOA-style tem- plates, or the number of steps and coin operators in quantum-walk templates. Structural vs. numerical parameters. InInferQ, template instanti- ation is staged.InferQfirst fixes the structure of the subcircuit (e.g., qubit assignment, gate topology, repetition pattern, and depth con- tribution) from(푛 푞 ,푑,푘,푟,휉). If the template contains parametrized gates,InferQthen samples the numerical values (e.g., rotation angles) from template-specific distributions. This separation lets InferQexplore structural diversity independently from numerical variability. L Additional Results on SQL-only features. Figures 28 and 29 show that the dominant SQL signals are structural counts, in particular the number ofJOINs, predicates, and aggre- gates. For runtime, the Linear SVM assigns negative coefficients tonum_where_clauses,num_eq_predicates, andnum_agg_funcs, sug- gesting that queries with heavier filtering and aggregation tend to favor Qiskit Aer. In contrast,num_joinsandnum_and_clausesshift the decision toward the RDBMS backend. For memory,num_joins is the dominant factor, while predicate and aggregation features retain negative influence, reflecting the benefit of the optimized join algorithms and cost-based planning employed by RDBMS. L.1 Scalability Figure 30 reports how theInferQpreprocessing cost grows as we in- crease the number of generated circuits. We observe near-linear scal- ing for both circuit generation and feature extraction (static, graph, InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation (a) Top-20 gate-type distribution.(b) Depth/width coverage. Figure 25: Generated-corpus gate mix and depth/width coverage. Color in b indicates the number of circuits in each bin on a logarithmic scale. Figure 26: Generated-corpus static circuit-feature distributions. Dashed lines mark medians. and SQL features): generating 1,000 circuits takes only 6.47 sec- onds, and extracting features takes 1.9 seconds. 30 This tackles Gap 30 We exclude dynamic features here, as extracting them requires running the simu- lation, while Section 6.4 suggests that they can be predicted using static, graph, and SQL features. 3 in Section 2.2. That is,InferQcan scale to large circuit corpora: generation and feature extraction contribute negligible overhead. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Figure 27: Generated-corpus interaction-graph feature distributions. Dashed lines mark medians. 42024 Importance num_and_clauses num_eq_predicates num_joins num_where_clauses num_select_columns num_agg_funcs Linear SVM Feature Importance 0.00.10.20.30.4 Importance num_select_columns num_and_clauses num_joins num_eq_predicates num_agg_funcs num_where_clauses XGBoost Classifier Feature Importance Figure 28: Importance of various SQL features for SVM and XGBoost trained for optimizing execution time. Figure 29: Importance of various SQL features for SVM and RF trained for optimizing memory. Take-away.InferQscales well in preprocessing: circuit gener- ation and (static/graph/SQL) feature extraction grow linearly and remain inexpensive. This supports building large circuit datasets for database- and learning-based analyses. 02004006008001000 Number of Circuits Processed 0 1 2 3 4 5 6 Total Time (seconds) Cumulative Execution Time: Generation vs Feature Extraction Cumulative Generation Time Cumulative Feature Extraction Time Figure 30: Cumulative execution time versus number of cir- cuits processed. The figure shows cumulative generation time, and cumulative feature extraction time. M Implementation InferQ is supported by two complementary tools: (1) a generation and feature-extraction framework used to construct the dataset, and (2) a web-based dataset browser for interactive exploration and retrieval. M.1 InferQ Generation and Feature Extraction Framework The parameters in Table 2 are stored in Python dataclass. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation The InferQ framework implements the circuit generation and metric extraction pipeline described in Section 3. It produces com- binational quantum circuits and computes their static, graph, SQL, and dynamic features in a reproducible and structured manner. Each generated circuit is assigned a content-based hash that uniquely identifies its structure and parameters. This hash serves as the primary key across the dataset and links the circuit to all extracted feature records. For every circuit, InferQ stores: •the quantum circuit in a portable serialization format com- patible with Qiskit, and •a feature record in JSON format containing all static, graph, and dynamic metrics. Feature extraction is modular and category-based. Static features are derived directly from the circuit representation, graph features are computed from the qubit interaction graph, and dynamic fea- tures are obtained from full-state simulation. This separation allows InferQ to be extended with new feature families without recomput- ing or modifying existing entries. M.2 InferQ Web Dataset Viewer InferQ is accompanied by a web-based dataset browser inspired by MQTBench[31] that enables interactive inspection, filtering, and download of circuits and their features. The interface presents the dataset as a table where each row corresponds to a circuit identified by its hash. Columns are grouped into the four InferQ feature categories: static, graph, SQL, and dy- namic. Users can enable or hide individual feature columns or entire feature groups, apply range-based filters on any visible numeric feature, and explore circuits based on structural, topological, or physical properties. Each circuit entry includes download links for both the quantum circuit file and its corresponding feature JSON record, allowing users to retrieve exactly the data selected through the interface and use it directly in simulators, learning pipelines, or benchmarking workflows. Reproducibility and Code. InferQ is fully reproducible: given the same code revision, dependency lockfile, and random seed, the framework deterministically regenerates identical circuit struc- tures, parameters, and extracted features. Each circuit is assigned a content-based hash that uniquely identifies its structure and serves as the primary key linking the circuit artifact to all feature records. Code and environment. InferQ is released as open-source soft- ware with separate modules for circuit generation, feature extrac- tion, and dataset management. The repository includes a locked Python environment viauv.lockand a declared interpreter ver- sion. For exact reproduction, users should report the git commit hash, Python version, and lockfile version. Cloud-agnostic storage. Circuit binaries and feature files are stored in a cloud object store. While Azure Blob Storage is used in the reference deployment, all storage operations are routed through a backend-agnostic interface, allowing any S3-compatible or local filesystem to be used. Each circuit is stored in its own directory Circuits/circuit_hash, containing a serialized.qpycircuit file and a.jsonmetadata file that records generator history and extracted features. Deterministic circuit generation. Circuit construction follows an incremental process in which subcircuits (“generators”) are sampled and appended until a stochastic stopping condition is met. All randomness is controlled by a single global seed, which governs instance-level parameters (e.g., qubit count and depth), generator selection, generator-internal choices, and gate parameters. Synergy-based generator sampling. Generator selection is history- dependent rather than i.i.d. After each generator is chosen, the cat- egorical distribution over the remaining generators is reweighted using predefined synergies between generator families. These syn- ergies favor complementary compositions (e.g., state preparation followed by algorithmic cores and optional variational layers), dis- courage long runs of the same family, and enforce feasibility con- straints such as depth and qubit limits. The updated distribution is then renormalized before sampling the next generator. Because these updates are deterministic functions of the previous genera- tor sequence and the global seed, the entire generator sequence is exactly reproducible. Feature reproducibility. For each circuit, InferQ extracts static, graph-based, and dynamic (simulation-based) features. Feature ex- tractors are modular and deterministic given the same simulator backend, numeric precision, and hardware configuration. For fair comparison, users should report simulator version and floating- point settings when dynamic features are used. M.3 Qiskit Aer Data Representation Selector Most quantum applications will be run using a simulator framework like IBM Qiskit [18] with Qiskit Aer[29] as a simulation backend. Qiskit Aer offers various simulation backends corresponding to different quantum data representations. Each performs better or worse in terms of time and memory depending on the circuit to be simulated. This leads to the research question: what is the optimal Qiskit Aer data representation for classical simulation? InferQ can be used to train a selector for the Qiskit data repre- sentations for optimal simulation. In our experiment we trained various ML models to select the best representation within the classes of ["statevector", "density_matrix", "extended_stabilizer", "matrix_product_state"] provided by Qiskit Aer. We recorded the execution time for 93,567 entries in InferQ on our machine from Section 5. 31 For this experiments, we used the framework from Qymera [22]. 32 By defining the best representation to be the one taking lowest execution time, we could train various multiclass classifier models to select the best method. Training models of complexities and evaluating them on a test set of size 20% outperformed Qiskit Aer’s own “automatic” data representation selector by a margin of up to 28%. The accuracy in table 20 is the percentage of cases in the test set that the predicted best method matched the actual best method. 31 Qiskit Selector training data (Parquet) available athttps://github.com/InfiniD ata-Lab/InferQ/blob/main/analysis/training_data/selector_training_da ta.parquet 32 We thank the authors for sharing their code and helping us set up the experiments. Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai Table 20: Test-set accuracy of InferQ-trained selectors com- pared with Qiskit Aer’s built-in “automatic” method selector. Qiskit “Automatic”Trained on InferQ MetricAccuracyXGBoostRandom ForestDecision TreeKNNLogistic RegressionNaive Bayes Accuracy36%64%64%63%61%61%55% Figure 31: Bar chart displaying the imbalance between the classes being the best simulation method for minimum exe- cution time. Upon inspection of the features, it became clear why Naive Bayes performs weakly. There is multimodality within feature distribu- tions rather than Gaussian structures. In addition, the classes are highly imbalanced, as shown in Figure 31. Despite the K-Nearest Neighbour (KNN)’s relatively high ac- curacy, it is clear from Figure 33 that it is unable to predict the smaller classes well, as 42% of the “density_matrix” and 34% “ex- tended_stabilizer” methods are being classified as “matrix_product_state”. The Decision Tree is much better overall for all the classes, except it is overcompensating for the minority classes and hence has low accuracy for the dominant “matrix_product_state”. Logistic regres- sion has lowest accuracy so we are left with tree models and linear SVM. In order to break this tie, we can look at the distribution in which the simulation methods come 2nd, 3rd and 4th place. From Table 21 it becomes clear that “matrix_product_state”, “density_matrix” and "statevector" dominate in 2nd position too. Hence, we can choose XGBoost which performs the best for these 3 dominant classes as can be seen from confusion plots of Figure . Although the accuracy of XGBoost is 64.4%, it still outperforms Qiskit Aer’s own "automatic" method which is only able to select correctly in 35.9% of the cases. Even simpler models like logistic regression and linear SVMs are able to leverage InferQ features to perform relatively well against the current Qiskit Aer "automatic" selector. We thus show that InferQ can be used to optimize Qiskit Aer Workloads by building a selector, demonstrating that a complex model like XGBoost surpasses its simpler competitors in predic- tions amongst the highly imbalanced classes of representations. By outperforming Qiskit Aer’s own "automatic" selector with all Table 21: Number of entries where each simulation method is ranked 1st, 2nd, 3rd, and 4th by the XGBoost-based selector, ordered by predicted execution time. Rank Position Method1234 statevector3080234743251312891 density_matrix17704203407625948 matrix_product_state422883595914537783 extended_stabilizer277325254627441995 models experimented with, it validates our data-centric approach to this problem. Moreover, the experiment showcases that data management tech- niques can be used to make classical simulation of quantum com- putation more efficient without incorporating the domain specific techniques of quantum science. It also completes a pipeline to solve the mutli-class problem of which classical simulation method is optimal given a circuit incorporating the novel approach of RDBMS. N InferQ Feature Schema Figure 32 illustrates the schema of howInferQstores the extracted circuit features. InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Figure 32: Schema for storing extracted circuit features.InferQcircuit data model schema. Each circuit is stored with a unique hash (primary key) and associated feature classes.InferQentries are centered around circuits in theInferQ_Circuitstable, which reference static, graph, SQL and dynamic features, as well as storage metadata in Azure DB. Figure 33: Confusion matrices, normalised over the true classes, for each model’s performance on the test set. SV =statevector, DM =density_matrix, MPS =matrix_product_state, ES =extended_stabilizer. Panels are ordered by decreasing accuracy and share a common colour scale.