← Back to Dashboard

15. Database Search

Archived Quadratic + QRAM cost

Quadratic O(√N) Grover provably optimal but QRAM loading O(N) erases search advantage. Archived per Troyer framework.

Algorithm
Grover's Search Algorithm
Logical Qubits
4
Framework
Modern QDK (qsharp 1.31.0)

Run Visualisation

Rendered from the committed estimate and simulator artifacts by the viz pipeline.

Database Search: archived, stage D. Estimated logical qubits: 18; physical qubits: 61122. Simulator histogram missing. Logarithmic resource bars; sampled outcomes are separate kernel evidence, not quantum advantage. Bloch panel, returned bit 0 (zero-based result order): unavailable (No matching simulator run); no marker.
What this image is not.
  • 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)

Physical Qubits
61.1k
Logical Qubits
18
T-Gates
Rotations
Runtime
507.5μs

Resource Breakdown

Calibration Evidence (20-Run Ensemble)

Mean Value
6.700
95% CI
± 0.588
Runs
20
Std Dev
1.342

Stage D: Advantage Evidence Package

Claim Category
projected
Theoretical Speedup
Quadratic (provably optimal)
Crossover Estimate
No practical crossover identified: with a naive O(N)-gate oracle there is none, and with a structured oracle the quadratic query saving is not expected to pay for error-correction overhead on early fault-tolerant hardware (Babbush et al., arXiv:2011.04149)
Classical
O(N) queries (optimal for unstructured search)
Quantum
O(√N) queries (provably optimal: BBBV lower bound)
Honest Assessment

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.

Residual Risks
  • 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)

p = 0.001
90.2%
p = 0.01
43.3%
p = 0.05
11.6%

Cross-Platform Emulator Results (100 shots)

Quantinuum H2-1E
[0, 1, 1, 1]
77% of shots
Rigetti QVM
[0, 1, 1, 1]
94% of shots
✓ Cross-platform agreement: both simulators find the same dominant outcome
H2-1E Distribution
Rigetti QVM Distribution

Troyer Utility-Scale Classification

Proven Speedup
Quantum Speedup
Quadratic: O(√N) vs classical O(N), provably optimal
Classical Competitor
Linear scan
Honest Assessment (Troyer Framework)

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).

■ Gate-based + Surface code (blue)
Qubit ModelQECPhysical QubitsLogical Qubits
Superconducting (ns, 1e-4)surface_code11,71818
Trapped Ion (μs, 1e-4)surface_code11,71818
Superconducting (ns, 1e-3)surface_code61,12218
Trapped Ion (μs, 1e-3)surface_code61,12218

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 point

Key Files

  • qsharp/src/Main.qs Quantum algorithm implementation
  • qsharp/HardwareKernel.qs Azure-submittable QIR kernel
  • python/classical_baseline.py Classical reference implementation
  • estimates/classical_baseline.json Baseline metrics
View on GitHub →