import pennylane as qml
qml.AmplitudeEmbedding(
features=x, # 2^n numbers, normalized
wires=range(n_qubits),
normalize=True,
)The whole setup for PennyLane’s amplitude embedding is one template call. It packs 1024 classical numbers into 10 qubits, because an n-qubit register carries 2^n amplitudes, so storage looks nearly free. As Davinder Singh explains on Towards Data Science, the expensive part is the circuit that builds the state from scratch. For arbitrary data it needs a number of operations that grows with the size of the data, not with the number of qubits. That gap is the quantum data loading problem. Holding data in a state and building that state are two separate costs.
What the two encodings trade
Angle encoding is the simple one: each feature becomes a rotation on its own qubit, RX, RY or RZ, so a three-feature vector needs three qubits and three gates. It is cheap to build and hopeless on width, because feature count and qubit count are the same number. Amplitude encoding puts the features into the amplitudes themselves, so n features need roughly log2(n) qubits. Four features take two qubits, and a million would fit in twenty, on paper.
Singh walks through the trade in detail. Generic state preparation for amplitude encoding can require exponentially many gates, and nobody currently knows of a loader that is efficient for arbitrary classical data. So the storage savings get paid back at load time, sometimes with more than you saved. Preprocessing catches people too: the input has to be a unit vector, per sample, so feature scaling is no longer optional. The pipeline breaks without it.
Quantum data loading has a WordPress twin
I don’t write quantum code for clients, but I debug this shape of problem every week. In WordPress the boundary sits between the database and PHP instead of between silicon and qubits, and you pay in bytes instead of gates. Autoloaded options are the cleanest example. Every row in wp_options flagged autoload is pulled from the database and unserialized on every request, before your theme renders anything. WordPress 6.6 added a Site Health check that warns you once the autoloaded total passes 800 KB. A plugin that stores a 700 KB settings array in one option row has solved its storage problem and made every page view pay for it.
Object caches have the same second cost. A cache hit still unserializes the payload, and a fat transient can cost more to unwrap than the query it replaced. That’s also why I stopped treating post meta as a place to store everything, a habit I wrote about earlier.
Where the analogy breaks down
Two differences matter. First, classical loading costs amortize: warm the cache, keep opcache happy, memoize the expensive branch, and the per-request cost drops. Quantum state preparation is paid on every run, and measurement collapses the state, so there is nothing to warm. Second, loading can destroy structure. Singh notes that spatial and temporal relationships in images or sequences are hard to preserve inside the encoding, which is the same complaint people make about serializing structured data into one blob. A blob is cheap to carry and awkward to query.
I should be clear about my limits here. I’m not a quantum researcher, so I can’t tell you how close the newer approximate loaders are to practical, and I’m not sure anyone outside those labs can right now. The PennyLane team’s own writeup on state preparation is a fair read on the question.
Questions I ask before believing a pitch
What I actually take from all this is a habit: I get suspicious of any architecture whose demo hides the loading step. Whether the pitch is a quantum model, a vector search API or a recommendation engine, I ask the same things:
- How many bytes move per request, and how many requests per page view?
- Where does that payload get cached, and what invalidates it?
- What does the first uncached request cost, in time and in money?
- Does the pipeline destroy structure the app will need to query later?
In my experience demos are solid on the model side and vague about the data path, and these questions surface that before anyone signs off on a budget.
If you’re scoping a data-heavy AI feature on a WordPress or WooCommerce site and want someone to trace the actual data path before the budget is committed, that’s work I take on.
You can check your own loading bill today:
wp db query "SELECT SUM(LENGTH(option_value)) AS bytes FROM wp_options WHERE autoload='yes';"Swap the table prefix if yours differs, or open Tools, Site Health on WordPress 6.6 or later and look for the autoloaded options warning. If a settings row is dragging hundreds of kilobytes across that boundary on every request, you’ve found the WordPress version of the same problem, and it’s a much easier one to fix.
