Fetcher.io
Ask your database a question. In plain English.
A middleware layer that sits between people and databases and removes the SQL. A finance lead asks for last quarter's margins. A customer asks for two-bedroom properties under a price cap. Both get a correct, permission-scoped answer in seconds — without a data analyst in the loop.
PostgreSQL · MySQL · MSSQL · Oracle · Snowflake · BigQuery · Redshift · Databricks
Every question about the business becomes a ticket for whoever writes SQL. Answers arrive days late, by which point the decision has already been made on a stale spreadsheet. Meanwhile your data team spends most of its week on queries that are variations of the same six questions.
Schema intelligence, no documentation
On first connection, Fetcher.io crawls the database — tables, columns, types, foreign keys, indexes — then reads column names and sample data to generate readable semantic labels. It maps prop_sqft_net to "net property area in square feet" without anyone writing a data dictionary.
Business glossary binding
Your organisation's own terms — what "downtown", "Category A" or "active customer" actually mean in your data — are stored in a vector glossary and injected into prompts, so the SQL matches how your team talks.
Queries traditional BI cannot handle
Temporal ranges, multi-condition filters, aggregation with ranking, year-over-year comparisons using window functions, and fuzzy semantic search combining pgvector similarity with structured filters.
Answers, not just tables
Raw results are interpreted into a written summary with context and caveats, alongside the formatted table and suggested follow-up questions. Export to CSV, Excel or PDF.
The difference between them is not the technology — it is what the user is permitted to see, which is enforced below the model rather than by it.
| Mode | Users | Typical query | Access scope |
|---|---|---|---|
| Internal BI | Finance, operations, HR, leadership | "Show profit margins Sep 2011–Sep 2012 versus prior year" | Full schema, read-only |
| Internal developer | Data engineers, product managers | "Find all users who churned within 30 days of signup" | Configurable schema, writes via approval workflow |
| Customer-facing | End customers on your platform | "Five properties in downtown Dubai, 2–3 bed, AED 150k–200k" | Tenant-scoped only, zero cross-tenant exposure |
| Stage | Model | Why this one |
|---|---|---|
| Query intent classification | Haiku 4.5 | Immediate feedback on whether the input is actionable, at minimal cost per classification |
| NL to SQL generation | Sonnet 5 | Strong code generation and instruction-following; handles complex multi-join queries reliably |
| Results interpretation | Opus 5 | Produces analyst-quality reading of tabular data, including the caveats a junior analyst would miss |
| Schema semantic labelling | Opus 5 | Requires real reasoning about ambiguous column names and inferred business logic |
A model writing SQL against a production database is a genuine risk. Every safeguard here sits outside the model, not inside the prompt.
Built against real schemas, not sample databases.
Fetcher.io was designed and built by our own engineering team, and it works because it was tested against messy production schemas — undocumented columns, inconsistent naming, tables nobody remembers creating.
Demos on clean sample data prove nothing. The hard part of NL2SQL is a schema that grew organically over eight years, and that is the problem this was built to survive.
Work with the team that built it →Point it at your database. See what happens.
Book a 30-minute call and we'll run Fetcher.io against a schema that looks like yours — not a demo dataset built to make it look good.