SQL development and data modeling
Query performance, data modeling, schema design, and untangling legacy SQL so reports agree with each other and dashboards stop timing out.
SQL development means writing, fixing, and modeling the queries your reporting and applications depend on, so the numbers are consistent and the queries finish. It covers schema design, performance work, and the unglamorous job of untangling queries that grew by accretion over several years. It is for teams whose reports disagree with each other, or whose dashboards have started timing out.
The problem
SQL problems present as business problems. Nobody files a ticket about a missing index. They say the report is wrong, or slow, or that finance and sales cannot agree on a revenue number.
- Two dashboards show different totals because each analyst joined the tables differently.
- A query that ran in four seconds last year now takes six minutes and nobody changed it.
- The definition of an active customer lives in nine separate queries, slightly differently in each.
- A report broke and the only person who understood the query has left.
- Nested subqueries several levels deep that nobody is willing to touch.
What we build
Modeled tables and views
The entities your business actually talks about, defined once, so a metric means the same thing in every report that uses it.
Written business definitions
What counts as an active customer, a closed deal, or recognized revenue, agreed with the people who own those numbers and documented next to the model.
Performance work
Reading the query plan rather than guessing: indexes where they help, rewritten joins, and materialization where a query is genuinely expensive to recompute.
Schema design
Tables, keys, and constraints that make invalid data hard to insert, for the operational databases behind internal tools and applications.
Legacy query cleanup
Breaking apart the queries that grew over years into readable, tested pieces, with the behavior verified against the original output before anything is switched over.
Data tests
Uniqueness, not-null, referential, and freshness checks that catch a broken upstream load before it reaches a dashboard.
What you get at handoff
- Models and migrations in your repository, under version control.
- A data dictionary covering the tables people query, in plain language.
- Before-and-after query plans for the performance work, so the change is verifiable.
- Tests that run in your pipeline, not on our machine.
- Notes on the tradeoffs taken and what we would revisit at higher volume.
Stack
Databases
Postgres, Snowflake, BigQuery, Redshift, MySQL
Modeling
dbt, Views and materialized views, Incremental models
Testing
dbt tests, Row-count and reconciliation checks
Performance
Query plans, Indexing, Partitioning, Clustering
Delivery
Migrations, CI checks, Version control
Related services
FAQ
Our reports disagree with each other. Where do we start?
With the definitions, not the SQL. Most disagreements turn out to be two teams meaning different things by the same word, and no amount of query rewriting fixes that. Once the definition is agreed and written down, the modeling work is usually straightforward.
Can you make our slow queries faster without a rewrite?
Often yes. A lot of slow queries are missing an index, scanning more partitions than they need, or joining in an order the planner handles badly. We read the plan first and only rewrite when the plan says the query shape is the problem.
Do we need dbt for this?
Not always. dbt is excellent for warehouse modeling and gives you tests and documentation cheaply, but if you have a handful of views on Postgres behind an application, plain SQL with migrations is simpler and easier for your team to own.
How do you avoid breaking reports while cleaning up old queries?
By running old and new side by side and comparing output on real data before switching anything over. If the numbers change, that is a finding to discuss, not something to quietly ship. Sometimes the old query was wrong, and someone needs to decide what to do about the historical reports.
Is this worth doing before an AI project?
Usually it is the thing that makes the AI project possible. A model answering questions over inconsistent data produces confident, wrong answers, which is worse than no answer. Clean definitions and trustworthy tables are the prerequisite.
Ready to scope SQL Development?
Send the workflow, tool stack, or reporting problem. We will tell you what should be automated, what should stay manual, and what is worth building first.