For SQL, tabs versus spaces is purely a readability choice — the database engine ignores whitespace entirely, so neither one affects how a query parses, optimizes, or runs. SQL is not whitespace-sensitive the way Python is; the tokenizer strips indentation before execution, so identical queries indented with tabs, spaces, or nothing at all produce the same result at the same speed. That frees the decision to be about humans. In practice spaces win most of the time because they render identically in every editor, diff tool, and web viewer, which is why most published SQL style guides use them. Tabs have one strong counter-argument — accessibility — since they let each developer set their own display width and use far fewer braille cells. The choice that actually matters more than either: pick one, never mix them, and let a formatter or .editorconfig enforce it.
That paragraph is the summary an AI overview would hand you. The rest of this article is the part it can't: a side-by-side decision table you can act on, the specific accessibility math behind the tabs argument, and why the real answer is "stop deciding by hand."
The decision at a glance
Most of the debate evaporates once you separate the two questions people conflate: which character and how it's enforced. The character barely matters; enforcement matters a lot. Here is the honest comparison.
| Consideration | Spaces | Tabs |
|---|---|---|
| Query execution | No effect — engine ignores whitespace | No effect — engine ignores whitespace |
| Cross-tool consistency | Renders identically everywhere (GitHub, Slack, wikis, every SQL client) | Renders as 2 / 4 / 8 columns depending on the tool — alignment can break |
| Accessibility | One braille cell per space; wastes cells on deep indents; width is fixed for everyone | One cell per level on braille displays; each developer sets their own display width |
| Style-guide alignment | Matches most published guides (e.g. Simon Holywell's SQL Style Guide) | Fewer SQL guides default to tabs |
| Manual typing | Needs editor support (or repeated spacebar) | One keystroke = one level in any editor |
| File size | A few extra bytes per indent (negligible) | One byte per level |
| Version-control diffs | Clean if consistent | Clean if consistent; mixing with spaces creates noise |
| Default in | Most web/cloud SQL editors, VS Code (soft tabs) | SSMS, some legacy tooling |
| Best when | Teams, open source, code shared across many tools | Accessibility-first teams; solo work in basic editors |
The one-line verdict: default to spaces (2 or 4) for shared and public SQL because consistency across tools is the common pain point; choose tabs when accessibility is a priority or your whole team already uses them. Either way, enforce it with tooling — that is what removes the friction, not the character you picked.
Why the engine truly doesn't care
The single most important fact in this whole debate is technical, not stylistic: SQL parsers discard insignificant whitespace during tokenization, long before the optimizer builds an execution plan. Below is what actually happens to your indentation.
Because indentation is gone before the optimizer runs, there is no mechanism by which tabs could be faster or slower than spaces. If you ever see a timing difference, it is measurement noise — the same query run twice varies too. This is worth internalizing because it settles the only part of the argument that would have an objective answer: performance is not a tiebreaker.
If you want to prove it to yourself, format the same query both ways and compare the plans — see does SQL formatting change query execution.
The case for spaces: consistency everywhere
Spaces have one decisive property: four spaces are four columns in every tool that exists. Copy space-indented SQL into a GitHub diff, a Confluence page, a Slack message, DBeaver, DataGrip, or a cloud query console, and the alignment survives intact. That reliability is why spaces became the default in collaborative and public settings, and why guides like Simon Holywell's SQL Style Guide indent with spaces.
Tabs, by contrast, render at whatever width each tool chooses — 2, 4, or 8 columns. SQL that lines up perfectly in your editor can look ragged when a colleague opens it somewhere else, especially if anyone has used tabs to align (rather than just indent) columns. When your code travels across many tools and many people, spaces remove a whole class of "it looks broken on my screen" problems.
The case for tabs: accessibility and configurability
The strongest argument on the tabs side is not aesthetics — it is accessibility, and the math is concrete. On a refreshable braille display, each character occupies one braille cell. With four-space indentation, code nested three levels deep consumes twelve braille cells before the first token of actual code — more than a quarter of a common 40-cell display, conveying no information. With tabs, three levels of nesting is three characters, so three cells. For a developer reading code through braille, that difference is significant.
Tabs also let each developer choose their own display width without touching the file. A low-vision developer can set tabs to render at 8 columns for easier reading while a teammate views the same file at 2 columns — the bytes on disk are identical. Spaces can't do this: the width is baked in for everyone. That per-viewer flexibility, plus the braille-cell savings, is why some accessibility-focused teams and projects deliberately default to tabs.
Soft tabs: the common compromise
Most teams that say "we use tabs" are actually using soft tabs — the Tab key inserts spaces. You get the one-keystroke typing convenience while the file stores spaces for cross-tool consistency. It's the default in VS Code, Sublime Text, and most modern editors, and you can enable it in SSMS and Azure Data Studio too.
The honest caveat: soft tabs fix the indent width in the file, so they keep the consistency benefit of spaces but give up the accessibility benefit of real tabs (a braille or low-vision user can no longer reconfigure the width). If accessibility is a live concern for your team, that trade-off matters; if cross-tool consistency is your main pain, soft tabs are an easy win.
The answer that actually matters: enforce it with tooling
Here is the reframe that ends the debate on real teams: stop deciding indentation by hand. The character you pick is a five-minute conversation; the thing that causes ongoing pain is inconsistency, and inconsistency is a tooling problem, not a willpower problem.
- Add an
.editorconfigto the repo. It specifiesindent_style(tab or space) andindent_size, travels with the project, and configures every compliant editor automatically — no per-developer setup. - Run a SQL formatter (SQLFluff, or a sql-formatter tool) so the whole file is reformatted to the standard on save, in a pre-commit hook, or in CI. Reviewers stop commenting on whitespace because there is never any to comment on.
- Do conversions in one commit. When you switch a codebase from tabs to spaces (or vice versa), make it a single, clearly labeled "formatting only" commit so it doesn't pollute the diff of real changes. This also keeps whitespace noise out of your reviews.
Try it on any query below — reformat it consistently in seconds instead of arguing about it:
Once a formatter owns your indentation, the tabs-vs-spaces question becomes academic. The file is consistent no matter who edited it, git diffs stay clean, and the team spends its attention on the SQL logic instead of its whitespace.
Making the call for your context
- Solo / personal projects: use whatever feels natural and be consistent. Configure your editor once and move on.
- Small teams: either works — agree once, put it in
.editorconfig, and enforce with a formatter. Agreement beats the specific choice. - Large orgs / open source: default to spaces unless you have an accessibility-driven reason for tabs; the cross-tool consistency avoids the most common friction with diverse contributors and tools.
- Accessibility-first teams: default to tabs for the braille-cell savings and per-viewer width, and document it so contributors don't "fix" it back to spaces.
- Joining an existing project: follow the established convention, full stop. Consistency with the codebase beats any personal preference, and a formatter makes conforming automatic.
Conclusion
Tabs versus spaces in SQL has no universal winner because the engine gives you total freedom — whitespace never affects how a query runs. Spaces win on cross-tool consistency and match most style guides, which is why they dominate in shared and public code. Tabs win on accessibility, thanks to braille-cell efficiency and per-developer display width. Soft tabs split the difference for teams whose main concern is consistency rather than accessibility. But the decision that saves you the most grief isn't the character — it's committing to one choice and letting an .editorconfig plus a formatter enforce it so nobody has to think about indentation again. Pick one, automate it, and spend your energy on the SQL that actually matters.