DuckDB-NSQL: Natural Language SQL for Analytical Workloads, Deployed Privately

DuckDB has become the default engine for local analytical workloads — fast, embedded, requiring no server, and capable of querying Parquet files, CSVs, and in-memory datasets with full SQL expressiveness. The gap it has not closed on its own is natural language access: data analysts who can describe what they want in plain English still need to translate that description into DuckDB's specific SQL dialect, including its analytical extensions and syntax preferences that differ from standard SQL in meaningful ways.

DuckDB-NSQL fills that gap. A 7B model fine-tuned specifically on DuckDB SQL by Numbers Station, it translates natural language questions into accurate DuckDB-dialect queries against provided schemas. Available via ollama run duckdb-nsql, it runs on CPU-only hardware, requires no GPU, and keeps your data schemas and query history entirely on-premise — no cloud API, no schema transmission, no data governance exposure.

What DuckDB-NSQL Does Well

• DuckDB-specific SQL generation: Fine-tuned on DuckDB's dialect rather than generic SQL — correctly uses DuckDB's analytical functions, syntax patterns, and extensions that general-purpose models frequently misapply
• Analytical query construction: Strong performance on the aggregation-heavy, window-function-rich queries that characterize analytical workloads — GROUP BY, PARTITION OVER, QUALIFY, and DuckDB's PIVOT syntax
• File-based schema awareness: Generates queries against Parquet files, CSV datasets, and in-memory tables when schema context is provided — matches the actual DuckDB use pattern rather than assuming a traditional database server
• Lightweight deployment: At 7B parameters and Q4 quantization, runs on 4–6GB RAM with no GPU requirement — fits on any analyst's laptop or a minimal cloud instance
• Query explanation: Translates existing DuckDB queries into plain language descriptions for documentation, onboarding, and cross-team communication
• Iterative query refinement: Supports follow-up prompts that modify a generated query — "now filter to only rows where X" — maintaining schema context across a multi-turn session

Who This Model Family is For

Personal Use

DuckDB NSQL is a practical tool if you work with local datasets (CSVs, Parquet files, or DuckDB databases) and want to generate queries using plain English instead of memorizing complex SQL syntax. It's especially useful for hobbyists, side projects, or personal data exploration on a laptop. Keep in mind this is a specialized SQL generation model — it does not chat, summarize, or act as a general assistant.

Business / Team Use

Teams that have standardized on DuckDB for local analytics, embedded reporting, or fast in-process querying can use DuckDB NSQL to make data access more accessible across the organization. Analysts and non-technical users can describe what they need and receive valid DuckDB queries, reducing reliance on a single SQL expert. Running it through NoCloudGPT keeps sensitive schemas and data entirely on your own infrastructure — an important advantage for finance, healthcare, and regulated industries.

Developer & Technical Use

Developers building internal data tools, dashboards, or natural-language query interfaces on top of DuckDB will find this model useful as a focused text-to-SQL engine. It is specifically tuned for DuckDB's dialect, which reduces syntax mismatches compared to general-purpose models. Its output should be treated as a first draft — always validate queries before running them against production data.

Data Science & Research Use

Data scientists and researchers using DuckDB for fast local exploration of analytical datasets will appreciate how DuckDB NSQL accelerates exploratory querying and prototyping of aggregations and joins. It handles the analytical patterns DuckDB excels at, allowing you to stay focused on your analysis rather than syntax. It is not a general reasoning or statistical modeling tool — its value is narrowly focused on turning natural language into correct DuckDB SQL.

Licensing Information

DuckDB NSQL was developed by MotherDuck and Numbers Station. Licensing depends on the specific variant and its underlying base model. Most published versions use permissive terms, but you should always confirm the exact license on the official model card before commercial deployment.

Official source:

• DuckDB NSQL on Hugging Face

Disclaimer: NoCloudGPT provides this licensing summary as a convenience reference only. It does not constitute legal advice. License terms can change. Always review the official model card and consult your legal counsel before deploying any model in a commercial or regulated context.

Available Model Sizes

Positioning note: DuckDB NSQL is a specialized SQL generation model optimized for DuckDB. It performs best when generating analytical queries against DuckDB databases and is not intended as a general-purpose chat model or for other database systems without adaptation.

Deployment Requirements

Local Analyst Workstation — 7B Q4 (4–6GB RAM, CPU only)

DuckDB-NSQL is a single-variant deployment — the 7B Q4 model is the standard release and is designed to run on analyst hardware without GPU requirements. On a laptop or workstation with 4–6GB of available RAM, it provides interactive natural language query generation with response times of 5–15 tokens per second on modern CPU hardware. This is fast enough for the iterative exploration pattern typical of analytical work — ask a question, review the generated query, execute it in DuckDB, refine and repeat. Pull with ollama run duckdb-nsql.

Shared Team Instance — 7B Q4 (AWS Lightsail 4GB or CPU instance)

For teams that want a shared natural language query endpoint, DuckDB-NSQL runs comfortably on an AWS Lightsail instance with 4GB RAM — the lowest-cost shared deployment option in this model catalog. Multiple analysts can submit queries to a single Ollama endpoint without requiring dedicated GPU infrastructure. Lightsail 4GB instances run approximately $20–40 USD per month, making this one of the most cost-effective private AI deployments available for analytical teams.

The Real Cost of Analytical Schema Exposure

Analytical datasets frequently contain the most sensitive data an organization holds: revenue figures, customer cohort breakdowns, clinical outcomes, research results, and competitive intelligence. The schemas that organize this data — table names, column names, metric definitions — describe your analytical framework in terms that are meaningful to competitors and regulators alike. Sending this schema context to a cloud API as part of every natural language query creates an exposure surface that most data governance frameworks have not explicitly addressed.

DuckDB-NSQL on-premise means your analytical schemas never leave your local environment. The questions your analysts ask, the dataset structures they query against, and the patterns in their query history stay within your infrastructure boundary. For organizations handling financial data under SOC 2, clinical data under HIPAA, or proprietary research data under internal classification policies, local deployment is the only deployment model that satisfies governance requirements.

Integration and Workflow Compatibility

• DuckDB CLI and Python API — use DuckDB-NSQL to generate queries, then execute them directly against your local DuckDB instance in the same workflow
• Jupyter and notebook environments — embed natural language query generation into data science notebooks via the Ollama Python library
• OpenWebUI — provide a browser interface for non-technical analysts to submit natural language questions against shared DuckDB datasets
• Ollama API — integrate DuckDB-NSQL into internal analytics tools, dashboards, or data portals via the OpenAI-compatible endpoint
• LangChain — chain DuckDB-NSQL with DuckDB's Python connector for fully automated natural language to query execution pipelines

Your analytical data is your most sensitive asset. Deploy DuckDB-NSQL privately and give your team natural language access to local datasets without routing your schema or query context through a cloud API.