Operational analytics · SQL

Your application data.
A clearer view of the work.

Count orders, track queues and summarize activity from the records your application writes.

Six records. One useful summary.

A grouped SQL query turns individual orders into counts and totals. Your application renders the returned rows as a chart, table or alert.

Source rows → SQL aggregation → application chartIllustrative dataset · USD

Operational records

shop.orders

id	status	amount_usd
o-101	paid	120
o-102	paid	80
o-103	pending	60
o-104	paid	200
o-105	pending	140
o-106	failed	50

Group and aggregate

SELECT status,
  COUNT(*) AS orders,
  SUM(amount_usd) AS total_usd
FROM shop.orders
GROUP BY status;

One result row per status, with its order count and total order value.

Render the result

Number of orders

paid

pending

failed

6 source rows → 3 status groups. Select order value to compare the sums.

From business question to SQL

Define the metric
before the dashboard.

Choose the rows that belong in the calculation, the grouping key and the meaning of the result.

Read the aggregate guide

What is waiting?: Filter pending orders, then count them by region or queue. Keep completed records outside that metric.
What has been paid?: Filter paid orders before summing their value. A total across all statuses is not paid revenue.
Which groups need attention?: Use HAVING to select groups after aggregation. Your application decides when a result creates an alert.

A plan you can inspect

See what the query
asks the engine to do.

EXPLAIN returns a plan without executing the SELECT. Inspect scans, filters and aggregates before putting a query behind a frequently refreshed dashboard.

If you expected an index scan, review the schema's index declarations and the predicate. Measure against your own data and instance configuration.

Read query plans

Inspect the pending-order query

EXPLAIN
SELECT status, COUNT(*) AS orders
FROM shop.orders
WHERE status = 'pending'
GROUP BY status;

Run this on your instance to inspect the operators chosen for your schema and indexes.

Freshness includes the application.

Querying operational records removes a separate analytical copy from this flow. The dashboard still needs a clear refresh policy.

01 · Database

Query the relevant records

Use explicit filters and the correct endpoint. Check transaction and replica behavior for the deployment you use.

02 · Application

Choose a refresh interval

Schedule requests, cache intentionally and display when the last successful query completed.

03 · Viewer

Handle the next update

Keep the previous result during refresh and surface failures. A stale chart should not appear current.

Keep the workload focused

Operational questions,
with an execution budget.

Use this approach for application dashboards, order summaries and workload queues. For large historical scans, evaluate a separate analytical workflow against your requirements.

Sorts, joins and window functions can buffer their inputs. Narrow the dataset before expensive operations; LIMIT after ORDER BY does not remove that work. Handle query limits and retry responses in the application.

Review SQL execution limits

Start with the question
your team asks every day.

Try an operational query Explore the SQL module

Your application data.A clearer view of the work.