Natural language query layer for analysts on relational databases

The moment a business analyst or data analyst realizes they need a number from a database — and the only person who can write the query is a backend engineer who has a two-day backlog — is the moment the entire promise of relational databases breaks down for non-technical users. The complaints here are precise: users say they need 'in-depth knowledge of query writing skills', struggle with 'unnecessary requirements for single and double quotes', and report that 'long queries are needed even for small amounts of data'. These are not database performance problems — they are access problems that manifest as productivity problems.

This gap persists because BI tools tend to abstract over raw SQL with drag-and-drop interfaces that work fine for simple aggregations but fall apart the moment a user needs a filtered join across three tables or a rolling average by region. The buyer of the BI tool is usually a VP of Analytics or CTO who can write SQL — they don't feel the pain. The person who feels it is a marketing analyst or operations manager who never learned SQL and has to file a request ticket every time they need a number.

What's missing is something narrow: a layer that sits directly on top of an existing relational database, lets a non-technical user describe what they want in plain language, translates that into a validated SQL query the user can inspect, runs it, and returns a result — without requiring them to learn join syntax or quote conventions. The business recurrence is real: analysts need new numbers every week, schemas change, new tables get added, and the question backlog never clears on its own.

What to build

Build a web interface that connects to an existing PostgreSQL, MySQL, or Aurora database via a read-only connection, lets a non-technical user type a question in plain English, generates and displays the SQL it intends to run for review, executes it, and returns results as a table or chart — with schema context refreshed automatically when tables change.

Where to start

Target ops teams at e-commerce companies on Shopify Plus who have a PostgreSQL backend with a relatively predictable schema — order, customer, and product tables — where the query patterns are narrow enough that accuracy on the most common question types is achievable before expanding.

The hard part

The generated SQL has to be correct enough, often enough, that analysts trust it — a single wrong result that gets used in a business decision destroys credibility, so the quality bar is higher than most natural language to SQL demos currently hit on real-world messy schemas.

How it makes money

Per-seat monthly subscription for analyst users, with the first seat free — the account admin (usually an engineer) sets it up for free and then the analysts who actually use it are the paid seats, which naturally expands as usage spreads across a team.