A useful natural-language SQL workflow does more than produce a query that runs. It translates business language into explicit rules, checks those rules against your schema, and verifies the result before anyone trusts the numbers. This first lap takes one sales request from plain English to a tested PostgreSQL query.
1. Turn the sales question into an output contract
Start with a request concrete enough to verify: Show the five customers with the highest paid order revenue in January 2026, including their names, order counts, and revenue.
Before asking a model for SQL, define what the answer should contain. Here, each row represents one customer, order count means qualifying orders, and revenue means the sum of qualifying order totals. Customers without qualifying orders should not appear.
This contract prevents a plausible but incorrect answer, such as ranking customers by lifetime revenue while displaying January order counts.
2. Supply the schema and the business definitions
Give the model the relevant structure rather than asking it to guess table names. A compact schema description is enough for this example:
- customers: id is the primary key; name is the display name.
- orders: id is the primary key; customer_id references customers.id; status is text; total_amount is a non-null numeric value; created_at is a timestamp with time zone.
- Business rules: status = 'paid' identifies qualifying orders. All amounts are in USD. Revenue uses total_amount without subtracting refunds.
- Reporting boundary: January means January 1 through February 1, 2026, using UTC boundaries.
Use sanitized schema metadata, not customer records or credentials. If a definition is unknown, ask the business owner instead of letting the model invent it.
3. Ask for assumptions before requesting SQL
Use a two-stage prompt: Using PostgreSQL and the supplied schema, identify ambiguities in this request. Do not write SQL until the reporting definitions are confirmed.
One important ambiguity remains: created_at measures when an order was created, not necessarily when payment settled. For this walkthrough, explicitly confirm that the report counts currently paid orders created during January. A payment-date report would require a different timestamp.
Once confirmed, request a single read-only SELECT statement, positional parameters for date boundaries, and an explanation of joins, filters, and aggregation. Tell the model not to invent columns.
4. Configure the model connection without database access
SwiftRelay fits naturally into this drafting step if your application already uses an OpenAI-compatible SDK. Set its base URL to https://api.fastapirelay.com/v1, load the API key from an environment variable, and send the schema and confirmed request as prompt context. Sign up for SwiftRelay to try this workflow with the small gift credit available to new accounts.
Keep generation separate from execution. The model needs schema context to draft SQL; it does not need database credentials or permission to run arbitrary statements.
5. Review the generated PostgreSQL statement
A suitable query for the confirmed request is:
SELECT c.id, c.name, COUNT(*) AS order_count, SUM(o.total_amount) AS revenue FROM customers AS c JOIN orders AS o ON o.customer_id = c.id WHERE o.status = 'paid' AND o.created_at >= $1::timestamptz AND o.created_at < $2::timestamptz GROUP BY c.id, c.name ORDER BY revenue DESC, c.id ASC LIMIT 5;
Bind $1 to 2026-01-01T00:00:00Z and $2 to 2026-02-01T00:00:00Z through your database driver. The exclusive upper boundary avoids end-of-month precision mistakes. Grouping by customer ID keeps people with identical names separate, while the secondary sort makes revenue ties deterministic.
6. Test totals and date boundaries with fixtures
Create a small test dataset with known answers. One customer might have two qualifying orders worth 30 and 70 dollars, plus a pending order worth 900 dollars. Expect an order count of two and revenue of 100 dollars.
Also test an order exactly at each boundary, two customers sharing a name, and an empty reporting period. Add more than five customers to verify ranking and the row limit. Compare actual rows with expected results, not just successful execution.
7. Put validation between generated SQL and production
Review the query plan with EXPLAIN, then test execution in a controlled environment. For automated workflows, use a SQL parser, restrict accessible tables, enforce statement timeouts, and execute through a read-only database role.
Save the approved query alongside its business definitions and fixtures. Natural-language changes can then become reviewable revisions rather than silent changes to reporting logic.