15. Database Search
Archived Quadratic + QRAM costQuadratic O(√N) Grover provably optimal but QRAM loading O(N) erases search advantage. Archived per Troyer framework.
Run Visualisation
Rendered from the committed estimate and simulator artifacts by the viz pipeline.

- Resource estimates and sampled kernel outcomes describe different programs. Neither demonstrates quantum advantage; this is not a quantum-state animation.
- No successful local-simulator histogram in the selected run source.
- Archived problem; not an active quantum-advantage candidate.
Resource Estimation (Azure Quantum RE)
Resource Breakdown
Calibration Evidence (20-Run Ensemble)
Stage D: Advantage Evidence Package
Grover speedup is provably optimal but quadratic. The oracle compilation cost is the critical variable: a naive oracle implementing the function as a circuit costs O(N) gates, completely eliminating the speedup. Only structured oracles with O(poly(n)) gate cost preserve the advantage.
- Quadratic speedup offset by large constant factors in fault-tolerant implementation
- Oracle compilation cost not included; real oracles may require O(N) gates, eliminating speedup
- 61k physical qubits for 4-qubit search; scaling to useful N requires millions of qubits
- Grover is provably optimal but constant-factor overhead may delay practical advantage to N>10^6
Noise Resilience (Depolarizing Simulation)
Ideal outcome: [Zero, One, One, One] (96% probability)
Cross-Platform Emulator Results (100 shots)
Troyer Utility-Scale Classification
Provably optimal quadratic speedup, but the QRAM assumption for data loading is critical. Without efficient QRAM, the speedup may be negated by data-access overhead.
These two numbers describe different programs
The resource estimate below is for Main.GroverSearch([7], 4, 3), the algorithm at utility scale. The Azure Quantum runs executed GroverSearchKernel(), a small kernel sized to fit today's hardware. Qubit counts and runtimes from the estimate are not measurements of the run, and the run histogram is not a sample of the estimated circuit.
Pareto Frontier: Qubits vs Runtime
The estimator returns 8 viable configurations, not one answer. Every headline figure on this page comes from the leftmost point, which uses the fewest qubits and is therefore also the slowest. Buying 1.9x the qubits cuts runtime to 0.36x.
qubit_gate_ns_e3 with surface_code, error budget 1e-3. Points are Pareto-optimal: no other configuration is better on both axes.
Multi-Model Resource Comparison
Physical qubit requirements across 6 qubit technologies × 2 QEC schemes (inspired by Troyer Architecture Series, Part 3).
| Qubit Model | QEC | Physical Qubits | Logical Qubits |
|---|---|---|---|
| Superconducting (ns, 1e-4) | surface_code | 11,718 | 18 |
| Trapped Ion (μs, 1e-4) | surface_code | 11,718 | 18 |
| Superconducting (ns, 1e-3) | surface_code | 61,122 | 18 |
| Trapped Ion (μs, 1e-3) | surface_code | 61,122 | 18 |
Problem Documentation
Problem 15 · Quantum Database Search
Overview
Unstructured database search underpins many cryptographic attacks and combinatorial problems. Grover's algorithm delivers a quadratic speedup over classical exhaustive search by amplifying probability amplitudes for marked items. This problem now includes a canonical Grover workflow in Q# plus classical query-complexity baselines and analysis plots for cross-checking scaling behavior.
Directory Layout
15_database_search/
├── estimates/ # JSON artifacts from classical / quantum workflows
├── instances/ # Dataset sizes and marked item distributions (small/medium/large)
├── plots/ # Generated figures from analyze.py
├── python/
│ ├── classical_baseline.py # Exhaustive search complexity and success probability estimates
│ └── analyze.py # Visualization of query budgets and scaling behavior
└── qsharp/
├── qsharp.json # Modern QDK project file
├── Program.qs # Canonical Grover implementation
└── GroverEstimation.qs # Resource-estimation variant
Quick Start
cd problems/15_database_search
# Classical baseline (writes estimates/classical_baseline.json)
python python/classical_baseline.py
# Visualize query complexity vs. dataset size
python python/analyze.py
# Quantum workflow (uses modern QDK qsharp Python package)
python -c "import qsharp; qsharp.init(project_root='qsharp'); print('Build OK')"
python tooling/run_all_qsharp.py # runs via qsharp Python package
Validation Highlights
- Canonical Grover implementation details and demonstrations are documented in `docs/GROVER_IMPLEMENTATION_SUMMARY.md`.
- Reported simulator success rates include:
- 93% for 16-item single-target search,
- 71% for 32-item multi-target search,
- 100% for 4096-item benchmark case.
- Classical-vs-quantum query scaling artifacts are generated in `plots/` and `estimates/classical_baseline.json`.
Objective Maturity Gate
- **Current gate**: **Stage D complete** (advantage evidence package hardened with backend uncertainty profiling, oracle overhead accounting, marked-fraction sensitivity analysis, and `projected` claim category locked).
- **Next gate target**: Maintenance promote `projected` → `demonstrated` only when hardware execution evidence is added.
Stage D evidence references for this problem:
- Backend uncertainty profiles: `estimates/backend_uncertainty_{small,medium,large}.json`.
- Oracle overhead accounting: `estimates/oracle_overhead_accounting_stage_d.md`.
- Marked-fraction sensitivity analysis: `estimates/marked_fraction_sensitivity_stage_d.md`.
- Backend readout characterization: `estimates/backend_readout_characterization_stage_d.md` + `.json`.
- Stage C evidence remains valid: executable Grover workflow in `qsharp/Program.qs`, estimator variant in `qsharp/GroverEstimation.qs`, classical comparison artifacts in `python/classical_baseline.py`, `estimates/classical_baseline.json`, and `plots/`.
DiVincenzo Readiness (Stage C/D Overlay)
| Criterion | Status | Evidence / Notes |
|---|---|---|
| Scalable qubit system | partial | Simulator-backed scaling evidence spans small to large instances; hardware resource-estimation evidence is not yet complete. |
| Initialization | met | Initial-state preparation for canonical Grover flow is explicit in qsharp/Program.qs and validated in simulator runs. |
| Coherence vs gate time | not-yet | Backend-calibrated coherence-vs-depth evidence is not yet included; current validation is simulator-centric. |
| Universal gate set | met | Canonical Grover oracle/diffuser workflow is implemented in Q# with documented circuit assumptions. |
| Qubit-specific measurement | partial | Measurement and success-rate validation are documented in simulator studies; hardware readout characterization is pending. |
Advantage Claim Contract
- **Claim category (current)**: `projected`.
- **Problem class and regime**: Unstructured search with configurable dataset size and marked-item fractions.
- **Fair baseline**: Classical exhaustive-search query model in `python/classical_baseline.py`.
- **Quantum resource scaling claim**: Grover scaling O(sqrt(N)) versus classical O(N) with simulator-backed behavior; hardware-specific performance still pending.
- **Data-loading and I/O assumptions**: Oracle construction cost and data-oracle assumptions must be included with future claims.
- **Noise/error model assumptions**: Current evidence is simulator-centric; backend-calibrated noise models remain pending.
- **Confidence/uncertainty method**: Simulator trials reported in implementation summary; backend shot-based confidence intervals remain a Stage D hardening task.
- **Residual risks**: Oracle synthesis and transpilation overhead can erode practical speedup for near-term sizes.
Stage D Hardening Package
- Stage D evidence file: `STAGE_D_ADVANTAGE_EVIDENCE.md`.
- This package defines the Stage D uncertainty/fairness hardening work needed before any promotion to a demonstrated claim category.
Reproduce It
cd problems/15_database_search
make classical # Run classical baseline
make analyze # Generate plots
make build # Validate Q# compilation
make run # Run Q# entry pointKey Files
qsharp/src/Main.qsQuantum algorithm implementationqsharp/HardwareKernel.qsAzure-submittable QIR kernelpython/classical_baseline.pyClassical reference implementationestimates/classical_baseline.jsonBaseline metrics