InferQ: can a database simulate a quantum computer?

Simulating a quantum circuit classically usually means tracking a state vector or tensor network directly, with a purpose-built simulator like Qiskit Aer doing the heavy lifting. But there’s a less obvious angle: circuit simulation is, at its core, a sequence of tensor contractions — and tensor contraction can be expressed as a join-and-aggregate SQL query. Represent two tensors as rows of (i, k, val) and (k, j, val), join them on the shared index k, multiply, and sum out k:

-- matrix multiplication w = A x B, expressed as a join-and-aggregate query
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;

That’s the whole trick — applying a gate to a quantum state is just this pattern, over and over. So: could a general-purpose relational database, with decades of engineering behind query optimization and out-of-core memory management, be a competitive quantum simulator?

Prior work showed isolated, striking results in this direction — DuckDB simulating GHZ-state preparation out to millions of qubits under a tight memory budget. But those results were on a narrow set of highly structured circuits, and it wasn’t clear when this approach generalizes versus when it falls apart (the same study found a dense circuit like the Quantum Fourier Transform tops out at just 14 qubits under identical conditions).

InferQ, published with Andrei Ilinescu and Rihan Hai at SIGMOD 2027, is a benchmark built to answer that question systematically rather than case-by-case. It:

• Generates general, compositional circuits by assembling subcircuits from a library of templates, rather than restricting to a handful of textbook circuit families.
• Compiles every circuit into an RDBMS-ready SQL workload, so the same circuit can be handed directly to PostgreSQL, SQLite, DuckDB, or Umbra.
• Extracts circuit and query features — static, graph-structural, SQL-level, and dynamic — so a workload can be characterized numerically, not just by eyeballing the circuit diagram.
• Releases a dataset of 202,975 generated circuits with all their features, plus a web-based viewer for searching, filtering, and downloading circuits.

Running this benchmark across four RDBMS engines and Qiskit Aer, we found RDBMSs achieve better peak memory usage than Aer on more than half of the generated circuits — the database approach isn’t a narrow party trick, it’s broadly competitive on memory. More interesting, though: using InferQ’s extracted features, simple linear and tree-based models can predict which engine will be faster or more memory-efficient for a given circuit with up to 95.6% (runtime) and 97.4% (memory) accuracy. That turns “should I simulate this circuit with a database or a dedicated simulator” from a case-by-case guess into a data-driven, learned decision — a small step toward automatic, workload-aware simulator selection.

This sits right alongside my earlier work on Matrix Product State simulation: both are ultimately about choosing the right computational substrate for a given circuit’s structure, whether that’s a tensor network or a relational database.

Paper, abstract, and PDF are on the publications page (Ilinescu et al., 2026).