Jekyll2026-09-10T11:17:31+00:00https://aadipat.github.io/feed.xmlblankPersonal website of Aadi Patwardhan — CS & Engineering (Honours) student at TU Delft, student researcher in quantum computing and AI. InferQ: can a database simulate a quantum computer?2026-09-10T00:00:00+00:002026-09-10T00:00:00+00:00https://aadipat.github.io/blog/2026/inferqSimulating 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).

]]>QEC lake: a data lake for quantum error correction2026-06-02T00:00:00+00:002026-06-02T00:00:00+00:00https://aadipat.github.io/blog/2026/qec-lakeQuantum error correction (QEC) is what makes a fault-tolerant quantum computer possible: physical qubits are noisy, so QEC codes spread logical information across many physical qubits and use repeated syndrome measurements to detect and correct errors. Decoding — turning a stream of noisy syndrome measurements into “which qubits flipped” — is increasingly done with AI models rather than hand-designed algorithms, because learned decoders can adapt to the messy, correlated noise of real hardware better than classical decoders can.

The catch: training a good decoder needs a lot of QEC data, and that data is a mess. Every code family (surface codes, color codes, …) and every hardware platform emits data in its own schema. Datasets are scattered across incompatible repositories, often undocumented, and rarely large enough on their own. Comparing two decoders fairly is hard when they were never trained or evaluated on comparable data in the first place.

QEC lake, the paper Max de Groot, Andrei Ilinescu, Aditya Shankar, Yuandou Wang, Wenbo Sun, Floris Geerts, Rihan Hai and I demoed at VLDB 2026, is a domain-specific data lake built to fix exactly this. It:

  • Continuously crawls and refreshes open QEC datasets from across code families and hardware platforms into one place.
  • Generates new data — user-configurable simulated circuits, and synthetic variants derived from real hardware data — to fill in the gaps where real data is scarce.
  • Manages metadata for discovery, so a researcher can actually find the subset of data relevant to their code family, distance, and noise model instead of digging through disconnected repos.
  • Prepares model-ready inputs, converting heterogeneous raw data into the tabular formats tree-based models and tabular foundation models expect, plus an AI-assisted natural-language interface for exploring the data.

At the VLDB demo, attendees ingested sources, generated new datasets on the spot, explored them through structured and natural-language queries, and exported model-ready training data — the full pipeline from “scattered QEC data” to “something a decoder can train on,” in one sitting.

To make the underlying decoding problem tangible for a general audience (not everyone at a database conference has a quantum information background), I also built QEC Tiles: Stabilizer Rush, a small browser game where you play the decoder in real time.

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

]]>My webpage is live!2025-07-23T00:00:00+00:002025-07-23T00:00:00+00:00https://aadipat.github.io/blog/2025/mywebpageI made this webpage using the al folio jekyll theme. I forked the repository and deployed the webpage using github pages on my username.github.io.

In about 5 minutes, the gh-pages branch was created which I set as the deploy branch. I also needed to give read write prviledges under settings/actions/general.

To work on it locally, I am using the dev container that they have already provided me with.

I am excited to use this page for documenting my insights, projects and sharing them with you!

]]>