Local AI by Editorial Team

Best Local LLM for SQL Query Generation

Self-hosted models that turn plain-English questions into SQL for PostgreSQL, MySQL, SQLite, and DuckDB, with BIRD-SQL results, licences, and RAM needs.

The natural-language-to-SQL problem is one of the oldest and most measurable jobs for an LLM. You have a database, you have a schema, you have a question in English, and you want a query that returns the right rows without leaking the schema to a third party. Local models handle that loop end-to-end. The question is which open-weight model actually writes correct SQL on the dialect you use, and how much RAM it costs you. This guide walks through the SQL-specialised models that ship on Ollama, the general code LLMs that post strong open-weight results on the BIRD-SQL leaderboard, and how to pick by hardware tier.

TL;DR

  • The benchmark that separates the field is BIRD-SQL, not Spider. The BIRD-SQL site describes a cross-domain dataset of over 12,751 unique question-SQL pairs and 95 big databases with a total size of 33.4 GB, across more than 37 professional domains such as blockchain, hockey, healthcare, and education. Its primary metric is Execution Accuracy (EX), judged by running the generated SQL against the actual database, and it is described as the first text-to-SQL benchmark designed to encourage semantic parsers to produce SQL queries that are not only correct but also efficient. Human performance is reported at 92.96 Test EX.
  • For dedicated text-to-SQL on a laptop, the sqlcoder family is the easy pull. The Ollama page describes SQLCoder as a code completion model fine-tuned on StarCoder for SQL generation tasks and lists sqlcoder:7b at 4.1 GB / 32K context plus sqlcoder:15b at 9.0 GB / 8K context. The defog/sqlcoder repo reports, on Defog’s own sql-eval framework (vendor-reported), that the SQLCoder family outperforms gpt-4 and gpt-4-turbo; the Ollama page does not say which 7B checkpoint its tag packages. Code is Apache-2.0, weights are CC BY-SA 4.0.
  • For DuckDB-style analytics SQL, duckdb-nsql is the niche pick. The Ollama page documents a 7B / 3.8 GB model “further pre-trained on a dataset of general SQL queries and then fine-tuned on a dataset composed of DuckDB text-to-SQL pairs.” Training data: “200k DuckDB text-to-SQL pairs, synthetically generated using Mixtral-8x7B-Instruct-v0.1, guided by the DuckDB v0.9.2 documentation. And text-to-SQL pairs from NSText2SQL that were transpiled to DuckDB SQL using sqlglot.” 16K context.
  • For broader code-with-SQL on consumer hardware, the Qwen2.5-Coder family is the base of several strong open-weight BIRD-SQL entries. The Qwen2.5-Coder blog ships six sizes (0.5B, 1.5B, 3B, 7B, 14B, 32B) with Apache-2.0 across the lineup except the 3B (Qwen Research license). The BIRD-SQL leaderboard reports CSC-SQL + Qwen2.5-Coder-7B-Instruct at 71.72 Test EX (Dev 69.19) and SLM-SQL + Qwen2.5-Coder-1.5B-Instruct at 70.49 Test EX. Both are research pipelines that fine-tune the model, not stock checkpoints.
  • For a multi-GPU server, DeepSeek-Coder-V2-Instruct at 236B total / 21B active parameters with 128K context is the largest open-weight option here, not the most accurate. The BIRD-SQL leaderboard reports DeepSeek-V2.5 (a related model, not Coder-V2) via the MSL-SQL pipeline at 64.00 Test EX, below the 7B Qwen2.5-Coder entry above; the model card describes performance “comparable to GPT4-Turbo in code-specific tasks” (vendor-reported) and support for 338 programming languages.
  • Local is the privacy choice for production schemas. Sending schema and row samples to a hosted chat vendor discloses table names, column names, and sometimes row values. Running a local model through Ollama on 127.0.0.1:11434 keeps the schema and the generated query on the same machine.

What “SQL generation” actually requires

Three capabilities separate a model that writes a query that runs from one that writes plausible-looking prose.

  1. Schema adherence. The model must read the table and column names you give it, not invent columns. The BIRD-SQL paper makes the point that “due to the nature of the real-world scenarios from which BIRD’s database values were collected, they typically retain their original and frequently ‘dirty’ format,” which is exactly the case where invented columns break. The model must also know the dialect: MySQL has no aggregate FILTER clause or generate_series, and stock SQLite has no regexp_replace.
  2. Execution accuracy. The benchmark primary metric, per BIRD-SQL, is Execution Accuracy - the generated query is run against the database and compared to the gold query’s result set. Exact-match is not the bar. A query that is semantically equivalent to the gold but uses a different join order still scores.
  3. Hallucination discipline. A model that confabulates a table name will return “relation does not exist” at runtime. The duckdb-nsql page is explicit that the model “was designed for text-to-SQL generation tasks from given table schema and natural language prompts” and that it “works best with the prompt format defined below”; the point of passing the schema is that if it lists users(id, created_at) and the question asks for signups by month, the model has users.created_at to work with instead of guessing at users.signup_date. Validating the output against the database is still the only proof.

The SQL-specialised models on Ollama

Two SQL-specific models on the Ollama library are covered here: sqlcoder and duckdb-nsql. They take opposite routes from each other.

sqlcoder (Apache-2.0 code, CC BY-SA 4.0 weights)

The Ollama sqlcoder page describes SQLCoder as a code completion model fine-tuned on StarCoder for SQL generation tasks and notes that the 15B variant “generally requires at least 16GB of RAM.” Available tags:

TagSizeContext
sqlcoder:7b4.1 GB (Q4_0, 4,108,916,352 bytes)32K
sqlcoder:15b9.0 GB8K

The defog/sqlcoder repo says the models were trained on “more than 20,000 human-curated questions” based on “10 different schemas,” and that none of those schemas appear in its sql-eval framework; the headline chart is labelled as covering “novel schemas not seen in training (n = 200), with 4 beams.” Its per-category table (vendor-reported, an excerpt below) shows sqlcoder-7b-2 ahead of gpt-4 on date, ratio, and join questions but behind it on group_by, order_by, and where:

Modeldategroup_byorder_byratiojoinwhere
sqlcoder-70b9691.497.185.797.191.4
sqlcoder-7b-29691.494.391.494.377.1
gpt-47294.397.18091.480
gpt-4-turbo7691.491.462.888.677.1
sqlcoder-7b6482.974.354.374.374.3

The README adds that “if you modify the weights (for example, by fine-tuning), you must open-source your modified weights under the same license terms” under CC BY-SA 4.0. In practice this means sqlcoder is a fine fit for personal use and internal tooling, and a poor fit for a proprietary product that retrains on customer schemas.

The sql-eval framework is the developer’s own; the BIRD-SQL leaderboard does not list sqlcoder. Treat sql-eval numbers as a sanity check, not as cross-grade comparison. The table also names checkpoints (sqlcoder-7b-2, sqlcoder-70b) while the Ollama page does not say which 7B checkpoint sqlcoder:7b packages, so the sqlcoder-7b-2 row may not describe the Ollama tag.

duckdb-nsql (Llama 2 licence, Llama-2 base)

The Ollama duckdb-nsql page documents a 7B / 3.8 GB model with 16K context, “Based on Meta’s original Llama-2 7B model and further pre-trained on a dataset of general SQL queries and then fine-tuned on a dataset composed of DuckDB text-to-SQL pairs.” The full training pipeline:

“200k DuckDB text-to-SQL pairs, synthetically generated using Mixtral-8x7B-Instruct-v0.1, guided by the DuckDB v0.9.2 documentation. And text-to-SQL pairs from NSText2SQL that were transpiled to DuckDB SQL using sqlglot.”

The page also notes that the model “can generate any valid DuckDB SQL statement, including statements for official DuckDB extensions.” That is the practical value: DuckDB-specific features like LIST, STRUCT_PACK, and UNPIVOT are not in PostgreSQL. A general code LLM usually writes PostgreSQL-shaped DuckDB. duckdb-nsql writes DuckDB-shaped DuckDB.

The trade-off: the model is fine-tuned for one dialect. If your warehouse is PostgreSQL or MySQL, sqlcoder or a general code LLM is a better fit.

General code LLMs that lead BIRD-SQL

BIRD-SQL is a widely cited cross-domain text-to-SQL benchmark. The leaderboard reports Execution Accuracy on the dev set and the held-out test set. The entries below are open-weight base models inside published research pipelines.

Qwen2.5-Coder

The Qwen2.5-Coder family blog ships six sizes:

SizeParamsLayersContextLicence
0.5B0.49B2432KApache-2.0
1.5B1.54B2832KApache-2.0
3B3.09B3632KQwen Research
7B7.61B28128KApache-2.0
14B14.7B48128KApache-2.0
32B32.5B64128KApache-2.0

The Qwen2.5-Coder-7B-Instruct card lists 7.61B parameters, 131,072-token context, GQA (28 query heads / 4 KV heads), Apache-2.0, and a code generation, code reasoning, and code fixing focus. The Qwen2.5-Coder-14B-Instruct card is the next step up at 14.7B.

The BIRD-SQL leaderboard lists these Qwen2.5-Coder-based entries:

PipelineModelBIRD Test EXBIRD Dev EX
CSC-SQLQwen2.5-Coder-7B-Instruct71.7269.19
CSC-SQLXiYanSQL-QwenCoder-32B-241273.6771.33
SLM-SQLQwen2.5-Coder-1.5B-Instruct70.4967.08
SLM-SQLQwen2.5-Coder-0.5B-Instruct61.8256.87

The 1.5B variant on SLM-SQL reaches 70.49 Test EX, only 1.23 points below the 7B on CSC-SQL. Neither number is a stock checkpoint: per the SLM-SQL paper, the small model gets supervised fine-tuning and reinforcement-learning post-training followed by corrective self-consistency at inference, and per the CSC-SQL paper, CSC-SQL fine-tunes its generation and revision models with GRPO. A “70.49” next to “Qwen2.5-Coder-1.5B” describes the trained pipeline, not what the stock model pulled from Ollama will do.

The top of the leaderboard is held by systems that list their model size as unknown (GrainSQL at 82.95, DataGallery-Text2SQL at 82.39, SiriusAI-SQL at 82.28 Test EX). The 7B-on-CSC-SQL number is what a fine-tuned 7B open-weight model inside a published pipeline achieves; a stock model with plain prompting should be expected to score lower, and no figure for that setup appears on the leaderboard.

DeepSeek-Coder-V2

The DeepSeek-Coder-V2-Instruct card describes a 236B total / 21B active parameter MoE further pre-trained from DeepSeek-V2 with “additional 6 trillion tokens,” 128K context, support for 338 programming languages (up from 86), and a custom Model License for weights (commercial use allowed; MIT for the code repo). The card claims performance “comparable to GPT4-Turbo in code-specific tasks” (vendor-reported). The BIRD-SQL leaderboard has no Coder-V2 entry; the nearest are MSL-SQL + DeepSeek-V2.5 at 64.00 Test EX and RSL-SQL + DeepSeek-v2 at 65.51, both below the Qwen2.5-Coder-7B entry above. At 236B total parameters it is not a fit for a laptop: the Ollama deepseek-coder-v2:236b tag is a 133 GB download, and Ollama’s default deepseek-coder-v2 tag is the 16B Lite model (8.9 GB), not the 236B.

Spider, the older benchmark

The Spider benchmark is the older cross-domain text-to-SQL dataset that pre-dates BIRD-SQL. Its official metric is Test Suite Accuracy (since 2020-11-15), with Execution Accuracy and Exact Matching as alternatives. Spider’s databases are cleaner than BIRD-SQL’s “dirty” real-world values, which is why the same model usually scores higher on Spider than on BIRD-SQL. If a vendor quotes Spider but not BIRD-SQL, they are quoting the easier benchmark.

Pick by hardware tier

4 to 16 GB RAM, no GPU (or small integrated GPU)

sqlcoder:7b at 4.1 GB and 32K context is the practical default. The 4.1 GB of weights fit in 8 GB of RAM with room for the Ollama daemon and a modest context, and it is fine-tuned for the task. Use duckdb-nsql (3.8 GB, 16K context) when the database is DuckDB.

For JSON-shaped downstream work, note the Ollama API format parameter: pass "format": "json" for free-form JSON, or pass a JSON Schema for constrained output. SQL is the obvious case where a schema makes sense - declare the keys you want ({"query": "string", "explanation": "string"}) and Ollama constrains the output to that shape. Whether the SQL inside is correct is a separate question.

16 to 32 GB RAM with an 8 GB to 12 GB GPU (RTX 3060, M-series shared memory)

qwen2.5-coder:7b at 7.61B parameters (a 4.7 GB download on Ollama) is the broader pick when the queries cross PostgreSQL, MySQL, and SQLite. Its BIRD-SQL Dev 69.19 on CSC-SQL comes from a fine-tuned research pipeline, so treat it as a ceiling, well above what plain prompting of the stock model should be expected to reach. sqlcoder:15b at 9.0 GB is the SQL-specialised alternative; the Ollama page says it “generally requires at least 16GB of RAM.”

24 GB GPU or 64 GB+ unified memory

qwen2.5-coder:14b at 14.7B parameters (a 9.0 GB download on Ollama; the model card lists a full 131,072-token context, while the Ollama tag page lists 32K) fits on a single 24 GB consumer GPU (RTX 4090) or a Mac with enough unified memory. The 14B is the largest pick in this guide that still runs on a laptop-class machine.

For a workstation with multiple GPUs or a server with well over 133 GB of memory (the size of the Ollama Q4 deepseek-coder-v2:236b download, before any context), DeepSeek-Coder-V2 at 236B total / 21B active is the largest open-weight option in this guide, though its relatives score below the Qwen2.5-Coder-7B pipeline on BIRD-SQL.

How to ask the model for SQL that runs

Two prompt patterns separate a working SQL workflow from one that produces plausible-looking garbage.

  1. Pass the schema, not the database. A model that sees CREATE TABLE users (id int, created_at timestamp) and CREATE TABLE orders (user_id int, amount numeric) will emit a query that joins on real columns. A model that does not see the schema will invent columns. The sqlcoder and duckdb-nsql prompt templates assume you pass the schema; if you write your own front-end, do the same.
  2. Constrain the dialect. PostgreSQL, MySQL, DuckDB, and SQLite differ on FILTER, generate_series, LIST, STRUCT_PACK, recursive CTEs, and window-function null handling. Tell the model which dialect the query must run against, and validate the output by running it against the database before trusting it.

A simple harness wraps these: send the question plus the schema to the model, parse the output, run it against the database, and report both the rows and the explain plan. The model wrote a query; the database decided whether the query worked. The BIRD-SQL leaderboard is structured this way - generated SQL is executed against the gold database and the result set is compared.

Privacy: why run locally

The most common reason to run a SQL-generation model locally is that the schema and the row samples are not safe to send to a third party. A table name like users.email and a column like users.password_hash are not secrets on their own, but a one-line prompt that includes five row values and the full CREATE TABLE block is a chunk of confidential data by most regulators’ standards. The same rule applies to anything in health, finance, employment, or internal ops.

The fix is not more clever prompting; the fix is the network path. An Ollama daemon bound to 127.0.0.1:11434 running a local model keeps prompts on the machine. The Ollama FAQ is explicit: “Ollama runs locally. We don’t see your prompts or data when you run locally. When using cloud-hosted models, we process your prompts and responses to provide the service but do not store or log that content and never train on it.” Bind the daemon, set OLLAMA_HOST only if you need to expose it on your LAN, and the schema and the row samples stay on the machine.

What to skip

Three traps are worth calling out.

  1. Spider-only benchmarks. The Spider benchmark runs cleaner numbers than BIRD-SQL because its databases are smaller and cleaner. Compare on BIRD-SQL, not Spider.
  2. Hosted SQL tools with schema upload. A vendor that lets you paste a schema and a question sends the schema to its backend, where retention and training policy decide what happens to it. If the schema is confidential, the local path is the answer.
  3. Models without JSON output. A free-form prose answer is not a SQL query. If your front-end parses the output and runs it against the database, pass a JSON schema via the Ollama format parameter so the model emits a parseable wrapper ({"query": "SELECT ...", "explanation": "..."}).

The bottom line

For SQL generation on a laptop, sqlcoder:7b at 4.1 GB is the default; duckdb-nsql at 3.8 GB is the right choice when the database is DuckDB. For a 7B-class general code LLM that handles PostgreSQL, MySQL, and SQLite in the same workflow, qwen2.5-coder:7b at 7.61B parameters is the broader pick, and the BIRD-SQL Dev 69.19 from the fine-tuned CSC-SQL pipeline is a ceiling, not a stock-model expectation. For a workstation with a 24 GB GPU, qwen2.5-coder:14b at 14.7B parameters is the largest pick that still runs on a laptop-class machine. For a multi-GPU server with well over 133 GB of memory, DeepSeek-Coder-V2 is the largest open-weight option, though not the BIRD-SQL leader. Apache-2.0 across the Qwen2.5-Coder 0.5B/1.5B/7B/14B/32B sizes, CC BY-SA 4.0 on sqlcoder weights, and a custom commercial-OK licence on DeepSeek-Coder-V2 weights. The schema and the row samples are the privacy decision; running locally means the schema never leaves the machine.