← Selected work

Datumara

An open-source analytics language model: business questions in, schema-aware SQL and decision-ready answers out — running where the data actually lives.

Stack: Python · Qwen2.5 fine-tuning (LoRA) · Spider dataset · Ollama Status: v0.1-alpha proof of concept, public Links: github.com/achagani/datumara · achagani.github.io/datumara

Brand image from the project's landing page — achagani.github.io/datumara.

01The problem

Every company has the same bottleneck: the distance between a business question and its answer is an analyst's backlog. Generic text-to-SQL tools don't fix it — they guess at schemas they don't know and produce queries that look right and are subtly wrong. And frontier cloud models can't help where it matters most, because the schema and the data can't leave the building. What's missing is a small model, trained on the pairing that actually matters — question ↔ schema ↔ query — that runs locally, next to the warehouse.

02The approach

Datumara fine-tunes a 3.5B-parameter base model (Qwen2.5) on the Spider text-to-SQL corpus, augmented to roughly 7,000 examples, with a split of 60/20/20 for train/validation/test. A complexity classifier routes queries by difficulty so training focuses capacity where errors cluster, and a hard-example mining loop feeds the model's own failures back into the next round. LoRA adapters keep training cheap enough to iterate on a single GPU. The finished model exports straight to Ollama: ollama pull datumara-local and one command gets you from install to answering questions against your own schema.

03Trade-offs

Small on purpose — a 3.5B model that knows your schema beats a frontier model guessing at it, and it fits on hardware where the data is allowed to be processed. The bet is that training data quality, not parameter count, is the lever.

Honest alpha — v0.1 is labeled proof-of-concept everywhere it appears: the README states the model may produce incomplete SQL, and VERSIONING.md defines the quality targets for the v1.0 roadmap. A demo that oversells would poison the very trust the product is about.

Answer, not just query — generating SQL is half the job. The other half is executing it and citing the tables, joins, and date windows used, so a human can verify the answer instead of re-deriving it. Plausible SQL that nobody checks is how bad decisions get made with a dashboard's blessing.

04Under the hood

The training pipeline is a set of composable scripts: train.py with YAML config presets for model sizes (3.5B/7B/13B), hyperparameters, and LoRA settings; evaluate.py and benchmark_baseline.py for measuring against the un-fine-tuned baseline; compare_models.py for side-by-side runs; and poc_verification.py as the end-to-end gate. Docker images with GPU support make the whole thing reproducible on a fresh machine. It's early — but the skeleton of a serious analytics model product is there, and it runs entirely on your side of the firewall.