InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation Andrei Ilinescu∗
Aadi Patwardhan∗
Rihan Hai
[email protected] Delft University of Technology Delft, The Netherlands
[email protected] Delft University of Technology Delft, The Netherlands
[email protected] Delft University of Technology Delft, The Netherlands
arXiv:2607.29134v1 [quant-ph] 31 Jul 2026
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.
1
Introduction
In the current noisy intermediate-scale quantum (NISQ) era, most quantum applications are developed and validated through classical 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 quantum 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 quantum 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 database 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 particularly 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 workloaddependent: 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 instance, 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]. Moreover, 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, indexing, 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 systematic 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 backend 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 computation can be expressed as tensor algebra: applying gates corresponds 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 multiplication, 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;
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 thousands (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 250 ≈ 1.13 × 1015 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 quantum 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) intermediate results may be enormous unless the representation stays sparse or factored; (ii) whether sparsity survives depends on the gate sequence, and entangling operations can rapidly densify the state and cause abrupt blow-ups; and (iii) 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 quantum 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 present InferQ, a database-oriented benchmark for quantum circuit simulation. Given a small user configuration (Table 2), InferQ generates compositional circuits by assembling subcircuits from a set of quantum templates. Each circuit is accompanied 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 workload, 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 workloads 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 propose InferQ, 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 dynamic features per circuit, enabling systematic workload characterization and correlation with database performance (Section 4). • Using InferQ workloads, we quantify when SQL-driven simulation is competitive with Qiskit Aer, including memory-efficient and out-of-core cases. InferQ features enable accurate, lightweight 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⟩: 1 0 |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
Example Gate Legend 2-qubit Gate
1-qubit Gate
S
|q1⟩
|q2⟩
S
— Phase
H
— Hadamard
T
— π/8 gate
Single-qubit (2×2) Unitary Matrix: Gate Input : C2 → Output : C2
H — CNOT
T
|q3⟩
Two-qubit (4×4) Unitary Matrix : Input : C4 → Output : C4
Equivalent Matrices
S
1
0
0
i
CNOT
H
Phase Gate
CNOT Gate
T
Hadamard Gate
T (π/8) Gate
1
0
0
0
1
1
1
1
0
0
1
0
0
√2
1
-1
0
e(iπ/4)
0
0
0
1
0
0
1
0
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: ∑︁ ∑︁ |Ψ⟩ = 𝑐 𝑥 |𝑥⟩ , |𝑐 𝑥 | 2 = 1. 𝑥 ∈ {0,1} 𝑁
𝑥 ∈ {0,1} 𝑁
Fix an ordering of the computational basis states (e.g., lexicographic order). The state vector representation of |Ψ⟩ is the column vector 𝑐𝑐 0···0 0···1 of its amplitudes in that order: .. . For example, when 𝑁 = 2, 𝑐 . 1···1 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 analogous to classical logic circuits. Computation is performed by applying 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 with Input ∈ C𝑛 it indicates that the gate acts on an 𝑛-dimensional state vector of complex amplitudes (where C denotes the complex numbers), e.g., one qubit corresponds to C2 and two qubits to C4 . A gate set is called universal 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 quantum computing community, including SupermarQ [33], MQT Bench [31], and QASM Bench [21]. While these suites are valuable for evaluating quantum circuits, they expose limited support for databasedriven and data-centric studies of circuit simulation. Gap 1: No broad DBMS-executable benchmark workloads. Existing benchmarks primarily distribute circuits as OpenQASM1 and Qiskit QPY2 files. These formats are well-suited for quantum toolchains, but they do not expose the induced simulation computation as optimizer-visible relational workloads that can be directly executed, inspected, or optimized by an RDBMS. As a result, studying circuit simulation inside an RDBMS typically requires substantial 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 summation and evaluates SQL simulation on Google’s Sycamore quantumsupremacy circuit, while [13] studies W and GHZ state preparation and QFT circuits. Thus, these works motivate DBMS-backed simulation, but do not provide a benchmark-scale collection of diverse circuits with reusable SQL workloads and workload features. We address this gap by having InferQ generate general, diverse circuits, each coming with an RDBMS-ready SQL workload (Section 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. Consequently, InferQ enables 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
Description
Example 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
StatePrep
State Preparation
Prepares |𝜓 ⟩ / |𝑏 ⟩ or initial superpositions before an algorithmic primitive.
StatePrep → HamSim StatePrep → Variational
HamSim
Hamiltonian Simulation
HamSim , ModularExp , GroverIter , Variational QPE , Variational , Random
HamSim → QPE
QFT
Quantum Fourier Transform
Controlled time-evolution unitaries are typically read out via QPE (incl. IQFT decoding) in eigenvalue/spectral workflows. Fourier-basis transform and dense benchmark block.
Oracle/A
Oracle/Algorithm-𝐴 Wrapper
ModularExp
Modular Exponentiation
QPE
GroverIter
Grover Iteration
GroverIter (repeat), AmpEst , Measure
Encodes a problem-dependent subroutine 𝐴 (e.g., oracle/feature map/encoding) that is naturally followed by Grover-style amplification. Order-finding and Shor-style structure: modular arithmetic unitaries followed by phase estimation (incl. IQFT) to extract phases/periods. Amplification layers typically repeat and then transition to an estimation wrapper or terminate with measurement.
AmpAmpl QPE
Amplitude Amplification Quantum Phase Estimation
Measure AmpAmpl , Measure , Variational , Random
Boosts the probability of a desired or postselected outcome. Phase readout/decoding stage (typically includes an IQFT); often followed by measurement or optional continuations.
Variational
Variational Circuit Layer/ Ansatz
Variational (repeat), Measure , Random
Layered ansatz patterns; measurement used for objective estimation; can be interleaved for hybrid workloads.
Random
Random Circuit Block
Random , Measure
AmpEst
Amplitude Estimation
Measure
Diversity/stress-test tail; may extend circuit length or terminate by measurement. Estimates a success amplitude or probability. It normally terminates the quantum subroutine by measurement and classical post-processing.
Measure
Measurement
END
END
(end symbol)
—
QPE , Measure , Random GroverIter , Variational , Measure
Gap 3: Limited scalability for data-centric analysis. Because many existing benchmarks focus on fixed algorithm templates, their scalability 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 applying machine learning models, cost modeling, and feature-driven analysis. We address this gap with scalable compositional generation 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 correspond 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 benchmarks expose few graph-derived properties and provide limited support for analyzing structural diversity across circuits. We address 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 simulation. Addressing these gaps requires a benchmark that produces SQL workloads, supports conditional composition of subcircuits,
Final step that yields classical outcomes and ends the whole circuit generation process. It marks the end of the template sequence.
QFT → QPE QFT → Measure
𝐴 → GroverIter → AmpEst
ModularExp → QPE
GroverIter → GroverIter GroverIter → AmpEst GroverIter → Measure AmpAmpl → Measure QPE → AmpAmpl QPE → Measure QPE → Variational QPE → Random Variational → Variational Variational → Measure Variational → Random Random → Random Random → Measure AmpEst → Measure
Measure → END END
scales to large and diverse circuits, and exposes graph- and querylevel 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 the InferQ benchmark 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 include state preparation, Hamiltonian simulation, quantum Fourier transform (QFT), quantum phase estimation (QPE), amplitude amplification 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-H3 , TPC-DS4 , and the Join Order Benchmark (JOB) [20] use parameterized templates to obtain controlled scale, coverage, and reproducibility. Inspired by this design, InferQ generates circuits from a library of templates representing 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], InferQ is more general and extensible: new primitives and transition rules can be added as quantum algorithms and simulation workloads evolve. This gives InferQ broad 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 quantum circuits, where a single circuit is assembled from multiple building blocks (Table 1). 5 This differs from template-only benchmarks that generate isolated, standalone circuits. InferQ selects 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. InferQ first samples userconfigured local hyper-parameters (e.g., qubit count and depth). (3) Generate subcircuits. For each selected template, InferQ samples template parameters and generates the corresponding subcircuit. (4) Output circuit. The circuit generation process stops when a stopping rule triggers, then InferQ composes all subcircuits 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 purpose of template selection is to keep this sequence valid while still producing diverse, realistic benchmark workloads. In InferQ, we maintain a set of circuit templates 𝐹 = {𝑓1, . . . , 𝑓𝑀 }. Table 1 lists representative templates, such as StatePrep ; the full template set is documented online.6 Given a selected template 𝑓 ∈ 𝐹 , InferQ instantiates a subcircuit by sampling concrete, circuit-specific parameter values. For example, from the StatePrep template we can generate a GHZ state preparation subcircuit with 10 qubits. 3 https://www.tpc.org/tpch/ 4 https://www.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 form Start → 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 by InferQ are ordered compositions of subcircuits, and the choice of the next subcircuit is often constrained by (and semantically 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. InferQ provides a set of user-configurable synergy rules that encode statistical dependencies between templates and bias generation toward semantically coherent pipelines, e.g., StatePrep→HamSim→QPE, ModularExp→QPE, and A→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. Let S denote 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) Let feas(𝑏, 𝑓 ) ∈ {0, 1} be a hard feasibility predicate for choosing template 𝑓 ∈ 𝐹 under context 𝑏 ∈ 𝐵. InferQ generates 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, . . . ,𝑇 }, InferQ maintains a categorical distribution 𝑝𝑡 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 transition model. At step 𝑡, InferQ samples 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 renormalize: 𝑝𝑡 (𝑓 ) feas(𝑏𝑡 −1, 𝑓 ) 𝑝¯𝑡 (𝑓 ) = Í , 𝑓 ∈ 𝐹, (4) 𝑔∈𝐹 𝑝𝑡 (𝑔) feas(𝑏𝑡 −1 , 𝑔) 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. Let R be 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 (𝑓 ) = 𝑝¯𝑡 (𝑓 ) · 𝛽, 𝑓 ∈ 𝐹, (5) (𝑇 ,𝑈 ,𝛽 ) ∈ R: 𝑓𝑡 ∈𝑇 , 𝑓 ∈𝑈
and then apply feasibility under the updated context 𝑏𝑡 and renormalize: 𝑝b𝑡 +1 (𝑓 ) feas(𝑏𝑡 , 𝑓 ) 𝑝𝑡 +1 (𝑓 ) = Í , 𝑓 ∈ 𝐹. (6) b𝑡 +1 (𝑔) feas(𝑏𝑡 , 𝑔) 𝑔∈𝐹 𝑝 Equations 4–6 keep the generation process simple: feasibility masking removes disallowed templates that do not fit the current circuit, while synergy rules encourage quantum subcircuits (primitives) that commonly appear together. This lets InferQ generate circuits that follow quantum algorithm design principles without enumerating every full circuit by hand. Allowed and disallowed compositions are captured by feasibility masking: a disallowed successor template 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 toward 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 current design keeps InferQ configurable as new quantum primitives and workloads emerge. Example 3.1 (Single-step reweighting under a synergy rule). Assume the previously selected template is StatePrep. By Table 1, the feasible successors are {HamSim, ModularExp, GroverIter, Variational}, with a uniform distribution 𝑝𝑡 (·) = 41 . Let R include (𝑇 , 𝑈 , 𝛽 ) = ( {StatePrep}, {HamSim}, 2). Then 𝑝b𝑡 +1 (HamSim) = 12 ,
𝑝b𝑡 +1 (ModularExp) = 14 ,
𝑝b𝑡 +1 (GroverIter) = 14 ,
𝑝b𝑡 +1 (Variational) = 14 ,
3.3
𝑝b𝑡 +1 (ModularExp) = 15 , 𝑝b𝑡 +1 (Variational) = 15 ,
Sample Hyper-Parameters
Circuit generation is constrained by the global hyper-parameters in Table 2, which are configured by users. InferQ requires 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
Parameter min_qubits max_qubits min_depth max_depth min_reps
Type int int int int int
max_reps min_eval_qubits max_eval_qubits measure seed
int int int bool int
Description Minimum number of qubits per generated circuit. Maximum number of qubits per generated circuit. Minimum target depth of a generated quantum circuit. Maximum target depth of a generated quantum circuit. Minimum number of repetitions for repeatable subroutines (e.g., Grover iterations or variational layers). Maximum number of repetitions for repeatable subroutines. Minimum number of qubits used during evaluation. Maximum number of qubits used during evaluation. Whether measurements are appended to the circuit. Global random seed to ensure full reproducibility of circuit generation.
sampled parameter tuple as 𝜃 = (𝑛𝑞 , 𝑑, 𝑘, 𝑟, 𝜉) ∈ Θ 𝑓 ,
Generate Subcircuits
Each selected circuit template 𝑓 is instantiated by sampling parameters from its parameter domain Θ 𝑓 . In InferQ, we write one
(7)
where 𝑛𝑞 is the qubit count, 𝑑 is the depth allocated to this subcircuit, 𝑘 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 generated 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. Quantumspecific 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 ◦ · · · ◦ 𝑆𝑇 .
and after normalization, 𝑝b𝑡 +1 (HamSim) = 25 , 𝑝b𝑡 +1 (GroverIter) = 15 ,
Table 2: Hyper-parameters.
(8)
Alongside 𝐶, InferQ outputs a provenance record that stores the template sequence (𝑓1, . . . , 𝑓𝑇 ), sampled parameters (including repetitions 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 database 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 contractions into relational joins as proposed by Blacher et al. [6]. Reproducibility guarantee. To make sure all sampling in InferQ is deterministic, we use seeded pseudo-random number generators7 and maintain a global random seed as part of the hyper-parameters in Table 2. Consequently, with the seed and the generated template 7 See https://docs.python.org/3/library/random#random.seed and https://
numpy.org/doc/2.2/reference/random/generated/numpy.random.seed.html.
InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation
2) Sample HyperParameters
1) Select templates history-dependent draw START → QFT (synergy boosts QPE) QFT → QPE
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)
Static
Table 3: Notation used in circuit feature extraction.
Feature Extraction
Graph
Simulation
SQL
Dynamic
Figure 5: InferQ feature extraction workflow. Static, graphbased, and SQL-derived features are extracted prior to simulation, whereas dynamic features can only be obtained after the simulation completes.
sequence, both the subcircuit structure and the numerical gate parameters are exactly reproducible across runs.
Notation
Description
𝐶 𝐺 𝑁 𝑊 𝐺 𝐼 = (𝑉 , 𝐸 ) 𝑉 𝐸 2𝑁 p = (𝑝 1 , . . . , 𝑝 2𝑁 ) 𝐻 (p) 𝜌 (p)
Quantum circuit (ordered list of gate instructions). Number of circuit instructions (gate count).
(𝑘 )
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, (ii) instantiates a small sequence of templates with parameters, and (iii) materializes both an artifact and its metadata. Step 1 (Hyper-Parameters). Given a user seed, InferQ samples 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, InferQ samples a short template sequence using the history-dependent distribution. Here the sequence is QFT → QPE. Each template is then instantiated by binding templatelocal 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 𝐶, InferQ stores a provenance record containing the template sequence and all sampled parameters, enabling exact replay and database-style inspection.
𝑆 vN 𝜀 𝜏
I(·) 𝑁 AST 𝑆 𝑃 𝐽
Circuit Feature Extraction
When we push quantum circuit simulation into an RDBMS, it induces 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
Qubit interaction graph induced by multi-qubit gates. Vertex set of 𝐺 𝐼 (qubits; |𝑉 | = 𝑁 ). Edge set of 𝐺 𝐼 (qubit interactions; |𝐸 | is the edge count). State-space dimension (length of a full statevector). Probability vector derived from the saved statevector. Shannon entropy of p (superposition). Sparsity / support density: fraction of entries above threshold (superposition). 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. Indicator function (1 if condition holds, else 0). 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 in InferQ and 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, InferQ models each circuit with four types of features: static, graph, dynamic, and SQL features, as listed in Table 47, respectively. Such a separation makes InferQ extensible: new features can be added easily. Notably, as shown in Figure 5, feature extraction is an optional post-processing step: InferQ can generate circuits without extracting features, and computes them only when needed for analysis.
4.1 4
Number of qubits in the circuit. Circuit width (maximum simultaneously active qubits).
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. Feature num_qubits width depth circuit_size pauli_gate_count two_qubit_gate_count two_qubit_gate_percentage locality_ratio idling_score density_score gate_counts
Time 𝑂 (1) 𝑂 (𝐺) 𝑂 (𝐺) 𝑂 (1) 𝑂 (𝐺) 𝑂 (𝐺) 𝑂 (𝐺) 𝑂 (𝐺) 𝑂 (𝐺) 𝑂 (𝐺) 𝑂 (𝐺)
Space 𝑂 (1) 𝑂 (𝑊 ) 𝑂 (𝑊 ) 𝑂 (1) 𝑂 (1) 𝑂 (1) 𝑂 (1) 𝑂 (1) 𝑂 (𝑊 ) 𝑂 (𝐺) 𝑂 (𝐺)
Description Total number of qubits Maximum simultaneous active qubits Longest dependency chain Total gate count Number of Pauli gates (X, Y, Z) Number of two-qubit gates Ratio of two-qubit gates Local vs. non-local gate ratio Idle qubit utilization Gate density feature [5] Per-gate-type histogram
Table 5: Time and space complexities for graph features. Feature edge_count max_degree min_cut diameter radius average_degree average_clustering_coefficient average_shortest_path_length central_point_of_dominance std_dev_adjacency_matrix
Time 𝑂 (1) 𝑂 (𝑁 ) 𝑂 (𝑁 𝐸) 𝑂 (𝑁 3 ) 𝑂 (𝑁 3 ) 𝑂 (𝑁 ) 𝑂 (𝑁 3 ) 𝑂 (𝑁 3 ) 𝑂 (𝑁 𝐸) 𝑂 (𝑁 2 )
Space 𝑂 (1) 𝑂 (1) 𝑂 (𝑉 + 𝐸) 𝑂 (𝑁 2 ) 𝑂 (𝑁 2 ) 𝑂 (1) 𝑂 (1) 𝑂 (𝑁 2 ) 𝑂 (𝑁 ) 𝑂 (1)
Description Number of interaction edges Maximum node degree Minimum cut Graph diameter Minimum eccentricity Mean node degree Local clustering tendency Mean shortest path length Graph centralization measure 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
Table 6: Time and space complexities for extracting SQL features (excluding parsing). Feature num_and_clauses num_joins num_select_columns num_agg_funcs num_where_clauses num_eq_predicates
Time 𝑂 (𝑁 AST ) 𝑂 (𝑆 · 𝑃 + 𝐽 2 ) 𝑂 (𝑁 AST ) 𝑂 (𝑁 AST ) 𝑂 (𝑁 AST ) 𝑂 (𝑁 AST )
Space 𝑂 (1) 𝑂 (𝐽 2 ) 𝑂 (1) 𝑂 (1) 𝑂 (1) 𝑂 (1)
Description Counts logical AND operators during AST traversal Counts explicit and implicit joins and stores join edges Counts column expressions in SELECT clauses Counts aggregate functions (e.g., COUNT, SUM, AVG) Counts WHERE clause nodes in the AST Counts equality predicates used in filters and joins
Table 7: Time and space complexities for dynamic features. Feature Shannon_entropy von_neumann_entropy sparsity
4.3
Time 𝑂 (2𝑁 ) 𝑂 (𝑁 · 2𝑁 ) 𝑂 (2𝑁 )
Space 𝑂 (2𝑁 ) 𝑂 (𝑁 · 2𝑁 ) 𝑂 (2𝑁 )
Description Shannon Entropy of stored statevector Von Neumann Entropy of stored statevector Sparsity of stored statevector
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 calculate 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.
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 database analysis: they indicate what the join structure and intermediateresult growth may look like in relational tensor computation. Intuitively, 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 contractions 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 interaction 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.
4.4
Dynamic Features
As shown in Table 7, dynamic features depend on the circuit’s output state and cannot be derived from circuit structure alone. They are crucial for database-backed simulation because relational approaches 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 diminishes. We therefore extract three dynamic features that capture these effects: (i) Shannon entropy, (ii) von Neumann entropy, and (iii) 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: Let p = (𝑝 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𝑁 ∑︁
(𝑝𝑖 + 𝜀) log2 (𝑝𝑖 + 𝜀).
(9)
𝑖=1
To quantify entanglement, we compute the von Neumann entropy across a partition defined by a cut along a qubit line 𝑘, (𝑘 ) 𝑆 vN = −Tr 𝜌𝐴𝑘 log2 𝜌𝐴𝑘 ,
𝜌𝐴𝑘 = 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 2𝑁
𝜌 (p) =
1 ∑︁ I(𝑝𝑖 > 𝜏), 2𝑁 𝑖=1
(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 exponential 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 additional 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 configuration (Table 2) into circuits, features, and an RDBMS-ready SQL workload for simulation, and (ii) 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. Detailed descriptions of all circuit templates and the corresponding
SQL code are provided in the online documentation.8 In addition to on-demand generation, InferQ releases a large dataset of 202,975 circuits online9 . 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 computed 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 .sql scripts) that represent the simulation workload, (ii) the circuit in a portable Qiskit serialization format (e.g., .qpy), and (iii) 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 online11 . InferQ is designed to be reproducible. Given the same code revision, dependency lockfile, and global seed (Table 2), the framework 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 use InferQ to quantify and explain when an RDBMS engine is a competitive simulation engine for general, compositional quantum circuits. First, in Section 6.2 we compare the InferQ-emitted SQL workloads on four RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra) against Qiskit Aer for wallclock 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 featureimportance analysis in Section 6.3 and demonstrate additional datacentric 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 hardware acceleration; all simulations were executed on CPU. We implemented our prototype in Python 3.12, with all dependencies pinned in pyproject.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
6.8% 9.9%
27.2%
Wins (memory) 66.7%
PostgreSQL
4 GB 1 GB
35.2% Spill
Wins (sim. time)
21.0%
100 MB
10.5% 6.2% 8.6% 8.0%
DuckDB
r(lrg)=+0.46 r(tot)=+0.66
SQLite
r(lrg)=+0.32 r(tot)=+0.49
r(lrg)=+0.38 r(tot)=+0.77
1 MB
0 sqlite state_vector
20
ducksql extended_stabilizer
40 60 Percentage of cases (%)
psql matrix_product_state
80
100
200
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.
K 00K 1M 5
40q
41q
43q
44q
3M
200
CTE size Lrg
45q
K 00K 1M 5
3M
CTE size
Tot
S-1
PostgreSQL DuckDB SQLite
Time (s)
20 10 5 2 40
41
42
43
44
45
Number of qubits
Figure 9: Runtime versus #qubits. PostgreSQL
Use case 1: RDBMS as Simulation Backend
DuckDB
SQLite
10.0 GB
Spill (log scale)
Q1: Is an RDBMS an efficient simulation engine? To answer this question, we generated 162 circuits13 using InferQ. For each circuit, we measured wall-clock runtime and peak memory when simulating it with (i) RDBMS engines (PostgreSQL, SQLite, DuckDB, and Umbra) executing the SQL workload emitted by InferQ, and (ii) Qiskit Aer using four built-in simulation methods14 (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
42q
K 00K 1M 5
Runtime Performance (16 GB) 100
1.0 GB 100 MB 10 MB 1 MB 100 KB 10 KB 20
21
22
23
20
21
22
23
20
21
22
23
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. PostgreSQL
1.0 GB
DuckDB
SQLite
100 MB
CTE size
6.2
200
Figure 8: Out-of-core spill versus intermediate relation sizes.
50
quantum-state simulation, we use Qiskit 2.0.1 together with Qiskit Aer 0.17.0. For database-backed simulation, we generate SQL using the sql-einsum code generator12 and build on the RDBMS simulator introduced by [13]. PostgreSQL is version 12.22 accessed via psycopg2-binary 2.9.10. SQLite is version 3.50.4, and DuckDB is version 1.1.3. Umbra (v0.2-1665-gfeeb4bb5d) is accessed through its PostgreSQL-compatible (18.1) server interface using psycopg2binary 2.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.
3M
CTE size
10 MB 1 MB 100 KB 10 KB 1 KB 100 B 0.0
ρ(tot)=+0.71 ρ(lrg)=+0.73
ρ(tot)=+0.62 ρ(lrg)=+0.65
ρ(tot)=+0.54 ρ(lrg)=+0.61
0.5
0.5
0.5
1.0 0.0
1.0 0.0
1.0
Output density (0=sparse, 1=dense) Sparse [0, 0.33)
Medium [0.33, 0.67)
Dense [0.67, 1.0]
Total CTEs
Largest CTE
Figure 11: Intermediate CTE sizes versus output density on sampled InferQ circuits.
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
database-oriented studies of SQL-based simulation report strong results on a small set of highly structured circuits (e.g., sparse statepreparation workloads) [6, 13]. Using InferQ, we move 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 confusionmatrix entries. The columns represent true label → prediction label. Best linear and tree-based models are bolded. (a) Time-optimal routing Model
(b) Memory-optimal routing
Accuracy
rdbms→rdbms
qiskit→qiskit
rdbms→qiskit
qiskit→rdbms
Accuracy
rdbms→rdbms
qiskit→qiskit
rdbms→qiskit
qiskit→rdbms
Logistic Regression Linear SVM
0.887 0.908
0.94 0.93
0.88 0.90
0.06 0.07
0.12 0.10
Logistic Regression Linear SVM
0.935 0.940
0.93 0.93
0.94 0.95
0.07 0.07
0.06 0.05
Decision Tree Random Forest XGBoost
0.940 0.956 0.953
0.78 0.81 0.88
0.97 0.98 0.96
0.22 0.19 0.12
0.03 0.02 0.04
Decision Tree Random Forest XGBoost
0.962 0.973 0.974
0.94 0.95 0.95
0.98 0.99 0.99
0.06 0.05 0.05
0.02 0.01 0.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 circuits15 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% accuracy and less than 5% misclassification per class), while the linear SVM also remains highly competitive (94.0% accuracy). Overall, InferQ features 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 inference. 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 routing 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, conventional 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 at https://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.
Model
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 material. Under this memory limit, Qiskit Aer’s exact statevector 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 intermediate volume than with the single largest intermediate, indicating that cumulative joins and group-bys lead to externalization. Figure 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 circuits 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) InferQ enables 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 optimization, 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 Model
(b) Memory-optimal routing
Accuracy
rdbms→rdbms
qiskit→qiskit
rdbms→qiskit
qiskit→rdbms
Accuracy
rdbms→rdbms
qiskit→qiskit
rdbms→qiskit
qiskit→rdbms
Logistic Regression Linear SVM
0.787 0.803
0.88 0.88
0.77 0.79
0.12 0.12
0.23 0.21
Logistic Regression Linear SVM
0.735 0.737
0.77 0.77
0.71 0.72
0.23 0.23
0.29 0.28
Decision Tree Random Forest XGBoost
0.915 0.932 0.924
0.76 0.75 0.81
0.94 0.96 0.94
0.24 0.25 0.19
0.06 0.04 0.06
Decision Tree Random Forest XGBoost
0.836 0.866 0.842
0.81 0.82 0.84
0.85 0.90 0.85
0.19 0.18 0.16
0.15 0.10 0.15
Linear SVM Feature Importance
XGBoost Classifier Feature Importance
num_where_clauses num_select_columns num_eq_predicates average_degree num_and_clauses statevector_saved_shannon_entropy edge_count width num_joins circuit_size
num_where_clauses statevector_saved_shannon_entropy num_eq_predicates width statevector_saved_sparsity average_clustering_coefficient num_joins edge_count pauli_gate_count num_agg_funcs 4
2
0
Importance
2
0.0
Model
Table 10: Feature-group ablation for routing (XGBoost) Runtime
0.1
0.2
Importance
Static + Graph + SQL + Dynamic Static + Graph + SQL Static + Graph Static
0.3
Figure 12: Importance of top 10 InferQ numeric features for SVM and XGBoost trained for optimizing execution time. Linear SVM Feature Importance average_degree statevector_saved_shannon_entropy num_where_clauses num_agg_funcs edge_count num_select_columns num_qubits num_eq_predicates two_qubit_gate_percentage average_clustering_coefficient
Random Forest Feature Importance
num_qubits statevector_saved_shannon_entropy width edge_count max_degree statevector_saved_sparsity num_agg_funcs average_degree idling_score num_where_clauses 3
2
1
0
Importance
1
2
Memory
Feature set Acc.
F1
Acc.
F1
0.95 0.93 0.92 0.92
0.84 0.78 0.74 0.74
0.98 0.97 0.96 0.95
0.98 0.96 0.95 0.94
For peak memory (Figure 13), the Linear SVM and Random Forest agree on the main features: num_qubits and shannon_entropy dominate, with additional contributions from width, edge_count, degree statistics, and sparsity measures. The Random Forest captures non-linear thresholds in these features, separating regimes where sparse relational execution substantially reduces peak memory.
0.00 0.05 0.10 0.15 0.20 0.25
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 circuits (Section 4.3, Table 6). Table 9a shows that these SQL-only features already yield strong routing accuracy, especially for timeoptimal 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 All InferQ features. 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, including shannon_entropy, width, and edge_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, and average_degree, indicating that irregular interaction structure matters for runtime differences.
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 workload 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) explains much of when an RDBMS should be chosen. This enables follow-up work on SQL-level cost modeling and query optimization tailored to quantum circuit simulation workloads. (2) When using the full feature set, the top features are consistent 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 followup work on data-centric models that learn when to use an RDBMS engine and how to optimize execution from InferQ-generated training data.
6.4
Use 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 models. Reported are coefficient of determination (𝑅 2 ) and root mean squared error (RMSE) comparing predictions to actual values. Model
Sparsity Model
Entropy Model
Random Forest RMSE
0.7737 0.1928
0.8936 1.9931
Linear Regression 𝑅 2 Linear Regression RMSE
0.3934 0.3156
0.6956 3.3714
Random Forest 𝑅 2
Figure 14: Predicted vs Actual value for the dynamic feature RF regression estimators for subset (1000 entries) of test set.
We construct estimators for sparsity and shannon_entropy using 202,975 circuits for which dynamic features are available.16 We train (i) a Random Forest regressor and (ii) 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 empirical 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 that InferQ features capture sparsity even when exact regression is difficult. Finally, feature-importance analysis for the sparsity-band classifier highlights pauli_gate_count as a stronger predictor than num_qubits. This suggests that (in our generated workload) sparsity is driven more by the gate mix than by state dimension alone, offering a concrete, data-derived signal that can guide both simulator design and feature engineering.
Take-away. (1) InferQ enables 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 predictive. 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.
Figure 15: Distribution of dynamic features over 202k entries in InferQ with Dynamic features.
7
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: learning 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 quantum analysis. Q5: Can we estimate complex quantum properties using InferQ features?
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 ondemand toolkit and a large dataset for reproducible analysis. Our evaluation shows that RDBMS engines can be competitive, especially in peak memory across a broad set of general circuits, and that lightweight models trained on InferQ features can reliably predict when an RDBMS engine will be preferable. We expect InferQ to enable follow-up work in (i) query optimization and physical design for emitted simulation SQL, and (ii) data-centric routing and cost modeling for simulator selection, trained at scale on InferQgenerated circuits and features. 16 Estimator training data (Parquet) available at https://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 RDBMSbased simulation and develop array-native execution for tensoraware DBMSs. InferQ can also be extended from circuit generation to end-to-end validation for quantum algorithm design, covering correctness checks, iterative test–debug cycles, and hardwareaware 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 Durand, 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. Proceedings 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. Towards 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 Approximate Optimization Algorithm. https://arxiv.org/abs/1411.4028 [12] András Gilyén, Yuan Su, Guang Hao Low, and Nathan Wiebe. 2019. Quantum singular value transformation and beyond: exponential improvements for quantum matrix arithmetics. 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: //www.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. QASMBench: 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. Automatic optimization of matrix implementations for distributed machine learning and linear algebra. In Proceedings of the 2021 International Conference on Management 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 Quantum 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 highperformance 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: Benchmarking Software and Design Automation Tools for Quantum Computing. Quantum 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: Appendix roadmap.
Spill
Table 12 provides a compact roadmap of the appendix material.
PostgreSQL
4 GB 1 GB 100 MB
r(lrg)=+0.46 r(tot)=+0.66
Main content
A B–C D–E
Out-of-core evaluation and spill behavior. Routing ablations and training/inference overhead. Tensor-aware DBMS discussion and support for external benchmark suites. SQLite–Aer profiling, DBMS-specific tuning, and physical-design discussion. Reproducibility details, generated-workload characterization, and subcircuit generation. SQL-only results, preprocessing scalability, implementation details, Qiskit Aer selector, and feature schema.
40q
F–H I–K L–N
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 complete the simulation, whereas RDBMS engines can spill temporary data to secondary storage and complete execution, demonstrating a clear case when an RDBMS backend is beneficial. Second, in Section A.2, we use InferQ to 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 (ii) 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
SQLite
r(lrg)=+0.32 r(tot)=+0.49
r(lrg)=+0.38 r(tot)=+0.77
1 MB
200
Appendix
DuckDB
K 00K 1M 5
3M
200
CTE size
41q
42q
43q
44q
K 00K 1M 5
3M
200
CTE size
45q
Lrg
K 00K 1M 5
Tot
3M
CTE size S-1
Figure 17: Spill volume of RDBMS engines (PostgreSQL, DuckDB, SQLite). Filled points (tot) denote total intermediate 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, intermediate 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 associated with cumulative intermediate volume than with the peak single-step intermediate. This suggests that optimization opportunities 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 endto-end query time once operator workspaces spill to disk.
17We 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 tempbytes-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
Runtime Performance (16 GB) 100 50
entries in the vector p against the vector size |p|:
PostgreSQL DuckDB SQLite
density(p) =
|{ 𝑖 | 𝑝𝑖 ≠ 0 }| . |p|
Time (s)
20
A smaller density indicates fewer non-zero tuples in the DBMS representation, while a density close to 1 indicates a near-dense output.
10 5 2 40
41
42
43
44
45
Number of qubits
Figure 18: Runtime of RDBMS engines (PostgreSQL, DuckDB, SQLite).
Spill Impact (16 GB) 100
Time (s)
50
PostgreSQL: r=+1.00 DuckDB: r=+1.00 SQLite: r=+0.94
20 10 5
PostgreSQL DuckDB SQLite
2
1M
B
100
MB
B
1G
B
4G
Spill
Figure 19: Runtime versus spill volume for RDBMS engines (PostgreSQL, DuckDB, SQLite).
Takeaways. This experiment demonstrates when DBMSbacked simulation is particularly useful: it enables exact simulation 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 optimization 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𝑛 amplitude vector p. We define output density as the fraction of non-zero
Experiment setup. We construct a sample of 17 InferQ circuits18 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 volume, 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 determine spill volume. For PostgreSQL and SQLite, several Mediumdensity circuits spill more than some Dense circuits at similar qubit counts. This indicates that spill is strongly influenced by intermediate 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 execution time and spill (rank correlations shown in the figure), and DuckDB exhibits a weaker but still positive association. This result 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 governed 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, controlling 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
PostgreSQL
DuckDB
SQLite
Spill (log scale)
10.0 GB 1.0 GB 100 MB 10 MB 1 MB 100 KB 10 KB 20
21
22
23
20
21
22
23
20
21
22
23
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). PostgreSQL
1.0 GB
DuckDB
SQLite
CTE size
100 MB 10 MB 1 MB 100 KB 10 KB 1 KB 100 B 0.0
ρ(tot)=+0.71 ρ(lrg)=+0.73
ρ(tot)=+0.62 ρ(lrg)=+0.65
ρ(tot)=+0.54 ρ(lrg)=+0.61
0.5
0.5
0.5
1.0 0.0
1.0 0.0
1.0
Output density (0=sparse, 1=dense) Sparse [0, 0.33)
Medium [0.33, 0.67)
Dense [0.67, 1.0]
Total CTEs
Largest CTE
Figure 21: Maximum and total intermediate CTE sizes against output state sparsity (log scale). PostgreSQL
DuckDB
SQLite
Time (s)
100 10 1 0.1
ρ = +0.99 100 MB
ρ = +0.63
10.0 GB 1 MB
10 MB 1 MB
ρ = +0.98 100 MB
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 XGBoost) 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 allfeatures setting. Table 15 reports training and inference time separately 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; therefore, 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. LR Feature Set
Acc
SVM F1
Acc
DT
F1
Acc
RF F1
Acc
XGB F1
Acc
F1
SQL 0.79 0.54 0.80 0.57 0.91 0.70 0.93 0.75 0.92 Static 0.80 0.55 0.80 0.55 0.90 0.68 0.92 0.72 0.92 Static + Graph 0.84 0.60 0.81 0.56 0.90 0.66 0.92 0.73 0.92 Static + SQL 0.86 0.64 0.86 0.65 0.93 0.76 0.94 0.78 0.94 Static + Dynamic 0.86 0.66 0.86 0.65 0.92 0.73 0.94 0.77 0.94 Static + Graph + SQL 0.87 0.67 0.84 0.62 0.92 0.74 0.94 0.78 0.93 Static + Graph + SQL + Dyn. 0.89 0.70 0.88 0.69 0.94 0.80 0.95 0.83 0.95
0.75 0.74 0.74 0.80 0.79 0.78 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. LR Feature Set
Acc
SVM F1
D
DT
F1 0.81 0.94 0.95 0.96 0.97 0.96 0.98
Beyond the RDBMS engines used in the main evaluation, tensoraware DBMSs such as TileDB and SciDB are natural candidates for quantum circuit simulation. They expose array-oriented storage and execution abstractions that appear well matched to tensor contractions. However, using them fairly requires significant effort because InferQ currently emits SQL workloads whose core operations are joins and aggregations. TileDB is an array storage engine for dense and sparse multidimensional 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
Acc
F1
Acc
XGB
SQL 0.75 0.72 0.75 0.72 0.83 0.79 0.86 0.82 0.85 Static 0.87 0.85 0.87 0.84 0.93 0.92 0.95 0.93 0.95 Static + Graph 0.90 0.87 0.89 0.87 0.93 0.91 0.96 0.94 0.96 Static + SQL 0.89 0.87 0.89 0.87 0.94 0.93 0.96 0.95 0.97 Static + Dynamic 0.94 0.92 0.94 0.93 0.95 0.94 0.97 0.96 0.97 Static + Graph + SQL 0.90 0.88 0.90 0.88 0.94 0.92 0.97 0.96 0.97 Static + Graph + SQL + Dyn. 0.94 0.93 0.94 0.93 0.96 0.95 0.98 0.97 0.98
Tensor-Aware DBMSs
F1
RF
Acc
Combining these results with the accuracy and F1 results in Tables 13 and 14, we observe that XGBoost provides the best overall trade-off between predictive performance and inference efficiency. Although Decision Trees have the lowest inference time for both routing tasks, requiring 0.0102 s for runtime-optimal routing 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 memoryoptimal 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.
Acc
F1
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
LR SVM DT RF XGB
0.12 1.80 0.10 0.79 0.36
0.07 0.90 0.10 0.72 0.34
Model
Runtime-Optimal Routing
Memory-Optimal Routing
LR SVM DT RF XGB
0.0154 0.1951 0.0102 0.1319 0.0139
0.0139 0.0943 0.0098 0.1076 0.0135
Inference time over 1,541 samples (s)
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 dropin 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 Since InferQ emits 20 TileDB-MariaDB/MyTile documentation: https://github.com/TileDB-Inc/Ti
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.
leDB-MariaDB. 21 SciDB-Py documentation: https://paradigm4.github.io/SciDB-Py/guide.htm l.
InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation
DB performance trends median +/- min/max band across circuits top: time (s) | bottom: memory (KB) Time vs sparsity 100
10 1
10 1
10 2 10 3 10 4
ducksql np-mps np-one-shot psql
3.0
3.5
4.0
4.5 5.0 5.5 num_qubits
6.0
scidb sqlite umbra
6.5
7.0
scidb sqlite umbra
10 2 10 3 10 4
sparse (0-0.33)
mixed (0.33-0.67)
100 10 1 10 2
10 4
dense (0.67-1.0)
8
6.0
6.5
7.0
10 12 num_gates
14
16
scidb sqlite umbra
ducksql np-mps np-one-shot psql
14
16
scidb sqlite umbra
med mem 104
4.5 5.0 5.5 num_qubits
6
105
med mem
med mem 104
4.0
4
Memory vs gates
ducksql np-mps np-one-shot psql
105
3.5
scidb sqlite umbra
Memory vs sparsity
scidb sqlite umbra
105
3.0
ducksql np-mps np-one-shot psql
10 3
Memory vs qubits ducksql np-mps np-one-shot psql
Time vs gates ducksql np-mps np-one-shot psql
med time
100
med time
med time
Time vs qubits
104
sparse (0-0.33)
mixed (0.33-0.67)
dense (0.67-1.0)
4
6
8
10 12 num_gates
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 prototype 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.
slower and uses more memory than the RDBMS backends on these small circuits. The np-mps baseline is often fast, but it is approximate, whereas the DB-backed methods and np-one-shot are 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, (ii) sparse-versus-dense array selection, (iii) contraction fusion to avoid per-step materialization, and (iv) cost models for arraynative execution. It is an interesting future direction to explore which types of simulation workloads array DBMSs would be most promising for.
Experimental setting. Figure 23 reports a comparison on 11 InferQ circuits 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, and np-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 beats np-one-shot in 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
E
Support for Existing Benchmarks
In addition to circuits generated by InferQ, the evaluation pipeline can ingest circuits from established benchmark suites: SupermarQ [33], MQT Bench [31], and QASM Bench [21]. These suites provide workloads that complement our generated corpus. The compositional circuit simulation workload introduced in Sec. 3 remains necessary for controlled simulation scale, feature-space coverage, and reproducible randomized workload generation, while external suites
Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai
Table 16: External benchmark-suite circuit entries supported by the InferQ ingestion pipeline. Per-suite counts are before cross-suite deduplication. Benchmark suite
# circuit entries
SupermarQ MQT Bench QASM Bench
8 34 67
Total (after deduplication)
85
provide an additional validation source based on named benchmark circuits. All imported circuits are normalized to Qiskit QuantumCircuit objects and tagged with their source suite and benchmark name. The ingestion pipeline then applies the same SQL generation, feature extraction, and the rest of the workflow used for InferQgenerated 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, InferQ also records a deduplicated inventory; after deduplication, the external benchmark inventory covers 85 unique algorithm families. The complete persuite circuit-family list and ingestion commands are provided in the Benchmark Algorithms table in the online documentation.23
F
Table 17: Median properties of completed SQLite–Aer profiling runs, grouped by the backend with lower runtime. CTE sizes are estimated from intermediate-relation cardinalities and row widths.
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 program represented as a chain of Common Table Expressions (CTEs). Each contraction step is implemented as a join followed by an aggregation. 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 results25 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 24We 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
Number of cases Total CTEs Contraction CTEs Total estimated CTE size Largest intermediate CTE Final result rows SQLite runtime Fastest Aer runtime
SQLite faster
Aer faster
46 26.5 22 2.9 KB 256 B 16 2.03 ms 2.82 ms
116 55 49 10.5 KB 1.0 KB 128 6.63 ms 3.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 preserves sparsity, SQLite materializes only a small number of nonzero amplitudes, and the join-and-aggregate pipeline can complete before 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 contraction 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 contraction sequence their cumulative cost can dominate the arithmetic. Thus, when Aer is faster, it is not because SQLite fails to represent 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 interpretation. 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 consumption 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 induce heterogeneous query shapes (e.g., short vs. long CTE chains) on which simulator method is applicable and efficient for each cirand different bottlenecks (overhead-dominated vs. memory- and cuit. In the profiling runs, the fastest Aer method varies across I/O-dominated). We therefore introduce workload stratification by circuits: unitary is fastest in 46 cases, automatic in 42 cases, circuit size. For the 162-circuit all-engine MLOS validation set,28 we statevector in 37 cases, extended\_stabilizer in 26 cases, ma split circuits by the median circuit_size (33 gates): circuits with trix\_product\_state in 5 cases, density\_matrix in 4 cases, circuit_size ≤ 33 use a small_size profile (82 circuits) and the and stabilizer in 2 cases. This indicates that a single fixed Aer remaining circuits use a large_size profile (80 circuits). This almethod is not a stable baseline for heterogeneous circuits. Some lows the tuner to select configurations appropriate for structurally circuits admit efficient specialized simulation, while others require different workloads of small and large circuits. Table 18 summaa more general representation. For peak memory, the lowest-RSS rizes the final profiles. We observed that SQLite did not obtain Aer configuration is usually statevector or density\_matrix: much performance gain from automatic tuning, so we have tuned statevector has the lowest RSS in 88 cases, density\_matrix in 49 it manually29 . cases, automatic in 14 cases, matrix\_product\_state in 9 cases, Results. Table 19 reports results after tuning on the 162-circuit and unitary in 2 cases. dataset, which are also the results for Figure 7. Overall, Qiskit Aer We do not enable Aer cache blocking in this comparison. Our Aer remains the runtime winner on most circuits (128/162). Among baseline uses the standard CPU simulator methods, whereas Aer’s the evaluated DBMS backends, only SQLite achieves runtime wins cache-blocking options (e.g., blocking_enable and blocking_qubits) (34/162); DuckDB, PostgreSQL, and Umbra do not win on runtime are documented for distributed GPU and/or multi-node simulaon this subset. In contrast, SQLite is the peak-memory winner on tion [30]. They partition the state into chunks to reduce data ex108/162 circuits (66.7%), while Qiskit Aer wins peak memory on change across distributed memory spaces, rather than providing 54/162 circuits. We have also evaluated the tuned configurations on a disk-backed CPU cache comparable to an RDBMS buffer manthe full 7,705-circuit dataset (Figure 1). The result is similar: RDBMS ager. Enabling these options would therefore change the simulator backends achieve the lowest runtime on 1,101 circuits (14.3%), and configuration instead of providing a fair comparison to SQLite’s all of these runtime wins come from the SQLite, for which tuning did relational execution. 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 Takeaway. The relative performance of SQLite and Qiskit Aer is setting, tuning increases SQLite’s peak-memory win count from governed by both representation and execution strategy. SQLite 3,196 to 3,901 circuits. is memory-efficient when sparsity keeps intermediate relations small, but Aer is faster once repeated joins, aggregations, temporary B-trees, and automatic indexes make SQL execution Take-away. Taken together with Appendix A (out-of-core) overhead dominate the contraction pipeline. and Appendix F (memory profiling), these results suggest two concrete future optimization opportunities for DBMS-backed simulation. G DBMS-Specific Tuning i) For large circuits where memory is the bottleneck, DBMS execution is uniquely useful because it can externalize operator To understand how DBMS configuration affects simulation perworkspaces and intermediate relations. For such simulation, formance, we have added DBMS-specific tuning for PostgreSQL, end-to-end performance is largely driven by spill and intermeDuckDB, and SQLite.26 We keep the circuit set and InferQ ’s SQL diate growth, motivating spill-aware planning (join ordering, generation pipeline unchanged and only vary DBMS-level configuoperator selection, and materialization control) and physical ration. design studies over intermediate tables (indexes, partitioning Automated tuning via configuration search. We initially exand layout, and caching reused intermediates) as discussed in plored manual tuning to understand the impact of major parameAppendix H. ters, but the configuration space is large, engine-specific, and not ii) For small circuits where Aer finishes in milliseconds, DBMS scalable across thousands of circuits. We therefore adopt an autoruntime is often dominated by fixed overheads (SQL compimated configuration-search workflow based on MLOS (Machine lation, planning, and repeated query execution), motivating 27 Learning for Operating Systems) : the workload is fixed, and the workload-level optimizations such as batching, reuse, and hantuner searches over DBMS parameters to minimize runtime. For dling repeated subcircuit computations across many runs. reproducibility, we document the parameter spaces, seed profiles, InferQ is a convenient tool for future database research in these and runner details in Section I. directions, because it generates controlled workloads (small or Workload-specific tuning. In preliminary experiments, we oblarge, sparse or dense) and emits database-native SQL along served that a single global configuration is suboptimal: circuits with query-shape and circuit metadata needed for systematic evaluation. 26We 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
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. Engine
Profile
Parameters
DuckDB DuckDB SQLite SQLite PostgreSQL
small_size large_size small_size large_size small_size
PostgreSQL
large_size
memory_limit=10780MB; threads=2; preserve_insertion_order=false; max_temp_directory_size=256GB memory_limit=7409MB; threads=1; preserve_insertion_order=true; max_temp_directory_size=128GB cache_mb=64; db_path=:memory:; mmap_mb=0; temp_store=MEMORY; threads=1 cache_mb=128; file-backed database; mmap_mb=128; temp_store=MEMORY; threads=1 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 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 successful Qiskit Aer method per circuit. Backend
H
Time wins
Memory wins
SQLite DuckDB PostgreSQL Umbra
34/162 0/162 0/162 0/162
108/162 0/162 0/162 0/162
RDBMS total Qiskit Aer total
34/162 128/162
108/162 54/162
Indexes, partitioning, and CTE query structure
In InferQ, each circuit is compiled into a single SQL statement of the form WITH ... SELECT, where each tensor contraction step is represented as a Common Table Expressions (CTE) and implemented 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 limits 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 usercontrolled. To enable explicit physical design, we added a second query generator which lowers the same contraction pipeline into a sequence of CREATE TEMP TABLE AS statements; each intermediate becomes a first-class relation on which indexes and partitioning can be applied. Note that this is not part of InferQ’s standard pipeline; we added it to support the experiments in this section. Systematically 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. Combined with split execution, they also define a concrete path for future physical design studies using standard database methodology. 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), (ii) partitioning and layout decisions to improve join locality and reduce spill (where the engine supports partitioned tables and partitionwise planning), and (iii) selective materialization and caching of frequently reused intermediates (e.g., repeated subcircuits) as materialized relations. Because InferQ exposes circuit features and query-shape metadata (e.g., number of contraction steps (CTEs), runtime, and spill proxies), these choices can be studied systematically 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 completed. 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 number 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 evaluate 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 computational basis (each with magnitude 2−ℎ/2 ). Figure 24 illustrates the circuit structure.
InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation
SQLite. Similar to DuckDB, here we use proc_io_write_bytes as the spill/workspace proxy. SQLite does not expose a stable querylevel temp-byte counter through Python’s sqlite3 interface, so we intentionally do not report a DB-native temp metric.
I.3
Configuration for DB tuning
We add a dedicated runner under scripts/finetuned_rdbms that reuses the same InferQ circuits and SQL generation path, but executes 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 paFigure 24: Expander circuit structure: Hadamards on ℎ seed rameters. For each engine, the tuner evaluates seed profiles (e.g., qubits followed by CNOT-only layers that expand connectivbalanced, fast, spill_safe) and then uses a black-box optimizer ity while preserving sparse support. backend (e.g., FLAML or SMAC) to propose additional configurations. Its objective is the median runtime on a pilot set; timeouts and execution failures receive a large penalty. All trials are recorded in Such sparse or highly structured states occur in practice in affine mlos_trials.csv, and the best configuration per engine is stored and stabilizer-style subroutines and in workloads where computain mlos_best_configs.json. These winning configurations are tion is restricted to a low-dimensional subspace. Moreover, even then validated on the full discovered circuit set via the fine-tuned when the final state is dense, intermediate tensors and relations durrunner using –tuning-json. Thus, the reported improvements ing contraction can be much smaller than 2𝑛 . Separately, amplitudecorrespond to DBMS-level physical execution choices rather than amplification procedures (e.g., Grover-style iterations) tend to conchanges to the circuit generator or SQL compilation. centrate probability mass onto a small subset of basis states as they Operationally, the runner generates SQL once per circuit, records iterate, and sparse Hamiltonians and sparse linear systems (as in query-shape metadata (e.g., number of CTEs/contraction steps), eigensolver and HHL-style routines) often induce structured tenand then executes the workload under the selected engine profiles sors. These regimes motivate studying DBMS backends with sparse with warm-up and timed runs, configurable timeouts, and resume representations and out-of-core execution. support. To reduce total tuning cost, we optionally use SQLite as a lightweight gate: if SQLite times out for a circuit under the tuned I.2 Spill Configuration for Out-of-core profile, we mark other engines as skipped_sqlite_timeout for experiments that circuit (i.e., we do not spend additional compute on circuits We run SQL queries on PostgreSQL, DuckDB, and SQLite, sweeping already rejected by the gate). This produces a controlled comparison Docker memory limit, e.g., 16 GB. All containers use a one-CPU of tuned physical execution while keeping the workload and SQL quota, swap is disabled by setting Docker –memory-swap equal to generation fixed. the memory cap, and host page cache is not explicitly dropped Table 18 reports the best configurations selected and validated by between runs. DuckDB uses one thread and sets memory_limit to our tuning workflow. For DuckDB, small_size allocates a larger the cap minus a 1024 MB headroom pad (3072, 7168, and 15360 MB memory budget and modest parallelism for short query plans, for the 4, 8, and 16 GB caps, respectively). SQLite uses a 64 MB cache while disabling insertion-order preservation to enable spill-capable budget for both main and temporary schemas. PostgreSQL uses operator choices; large_size reduces memory and parallelism the tuned PostgreSQL 12.22 container, with the server container to limit concurrent memory pressure and temp-space exposure capped at the experiment memory limit and temp_file_limit set for deeper plans where planner/executor overhead can dominate. to 64 GB. Spill is measured as postgres_explain_temp_written For SQLite, small_size keeps the database and temporaries fully for PostgreSQL and as proc_io_write_bytes for DuckDB and in-memory to avoid filesystem overhead, whereas large_size SQLite. uses a file-backed database with a modest mmap window to staWe report spill volume using engine-specific sources when availbilize larger intermediate results while still keeping temporaries able, and otherwise use a conservative operating system level proxy. in memory. For PostgreSQL, small_size increases per-node memPostgreSQL. We compute exact temporary spill bytes from EXPLAIN ory (work_mem, temp_buffers) and enables parallel workers to (ANALYZE, BUFFERS, FORMAT JSON) by converting the reported accelerate small contractions, while constraining join enumeratemp written/read blocks to bytes using the 8192-byte block size; tion (join_collapse_limit/from_collapse_limit) to preserve we treat this value as the per-query externalization metric. the emitted join order and disabling JIT; large_size caps per-node DuckDB. We use proc_io_write_bytes as the primary spill/workspace memory and disables parallel gather to reduce worker amplification proxy, and when available we additionally parse DuckDB profiland make externalization behavior more predictable. Finally, we ing JSON fields such as temporary_storage_bytes and spilled_ include Umbra via its PostgreSQL-compatible frontend to broaden bytes for diagnostics only, since the profile schema can vary across the engine comparison to a modern compiled analytical DBMS versions. without changing the SQL workload.
Andrei Ilinescu, Aadi Patwardhan, and Rihan Hai
J
Generated Circuit Characterization
To make the generated workload distribution transparent and reproducible, InferQ records per-circuit metadata for each generated circuit and aggregates these fields over the full corpus. Figures 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 workload 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 entangling component: cx alone accounts for 26.6% of all gates, alongside common one-qubit rotations and Clifford-style operations such as ry, x, h, and rz. The remaining top gates include controlled-phase, controlled-Z, multi-controlled-X, swap, and higher-controlled variants, 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 ratio, 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 number of circuits in each (number of qubits, depth) bin using a logarithmic 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 103 , 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 resulting features include edge count, maximum and average degree, clustering coefficient, shortest-path statistics, diameter, radius, cutrelated measures, central-point dominance, and adjacency-matrix variation. These graph features capture structure that is not visible from gate count, width, or depth alone: two circuits with the same number of qubits and a similar depth can still differ substantially 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 transparent, reproducible, and analytically useful. With InferQ, users
can inspect the concrete properties that shape simulation performance, including gate composition, static circuit size, depth/width coverage, and qubit-interaction topology. This allows engine comparisons to be interpreted in terms of the circuits being simulated and helps identify which circuit families require particular simulation 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 parameters from its parameter domain Θ 𝑓 . In InferQ, 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 QFT includes final swaps, the choice of feature map and ansatz in variational templates, the number of layers in QAOA-style templates, or the number of steps and coin operators in quantum-walk templates. Structural vs. numerical parameters. In InferQ, template instantiation is staged. InferQ first fixes the structure of the subcircuit (e.g., qubit assignment, gate topology, repetition pattern, and depth contribution) from (𝑛𝑞 , 𝑑, 𝑘, 𝑟, 𝜉). If the template contains parametrized gates, InferQ then samples the numerical values (e.g., rotation angles) from template-specific distributions. This separation lets InferQ explore 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 of JOINs, predicates, and aggregates. For runtime, the Linear SVM assigns negative coefficients to num_where_clauses, num_eq_predicates, and num_agg_funcs, suggesting that queries with heavier filtering and aggregation tend to favor Qiskit Aer. In contrast, num_joins and num_and_clauses shift 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 the InferQ preprocessing cost grows as we increase the number of generated circuits. We observe near-linear scaling 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 seconds, and extracting features takes 1.9 seconds.30 This tackles Gap 30We 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, InferQ can 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. Linear SVM Feature Importance num_agg_funcs
XGBoost Classifier Feature Importance
Cumulative Execution Time: Generation vs Feature Extraction
num_where_clauses num_agg_funcs
6
num_where_clauses
num_eq_predicates
5
num_joins
num_joins
num_eq_predicates
num_and_clauses
num_and_clauses
num_select_columns 4
2
0
Importance
2
4
0.0
0.1
0.2
0.3
Importance
0.4
Figure 28: Importance of various SQL features for SVM and XGBoost trained for optimizing execution time.
Total Time (seconds)
num_select_columns
Cumulative Generation Time Cumulative Feature Extraction Time
4 3 2 1 0 0
200
400
600
Number of Circuits Processed
800
1000
Figure 30: Cumulative execution time versus number of circuits processed. The figure shows cumulative generation time, and cumulative feature extraction time.
M Figure 29: Importance of various SQL features for SVM and RF trained for optimizing memory. Take-away. InferQ scales well in preprocessing: circuit generation and (static/graph/SQL) feature extraction grow linearly and remain inexpensive. This supports building large circuit datasets for database- and learning-based analyses.
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 combinational 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:
file and a .json metadata file that records generator history and extracted features.
• the quantum circuit in a portable serialization format compatible with Qiskit, and • a feature record in JSON format containing all static, graph, and dynamic metrics.
Synergy-based generator sampling. Generator selection is historydependent rather than i.i.d. After each generator is chosen, the categorical distribution over the remaining generators is reweighted using predefined synergies between generator families. These synergies favor complementary compositions (e.g., state preparation followed by algorithmic cores and optional variational layers), discourage long runs of the same family, and enforce feasibility constraints 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 generator sequence and the global seed, the entire generator sequence is exactly reproducible.
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 features are obtained from full-state simulation. This separation allows InferQ to be extended with new feature families without recomputing 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 dynamic. 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 structures, 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 software with separate modules for circuit generation, feature extraction, and dataset management. The repository includes a locked Python environment via uv.lock and a declared interpreter version. 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 .qpy circuit
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.
Feature reproducibility. For each circuit, InferQ extracts static, graph-based, and dynamic (simulation-based) features. Feature extractors are modular and deterministic given the same simulator backend, numeric precision, and hardware configuration. For fair comparison, users should report simulator version and floatingpoint 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 representations 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 at https://github.com/InfiniD ata-Lab/InferQ/blob/main/analysis/training_data/selector_training_da ta.parquet 32We 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 compared with Qiskit Aer’s built-in “automatic” method selector.
Metric
Qiskit “Automatic” Accuracy
XGBoost
Random Forest
Accuracy
36%
64%
64%
Trained on InferQ Decision Tree KNN Logistic Regression 63%
61%
61%
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.
Naive Bayes 55%
Rank Position Method statevector density_matrix matrix_product_state extended_stabilizer
1
2
3
4
30802 17704 42288 2773
34743 20340 35959 2525
25131 7625 14537 46274
2891 948 783 41995
models experimented with, it validates our data-centric approach to this problem. Moreover, the experiment showcases that data management techniques can be used to make classical simulation of quantum computation 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. Figure 31: Bar chart displaying the imbalance between the classes being the best simulation method for minimum execution time.
Upon inspection of the features, it became clear why Naive Bayes performs weakly. There is multimodality within feature distributions 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 accuracy, it is clear from Figure 33 that it is unable to predict the smaller classes well, as 42% of the “density_matrix” and 34% “extended_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 regression 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 predictions amongst the highly imbalanced classes of representations. By outperforming Qiskit Aer’s own "automatic" selector with all
N
InferQ Feature Schema
Figure 32 illustrates the schema of how InferQ stores the extracted circuit features.
InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation
Figure 32: Schema for storing extracted circuit features. InferQ circuit data model schema. Each circuit is stored with a unique hash (primary key) and associated feature classes. InferQ entries are centered around circuits in the InferQ_Circuits table, 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.