Let anyone ask your database a question, and trust the answer.
Text-to-SQL and semantic-layer copilots that turn a plain question into a correct, governed query with charts.
What is natural language data querying?
Natural language data querying lets business users ask a plain-English question and receive a correct, governed answer with a chart, without writing SQL. Eazyware builds it with a semantic layer over your schema, validated read-only text-to-SQL, row- and column-level security, and evaluations against a golden question set, embedded in Slack, Teams or your product.
| Service line | AI-Powered Product Engineering |
|---|---|
| Engagement | Scoped build with milestones |
| Duration | Quoted after scoping; typically 8–16 weeks |
| Starting price | $12,500 |
| Typical range | $12,500 – $38,500 |
| Deliverables | 5 listed below |
| Delivered from | Bengaluru, India (IST, UK and US East hours) |
| Code ownership | Client owns code, infrastructure, prompts and documentation |
What problem does it solve?
Every business question queues behind the data team. Dashboards answer yesterday's questions. Off-the-shelf text-to-SQL hallucinates joins and leaks data.
How do we approach it?
We never let a model write SQL against a raw schema. The first weeks build a semantic layer: business definitions of metrics, canonical joins, named time periods and the vocabulary your teams actually use. Natural-language questions are mapped onto that layer, the generated query is validated for safety and cost, and it runs read-only under the requesting user's role with row- and column-level security. A golden set of one to three hundred real questions with verified answers is the measure; accuracy is reported against it by question type. Answers come back with the SQL visible, so trust is earned, not requested.
What do clients use it for?
- Ad-hoc questions in Slack or Teams for sales and ops
- Embedded analyst inside your SaaS
- Self-serve reporting for leadership
- Reducing the data team's request queue
Is it the right fit?
Good fit when
- Companies with a warehouse or well-structured databases
- Products with customer-facing analytics
- Teams with a defined set of business metrics
Probably not when
- Undocumented schemas with no metric definitions
- Write or transactional operations
What do we build?
- Semantic layer over your schema: metrics, dimensions, business definitions
- Natural-language to SQL with validation, cost guards and read-only execution
- Row- and column-level security tied to the user's role
- Charts, tables and narrative summaries in the answer
- Embedded in Slack, Teams, your product, or a standalone analyst app
- Query evals against a golden set with a feedback loop
What you get
- Semantic model
- NL query service
- UI and integrations
- Eval set
- Governance rules
How does the engagement work?
- 01
Schema and metric audit
- 02
Semantic layer
- 03
Golden question set
- 04
Build
- 05
Eval to threshold
- 06
Rollout by team
What does good look like?
Sales, operations and leadership asking questions in Slack or in your product and getting correct, governed answers with a chart in seconds. Accuracy on the golden set reported by category. The data team's queue of ad-hoc requests shrinking to the questions that need a person. And a system that shows its work, so a wrong answer is caught rather than trusted.
How does it compare?
| Eazyware | Typical agency | In-house hire | |
|---|---|---|---|
| Time to first result | Sprint Zero in 10 days, then a fixed-scope build | 6–12 weeks of discovery before a proposal | 3–6 months to hire, then ramp |
| Pricing model | Fixed scope, milestone billing, INR or USD | Time and materials, open-ended | Salaries, tooling, management overhead |
| AI depth | Multi-model, evals, cost routing, observability as standard | Often a single vendor API and a prompt | Depends entirely on who you can hire |
| Ownership | Client owns code, infra, prompts and docs | Sometimes retained or licensed back | Owned, but concentrated in one or two people |
| After launch | Care Plans with SLA and AI add-on | Change requests at hourly rates | Ongoing headcount whether or not there is work |
Which pitfalls do we design around?
Text-to-SQL fails when it hallucinates joins, when it runs with write access, when it leaks rows a user should not see, and when the accuracy number comes from a vendor's question set rather than yours. The semantic layer, read-only execution, role-based security and your golden set are the four answers.
What do we measure?
Every engagement is instrumented. These are the numbers you see in the dashboard and the monthly report, not claims on a website.
- Accuracy on the golden question set
- Queries answered without an analyst
- Time to answer
- Security policy violations (target: zero)
Which technologies do we use?
- Postgres / MySQL / BigQuery / Snowflake / MongoDB
- dbt or custom semantic layer
- OpenAI / Anthropic
- Node.js / Python
Who does the work?
A data engineer who builds the semantic layer with your analysts, an AI engineer for the query generation and evals, and an integration engineer for Slack, Teams or your product.
What do you need to bring?
Read access to the database or warehouse, the analysts who know the metric definitions, a list of one to three hundred real questions your teams ask, and a view on the roles and row-level restrictions the answers must respect.
Frequently asked questions
Can it write to the database?
No. Read-only by default, always.
What about wrong answers?
Semantic layer plus validation plus evals. The system shows the SQL and cites tables.
MongoDB?
Yes. Natural language to aggregation pipelines.
Where does this fit?
Natural Language Data Querying is part of our AI-Powered Product Engineering line. Not sure yet? Start with Sprint Zero, a ten-day discovery whose fee is credited to this build. See all pricing or talk to an engineer.