See a session · about 4 minutes
One week, one database, one conversation.
A store's evening sales drop by a third. Follow an AI assistant with NexQL as it finds out why, from the live database: narrowed to one slow request, explained, fixed without locking payments, and confirmed recovered.
- Seven questions, Monday to Tuesday
- Scroll to follow along
- Tool names open their docs
The evening drop
head of online store
Sales were down about 4% last week. Can you tell me why?
Claude + NexQL
Checked the database
- list_schemaslooked at what this database holds11ms
- run_selectcounted orders for every hour of the week184ms
- run_selectcompared it with the week before96ms
Mornings and afternoons are completely normal. The entire drop happens between 6pm and 10pm — the busiest stretch of the day, when about a third of all orders are placed.
- where the drop is
- 6–10pm
- orders in that window
- −31%
- sales missed
- $212K
Where shoppers leave
data analyst
Where in the checkout are people giving up?
Claude + NexQL
Checked the database
- search_schemafound the tables behind checkout9ms
- get_join_pathlinked website visits to real orders17ms
- run_selectmeasured how far each visit got240ms
They get all the way to the payment page and then leave. Of every 100 evening shoppers who open a cart, 76 reach payment but only 57 finish — and the ones who quit had been watching a loading spinner for about nine seconds.
- average wait before quitting
- 9 seconds
- lost on the payment page
- 19 in 100
| STEP | GET THERE | LEAVE HERE |
|---|---|---|
| Opens the cart | 100 | — |
| Enters address | 94 | 6 |
| Reaches payment | 76 | 18 |
| Completes the order | 57 | 19 |
One slow request
data analyst
Is the whole site slow in the evening, or just that page?
Claude + NexQL
Checked the database
- db_health_checkran the general health checks140ms
- slow_queriesranked what takes the most time61ms
- table_statschecked size and activity per table29ms
Just one thing. The database itself is in good shape — but a single request, the one that adds up the cart total, is using almost half of all the evening capacity. Nothing else has changed.
- slow request
- 1
- of evening capacity
- 46%
- The cart total request is using 46% of the eveningIt adds up items and stock levels for the cart page.
- Memory, connections and disk are all healthyNo warnings outside this one request.
- No other request is above 17%Payments, prices and logins are unchanged from last month.
Why only after 6pm
engineer
Why is that only slow after 6pm?
Claude + NexQL
Checked the database
- explain_queryasked the database how it runs that request74ms
- table_statslooked at the stock table26ms
- sample_valuessampled tonight’s stock rows19ms
It is working from an eleven-day-old summary of the stock table. That summary says only about 40 rows will match, so the database checks them one at a time. After the evening restock there are 8,100 — and checking those one at a time is what takes nine seconds.
- since the summary updated
- 11 days
- off in its estimate
- 200×
| EXPECTED | ACTUAL | |
|---|---|---|
| Rows to check | 40 | 8,100 |
| Time to answer | 30 ms | 9,000 ms |
| Method chosen | one at a time | needs bulk match |
The safe fix
engineer
What is the safest fix we can ship today?
Claude + NexQL
Checked the database
- check_ddl_safetytested the fix before running it34ms
- get_ddlchecked how the table is built21ms
- auto_tune_queryproposed a faster approach52ms
Two small pieces of work, and one trap to avoid. Refreshing the summary is instant. The shortcut that keeps it fast has to be added in two steps — written the obvious way, in one step, it would freeze every payment for four to seven minutes.
- pause, done safely
- 0.2 sec
- pause, done the obvious way
- 4–7 min
- Refresh the stock summaryThree seconds, nothing goes offline.
- Add the shortcut in two steps, not onePayments pause for under a fifth of a second.
- Do not run it as a single commandThat version locks payments for four to seven minutes — the table is split into nine parts and all of them freeze.
- Both steps can be undone in seconds if anything looks wrong.
Did it work?
engineer
It is live. Did it work?
Claude + NexQL
Checked the database
- explain_queryconfirmed the new approach is being used68ms
- slow_queriescompared tonight with last night58ms
- db_health_checkreran the health checks: no warnings132ms
Yes. The cart total now comes back in 31 milliseconds instead of 812 — about 26 times faster — and no single request is taking more than 9% of the evening.
- cart total
- 26× faster
- warnings left
- 0
Sales are back
head of online store
Are sales back to normal?
Claude + NexQL
Checked the database
- run_selectcounted last night’s orders per hour176ms
- run_selectcompared with the same night last week104ms
- run_selectchecked carts abandoned at payment88ms
Better than normal. Last night’s evening orders came in slightly ahead of the daytime rate, and the payment page lost 2 shoppers in 100 instead of 19. That is $28.4K of sales recovered in a single night.
- orders vs last week
- +4.1%
- recovered, first night
- $28.4K
- question to fix
- 1 day
Tools in this session
Each one is explained in the docs: what it does, how it works and what it needs.
search_schemaFinds tables, views and functions that match your words.get_join_pathWorks out how two tables connect.sample_valuesShows a handful of real values from one column.get_ddlReturns the definition of a table, view, function or index.list_schemasLists the schemas in the current database.run_selectRuns a read-only query and returns the rows.explain_queryShows how Postgres plans to run a query, without running it.auto_tune_querySuggests step-by-step fixes for a slow query.db_health_checkChecks for common problems and reports them.table_statsShows size and activity for one table.slow_queriesLists the slowest queries the database has seen.check_ddl_safetyWarns about schema changes that would lock or rewrite a table.