MariaDB QPS Spike vs Ecom Order Rate, MariaDB

Card class: Hero • Category: Cross-Channel: Revenue at Risk

At a glance

A dual-axis view that plots MariaDB queries-per-second against the storefront’s order rate on the same timeline. When the two lines move together, your database load is paying for itself: more queries, more orders. When QPS spikes but orders stay flat, the database is working hard for nothing, and the usual culprit is a bot, a scraper, or a runaway integration hammering the catalogue. This card turns a raw database-load signal into a revenue-relevance question: is this traffic worth serving?


What it tracks	MariaDB queries per second on one axis, the connected storefront’s order rate on the other, over a rolling 15-minute window, so load and value can be read against each other.
Data source	The `Questions` (or `Queries`) global status counter on MariaDB, sampled over time for QPS, plotted against order events from the Shopify, BigCommerce or Adobe Commerce connector.
Time window	`15m` rolling, refreshed on the live poll.
Alert trigger	`qps spike with no order spike (= bot / scraper)`, a QPS surge that is not matched by an order-rate surge.
Roles	owner, engineering, operations

Calculation

QPS is derived from the Questions status counter (or Queries, depending on whether you want to include stored-procedure internals): Vortex IQ samples the counter, takes the delta between samples, and divides by the elapsed seconds to produce queries per second. The order rate is the count of order events from the linked storefront over the same window, expressed per minute or per second to share the axis. The card plots both on a dual axis so the correlation between them is the readable signal, not either line alone. Per the card’s alert rule, the trigger condition is a qps spike with no order spike: the engine looks for a window where QPS rises sharply above its recent baseline while the order rate stays flat. That divergence is the bot/scraper fingerprint, traffic that costs you database load and infrastructure spend while generating zero revenue. A spike in both lines together is healthy demand and does not alert.

Worked example

A Shopify store on a self-managed MariaDB backend (custom catalogue service) normally runs ~1,200 QPS at ~3 orders/min during the day. Snapshot taken 14 Apr 26, 13:20 to 13:35 BST, 15-minute window.

Time	QPS	Orders/min	Reading
13:20	1,180	3	Baseline, healthy ratio
13:25	1,240	3	Baseline
13:30	6,900	3	QPS spike, order rate flat
13:35	7,150	2	Spike sustained, orders if anything down

QPS has jumped 5.8x while orders are flat (and dipping). The headline shows the alert fired: QPS spike with no order spike. This is not a flash sale; a sale would lift both lines. It is the signature of a catalogue scraper crawling every product and variant page as fast as it can, each page firing a burst of database reads. The on-call response runs in two tracks:

Protect the database now. A 6x query load can saturate the connection pool and slow legitimate shoppers. Check Connection Pool Saturation % and Query Latency p95 (ms); if real customers are now seeing slow pages, the scraper is causing collateral damage and needs blocking at the WAF or CDN immediately.
Confirm it is a scraper, not a bug. Pull Top 10 Slowest Queries (digest) and SHOW PROCESSLIST. A scraper shows as a flood of identical catalogue-read digests from a narrow set of source IPs. A runaway integration or an N+1 regression after a deploy shows a different fingerprint (often a single digest exploding in call count). The fix differs: block the IPs for a scraper, roll back or patch for a code regression.

Cost framing for the spike:
  Baseline cost: 1,200 QPS serving ~3 orders/min => load is "paid for"
  During spike: ~7,000 QPS serving ~2-3 orders/min
  ~5,800 QPS of pure overhead generating zero revenue
  Risk: pool saturation slows the ~3 orders/min of REAL shoppers
         => the scraper does not just waste capacity, it threatens conversion

If the scraper tips the pool over, the genuine 3 orders/min (at, say, £64 AOV that is ~£192/min, ~£11,500/hour of real revenue) is what is actually at stake, not the worthless scraper traffic. Three takeaways:

QPS alone is not a health metric. High QPS is good if it tracks orders and bad if it does not. This card exists precisely because a raw QPS number cannot tell you which it is; the order-rate overlay can.
The dangerous case is divergence, not magnitude. A genuine 5x QPS spike during a flash sale is fine because orders rise with it. The alert fires only when the lines decouple, because that is the only pattern that means “load without value”.
A scraper is also a database-stability risk, not just a cost. The collateral is the threat: a scraper that saturates the connection pool degrades the experience for paying shoppers. Treat a no-order QPS spike as a potential availability event, not merely a billing annoyance.

Sibling cards

Card	Why pair it with QPS Spike vs Order Rate	What the combination tells you
Queries per Second (live)	The raw QPS line this card gives revenue context to.	The live card shows magnitude; this card shows whether that magnitude is worth serving.
Connection Pool Saturation %	A QPS flood drives connection pressure.	If a no-order spike pushes saturation past 90%, the scraper is now a stability risk.
Pool Saturation Across Galera Nodes vs Traffic	The per-node view of where the QPS flood lands.	A scraper hitting one node via a sticky proxy can saturate it while siblings stay calm.
Query Latency p95 (ms)	Measures the collateral damage to real shoppers.	Latency rising during a no-order spike confirms the scraper is degrading genuine traffic.
Top 10 Slowest Queries (digest)	Identifies the digest the spike is firing.	A flood of one catalogue-read digest is the scraper’s fingerprint.
Slow Queries During Checkout Window (5m)	Checks whether the spike is hurting checkout specifically.	If checkout queries slow during the spike, the scraper is directly threatening conversion.
MariaDB Inventory Rows vs Ecom Inventory Count	The other cross-channel revenue-at-risk card.	A runaway sync job can also spike QPS with no orders; the inventory card helps tell sync from scraper.
MariaDB Health Score	The executive roll-up.	A no-order spike may not move the health score until the pool saturates; read both.

Reconciling against the source

Where to look in MariaDB’s own tooling:

Compute QPS yourself from the counter: sample SHOW GLOBAL STATUS LIKE 'Questions'; (or 'Queries') twice a few seconds apart and divide the delta by elapsed seconds. SHOW GLOBAL STATUS LIKE 'Uptime'; gives the lifetime average (Questions / Uptime). SHOW PROCESSLIST; or SELECT * FROM information_schema.PROCESSLIST reveals who is running the flood and from which host. performance_schema.events_statements_summary_by_digest shows which query shapes are exploding in COUNT_STAR. On managed platforms: AWS RDS / Aurora “Queries” CloudWatch metric or Performance Insights, SkySQL monitoring QPS panel.

The order-rate axis is verified against the storefront’s own analytics: Shopify Analytics orders-over-time, BigCommerce Analytics, or Adobe Commerce Reports → Orders. Why our number may legitimately differ from a manual reading:

Reason	Direction	Why
Questions vs Queries	Our QPS can be higher or lower	`Questions` excludes statements run inside stored procedures; `Queries` includes them. The connector documents which it samples; a manual reading of the other counter will differ.
Sample interval	Smoothing	Vortex IQ samples on the live poll; a tighter manual sample can catch a sharper instantaneous peak.
Order attribution lag	Orders appear later	Storefront order events can arrive with a short delay, so a real order spike may look momentarily flat before the orders land.
Replica vs primary QPS	Per-node variance	QPS is per instance; reads served by replicas are counted on those nodes, not the primary.

Cross-connector reconciliation:

Card	Expected relationship	What causes divergence
`shopify.total_revenue` / `bigcommerce.total_revenue` / `adobe_commerce.total_revenue`	A genuine QPS spike that tracks orders should coincide with rising revenue.	A QPS spike with flat revenue confirms the no-order (scraper) pattern.
`google_analytics.ga_property_health`	Real shopper sessions in GA4 should rise with a genuine demand spike.	A QPS spike with no GA4 session rise points at server-to-server traffic (a scraper or integration), not browsers.

Known limitations / FAQs

QPS spiked but it was a real flash sale. Why did the card not alert? Because orders rose with it, that is the design. The alert fires only on divergence: QPS up, orders flat. A flash sale lifts both lines, so the ratio stays healthy and no alert fires. If a genuine sale ever triggers the alert, it usually means orders are not landing despite the traffic (a checkout failure), which is itself worth investigating. The card alerted but it was a legitimate batch job, not a scraper. How do I stop the noise? Known internal jobs (nightly reindex, analytics export, ETL) produce exactly the no-order spike fingerprint. Exclude them by source IP or user in the Sensitivity tab, or schedule them in a window the card knows to discount. Do not widen the threshold globally, as that would also hide real scrapers. Is high QPS bad? Not by itself. High QPS that tracks orders means the store is busy and the database is earning its keep. The card is agnostic about magnitude; it cares only whether the load corresponds to revenue. Use Queries per Second (live) for the raw number and this card for the “is it worth it?” judgement. Should I sample Questions or Queries for QPS? Questions counts statements sent by clients and excludes statements executed inside stored procedures and triggers; Queries includes them. For a storefront-facing read of shopper-driven load, Questions is usually the more meaningful counter. The connector documents which it uses; match it when reconciling manually. A no-order QPS spike is hitting only one Galera node. Why? A scraper coming through a sticky-session proxy or hitting one hard-coded node concentrates its flood there. That node can saturate while siblings stay idle. Cross-reference Pool Saturation Across Galera Nodes vs Traffic to see the per-node picture and rebalance or block at the proxy. Does this card work without a storefront connector? No. The order-rate axis comes from the linked Shopify, BigCommerce or Adobe Commerce connector. Without it the card cannot answer the core question (is this load generating orders?) and stays empty. Link the storefront connector to activate the dual-axis view. Could a no-order spike be a code regression rather than a scraper? Yes, and the distinction matters. A scraper shows as many catalogue-read queries from a few external IPs; a regression (for example a new N+1 query after a deploy) shows as one digest exploding in call count from your own application servers. Use Top 10 Slowest Queries (digest) and SHOW PROCESSLIST to tell them apart: block IPs for a scraper, roll back or patch for a regression.

Tracked live in Vortex IQ Nerve Centre

MariaDB QPS Spike vs Ecom Order Rate is one of hundreds of KPI pulses Vortex IQ tracks across MariaDB and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.

​At a glance

​Calculation

​Worked example

​Sibling cards

​Reconciling against the source

​Known limitations / FAQs

​Tracked live in Vortex IQ Nerve Centre