InferQ: A Database-Oriented Benchmark for Quantum Circuits Simulation

AI summary

Overview

Research area: Quantum computing meets data management — specifically, benchmarking relational database systems (RDBMSs) as engines for simulating quantum circuits.

Technical level: Intermediate. Readers should be comfortable with basic SQL and the circuit model of quantum computation; the paper itself supplies the necessary background on qubits, gates, and state vectors in Section 2.

Scope: The paper introduces InferQ, a database-oriented benchmark that generates diverse, compositionally structured quantum circuits, emits each simulation task as an executable SQL workload, and extracts circuit and query features to characterize that workload across RDBMS engines and the Qiskit Aer simulator.

What This Paper Is About

Recent work has shown that a relational database can simulate a quantum circuit by compiling the simulation into SQL join-and-aggregate queries that implement tensor contractions. Those early results, however, covered only a narrow set of highly structured circuits — for example, GHZ and W state preparation and QFT — so database researchers had no systematic way to study query optimization, physical design, or engine selection for this workload class. InferQ closes that gap by generating general, compositionally assembled circuits at scale, packaging each one with an RDBMS-ready SQL workload and a feature record, and releasing a dataset of 202,975 circuits.

Key Contributions

1. A relational-form benchmark for circuit simulation. InferQ produces quantum circuit simulation workloads as SQL, so they can be executed, inspected, and optimized directly inside RDBMS engines, rather than being distributed only as QASM/QPY files for quantum toolchains.

2. A template-based compositional generator. Circuits are assembled from a library of quantum primitive templates (StatePrep, HamSim, QFT, Oracle/A, ModularExp, GroverIter, AmpAmpl, QPE, Variational, Random, AmpEst, Measure, bracketed by Start and End) using hard feasibility constraints plus soft "synergy rules" that reweight the next template choice based on history. The paper frames this as a Markov transition process, which lets the benchmark scale circuit size while preserving realistic structure.

3. Four groups of extracted features. For each circuit, InferQ extracts static, graph, SQL, and dynamic features, enabling systematic workload characterization and correlation with database performance. Static, graph, and SQL features are computed before simulation; dynamic features require the simulation to complete.

4. An empirical characterization of when SQL-based simulation wins. The paper quantifies on InferQ workloads when RDBMS-driven simulation is competitive with Qiskit Aer, including memory-efficient and out-of-core cases, and shows that lightweight machine learning models built on InferQ features can predict which backend is preferable.

Main Findings

• RDBMSs often use less memory than Qiskit Aer. Across the engines tested (PostgreSQL, SQLite, DuckDB, and Umbra) and Qiskit Aer, RDBMSs achieve better peak memory usage than Qiskit Aer on more than 50% of the circuits generated by InferQ.

• Runtime and memory leadership is split, not uniform. Figure 1 reports, across 7,705 circuits, the share of cases in which RDBMSs executing the emitted SQL or Qiskit Aer achieves the lowest runtime and the lowest peak memory — the paper presents this as a per-metric split rather than a single winner.

• SQL execution is workload-dependent, as prior work foreshadowed. The paper cites that under a 2GB memory limit, DuckDB simulates up to 4,000,862 qubits for GHZ-state preparation and up to 53,017 qubits for W-state preparation, but only 14 qubits for the dense QFT circuit under the same setting. GHZ is a stabilizer circuit using only Clifford gates (Hadamard, CNOT, Phase) and is classically efficient by the Gottesman–Knill theorem.

• Cheap models can route between backends. Using InferQ features, linear and tree-based models predict when SQL execution is preferable with accuracy up to 95.6% for runtime and 97.4% for memory, enabling data-centric simulator selection.

• Quantum workloads differ structurally from ML tensor workloads. A 50-qubit state vector has 2^50 ≈ 1.13 × 10^15 amplitudes, requiring about 16 PB to store densely, while each gate is only a 2×2 or 4×4 operator applied across that exponential index space. The computation is a long, dependency-constrained sequence of small updates whose sparsity can collapse abruptly at entangling operations — not a few large dense matrix products like attention's QKᵀ and QV.

• A large public dataset accompanies the benchmark. InferQ releases 202,975 circuits along with a web-based viewer supporting search, filtering, and download of circuits and feature records.

• Generation is exactly reproducible. A global random seed is a first-class parameter, so given the seed and the emitted template sequence, both subcircuit structure and numerical gate parameters replay identically — provenance records store the template sequence, sampled parameters, and global statistics such as depth and gate counts.

Methodology in Plain English

The authors borrow the design pattern of database benchmarks like TPC-H, TPC-DS, and the Join Order Benchmark: parameterized templates rather than a fixed list of hand-written instances.

Generation proceeds in four steps. First, InferQ picks an ordered sequence of templates, starting from a Start symbol. The choice is history-dependent: a hard feasibility mask zeroes out templates that don't make sense after the current one, and soft synergy rules — triples of a trigger set, a target set, and a multiplicative weight β — boost or suppress candidates that commonly co-occur in real algorithms (for example StatePrep → HamSim, ModularExp → QPE, or A → GroverIter → AmpEst). Second, it samples global parameters (qubit range, depth range, repetition range, evaluation-qubit range, whether to measure, and the seed) uniformly from user-supplied ranges, which act as scale factors for the resulting SQL workload. Third, each selected template is instantiated into a subcircuit by binding a parameter tuple of qubit count, depth, evaluation-qubit count, repetition count, and template-specific configuration. Fourth, the subcircuits are composed in order into one circuit, and generation stops either at a maximum template count or by a probabilistic stopping rule.

Each finished circuit is then translated to SQL by extending an existing package that writes the circuit in Einstein-summation form and converts tensor contractions into relational joins and aggregations, following the approach of Blacher et al. Feature extraction runs over the circuit and query to produce static, graph, SQL, and dynamic descriptors. Finally, the generated workloads are executed on PostgreSQL, SQLite, DuckDB, and Umbra and compared against Qiskit Aer on runtime and peak memory, and the resulting measurements are used to train lightweight linear and tree-based models that predict the better backend.

Why This Matters

Impact on research. The benchmark turns quantum circuit simulation into a first-class database workload, making join ordering, materialization, indexing, partitioning, spill behavior, and cardinality estimation studiable for a workload class the database community has only touched through isolated case studies. It also gives the quantum side a systematic way to ask when a classical engine is the right simulator rather than assuming one.

Real-world applications:

• Simulator selection in quantum software stacks. A learned router built on InferQ features could automatically send a circuit to an RDBMS or to a state-vector simulator based on predicted runtime and memory, without the user benchmarking both.

• Memory-constrained simulation environments. Laptops, CI runners, and shared clusters with hard memory caps can exploit RDBMS out-of-core and spill behavior for circuits that would exhaust a dense state-vector simulator.

• Quantum algorithm development and debugging. Developers validating circuits before hardware execution benefit from knowing which backend will finish within their resource budget.

• Benchmarking and procurement of analytical engines. Because the workloads are SQL, they become a new stress test for query optimizers and execution engines on long chains of small, dependency-constrained joins.

Industry relevance. Data platform vendors and cloud database teams get a concrete, publicly downloadable workload corpus (202,975 circuits with precomputed features) for evaluating optimizers; quantum toolchain vendors get a data-driven argument for heterogeneous simulator backends rather than a single monolithic simulator.

Future Directions

• Optimizer and physical-design research on the emitted SQL. The paper frames this as the central opening: existing approaches have not exploited query optimization, indexing, and materialization for simulation workloads, and InferQ is meant to make that work measurable.

• Better backend selection models. Accuracy of 95.6% (runtime) and 97.4% (memory) from linear and tree-based models leaves room for stronger predictors, and for selectors that weigh runtime and memory jointly rather than per metric.

• Extending the template library and synergy rules. The design is explicitly meant to be extensible as new quantum primitives and algorithms emerge, so template coverage and transition rules can grow with the field.

• Deeper characterization of where sparsity collapses. The paper identifies abrupt densification at entangling gates as a core difficulty, but a predictive account of intermediate cardinality growth — the quantity a query optimizer would need — is left as an open problem for the benchmark to support.

Target Audience

Database researchers and engineers working on query optimization, physical design, and execution-engine evaluation who want a non-standard, structurally unusual tensor workload; quantum computing researchers interested in classical simulation costs and simulator selection; and graduate students in either area looking for a benchmark that ships with reproducible generation, SQL workloads, features, and a large public dataset. Familiarity with SQL is assumed throughout; the quantum background needed is provided in the paper's Section 2.

Authors’ abstract

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