Text-to-SQL vs writing SQL manually: when to use each
Choose how to produce your next report by comparing the work required before and after the SQL is written.
By the Datarelix Team · Published · Updated · Last verified
Text-to-SQL produces SQL from a written question; how text-to-SQL generates database queries explains the mechanism. Writing SQL manually produces the same kind of database instruction, with the author choosing the syntax directly. Both approaches require database access, a definition of the measure and a way to check the answer.
For someone who knows the business question but not SQL, text-to-SQL can provide a starting query and result. For an analyst developing a complex calculation, manual SQL offers direct control over each expression. These approaches can be used together.
Compare the same reporting task
Suppose you need paid order value by region for August 2026. The source has one row per order, an order date, a region, a status and an amount in EUR.
| Step | Text-to-SQL workflow | Manual SQL workflow |
|---|---|---|
| Define the question | State period, currency, status and grouping in words | Establish the same definitions before coding |
| Find the data | Give the tool access and relevant schema descriptions | Inspect the schema and identify fields and relationships |
| Produce SQL | Review the generated statement | Write the filters, grouping and aggregation |
| Execute | Use the tool’s permitted execution workflow | Run in a SQL client with the approved identity |
| Check results | Compare definitions and a known total; ask for SQL review where needed | Check the same definitions, totals and joins |
| Revise | Clarify the question and inspect the revised SQL | Edit the relevant expressions directly |
| Reuse | Save the answer or chart if the product supports it | Save the script or put it into a reporting tool |
Setup, schema complexity and familiarity with SQL affect the effort for either route.
What the query should mean
Example PostgreSQL:
SELECT region, SUM(total_eur) AS paid_order_value_eur
FROM orders
WHERE status = 'paid'
AND ordered_at >= DATE '2026-08-01'
AND ordered_at < DATE '2026-09-01'
GROUP BY region
ORDER BY paid_order_value_eur DESC;
The half-open date interval includes August and excludes September 1. This calculation assumes total_eur is an order-level amount. It does not deduct refunds stored elsewhere. Calling this “net revenue” without changing the calculation would mislabel the result, regardless of who wrote the SQL.
If the result is North EUR 1,200 and South EUR 800, the total is EUR 2,000. Confirm that figure against an approved report or a small independently checked sample. A chart should preserve those values and state that they are before refunds.
When should you use each approach?
Use text-to-SQL when you can describe a reporting question clearly and want help turning it into a first query. In Datarelix, the result includes the executed SQL and source information, and a checked chart can be saved to a private dashboard. You need a reachable supported source; dashboard refresh is manual and each dashboard uses one connection.
Use manual SQL when you need precise control over complex joins, a specialised database feature, or a script managed alongside other development work. If the task changes data or database structure, use an appropriate authorised database workflow: Datarelix’s reporting queries are read-only.
If you already use a SQL editor, inspect its available AI features before assuming you need a separate tool. The decision may be about charting, repeat reporting and who uses the result as much as about generating SQL.
Combine generated SQL with an analyst’s review
An analyst can use text-to-SQL to draft a familiar report, inspect its assumptions, and continue in an SQL editor when direct control is useful. For the regional example, review whether region is recorded on the order or comes from the customer’s current address. Those choices can produce different historical reports even with identical date filters; record the answer as schema context and business definitions so the next question starts from it.
When revising to wholesale customers, decide whether the segment is measured at order time or today. Check that the join key is unique on the customer side, then reconcile one region before saving the revised output. The natural-language request expresses the intent; the query makes its implementation reviewable.
For repeated analysis, keep the definition and successful SQL together. A personal chart can use a stored calculation; a maintained reporting view may be appropriate when the same business rule is used in several reports. Neither handwriting nor generation removes that maintenance decision.
Make one revision and check it
Change the request to “include only wholesale customers.” That can require a customer-table join. Check that each order appears once after the join and that the customer segment means what you intended. A plausible lower total is not enough to establish correctness.
Use the verification guide for the review. For the report itself, follow weekly sales reporting or connect a source and try one question with a known answer.