How to Format SQL in DBeaver

1. Format SQL in DBeaver with Ctrl+Shift+F

DBeaver bundles its own SQL formatter. Since version 6 it replaced the old Eclipse-based formatter, and it now understands SQL dialects well enough to keep CTEs, window functions and dialect-specific syntax intact.

The default shortcut is Ctrl+Shift+F (Windows/Linux) or Cmd+Shift+F (macOS). There are three ways to trigger it:

• Keyboard — press Ctrl+Shift+F with the SQL editor focused. With no selection, the whole script is formatted. With text selected, only that block is formatted.
• Menu — SQL Editor > Format > Format SQL.
• Context menu — right-click inside the editor and choose Format > Format SQL.

Here is a query that was pasted in from a log file. Everything is on one line, keywords are lowercase, and there is no spacing around operators:

select u.id,u.email,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.created_at>='2026-01-01' and u.status='active' group by u.id,u.email having count(o.id)>3 order by orders desc;

After pressing Ctrl+Shift+F with a default profile (keywords upper, 4-space indent), DBeaver reflows it into something a human can read and diff:

SELECT
    u.id,
    u.email,
    COUNT(o.id) AS orders
FROM
    users u
    LEFT JOIN orders o ON o.user_id = u.id
WHERE
    u.created_at >= '2026-01-01'
    AND u.status = 'active'
GROUP BY
    u.id,
    u.email
HAVING
    COUNT(o.id) > 3
ORDER BY
    orders DESC;

Every change the formatter makes is a normal editor edit, so Ctrl+Z undoes it in one step. If a profile reformats a file in a way you dislike, back out and edit the profile instead of the SQL.

Tip: Formatting only the selection is the safe default while you are dialing in a profile. That way an imperfect rule set cannot rewrite a 2,000-line migration script faster than you can undo it.

2. Configure the Formatter: Profiles, Indentation, Keyword Case

The formatter is configured under Window > Preferences > Editors > SQL Editor > Formatting (on macOS the same page lives under DBeaver > Settings > Editors > SQL Editor > Formatting). In older builds the page is labelled Code Formatting; the options are the same.

Formatting profiles

At the top of the page there is a formatting profile selector. DBeaver ships a small set of presets you can switch between, and you can derive your own:

1. Open the Formatting page and pick the preset closest to your target style.
2. Tune the options below it (indentation, keyword case, line breaks, alignment).
3. Use the profile controls to save the tweaked set under a new name, e.g. team-postgres.
4. Press Apply and Close, then re-format a script to confirm the result.

Indentation and whitespace

• Tab size / indent size — the width of one level. Two spaces is common for PostgreSQL and MySQL shops, four for enterprise T-SQL.
• Use tab characters vs spaces — pick spaces unless your repo already standardises on tabs. Mixed tab/space output is the number-one cause of "it looks wrong in Git".
• Trim trailing whitespace and max line length — the line-length limit is what makes the formatter wrap long boolean expressions instead of leaving 300-character lines.

Keyword and identifier case

The formatter can change the case of keywords, data types, functions and identifiers independently. Each has Upper, Lower and Keep as is options:

• Keywords: Upper — the most common choice; select becomes SELECT.
• Functions: Keep as is — avoids breaking case-sensitive identifiers and quoted names.
• Identifiers: Keep as is — critical if your schema uses camelCase or quoted identifiers that PostgreSQL and Oracle treat as case-sensitive.

A conservative starting point: keywords upper, everything else keep-as-is.

Line breaks, commas and alignment

These options decide how clauses are split and how lists are laid out:

• Line break before/after major clauses (FROM, WHERE, GROUP BY, AND/OR). Enabling breaks before AND/OR turns an unreadable boolean wall into an indented list.
• Comma position — leading (comma-first) or trailing (comma-last). Pick one and enforce it; mixing the two is what makes diffs noisy.
• Alignment — align column definitions, assignments or aliases into columns. This is the option that produces the cleanest output and also the one that interacts badly with CJK text (see section 6).

Apply a profile, then format a representative query to see the result. A dialect with heavy boilerplate — say PL/SQL with nested blocks — is the best template to test on, because it exposes bad indentation rules immediately.

3. Export & Import Formatting Profiles for Your Team

A DBeaver formatting profile is not a standalone file you can commit — it lives inside the workspace preferences. That said, there are two practical ways to get identical formatting across a team.

Option A: Eclipse preference export (.epf)

DBeaver is built on the Eclipse platform, so it inherits Eclipse's preference export:

1. File > Export > General > Preferences.
2. In the export dialog, restrict the exported preferences to the SQL editor keys (a filter keyword such as dbeaver narrows it down) so you do not ship unrelated UI settings.
3. Choose a destination and finish. You get an .epf file.
4. Commit that .epf to your repo, or attach it to your onboarding notes.

Teammates import it with File > Import > General > Preferences, select the file, and restart DBeaver. Their formatter now behaves exactly like yours.

Option B: copy the workspace preference file

For scripted or headless setup, the profile lives in a plain text preference file inside the DBeaver workspace. The locations to know:

# Linux
~/.local/share/DBeaverData/workspace6/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.jkiss.dbeaver.ui.editors.sql.prefs

# Windows
%APPDATA%\DBeaverData\workspace6\.metadata\.plugins\org.eclipse.core.runtime\.settings\org.jkiss.dbeaver.ui.editors.sql.prefs

# macOS
~/Library/DBeaverData/workspace6/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.jkiss.dbeaver.ui.editors.sql.prefs

Copy that file into a new install before DBeaver first starts, and the formatter settings — along with the rest of the SQL editor preferences — are already in place. This is the approach to use when you provision developer machines from a script rather than asking each person to click through the import dialog.

Note: this file carries other SQL editor settings too, so treat it as "editor config". To share only the formatting rules, use the .epf export in Option A.

4. DBeaver + External Toolchain: Format on Save

DBeaver has no native "format on save" checkbox. If you want SQL formatted automatically rather than by pressing a shortcut, you have two routes: let DBeaver call an external formatter, or format outside DBeaver with a hook.

Route 1: the built-in external formatter hook

On the Formatting preference page, the formatter selector can be switched from DBeaver to External formatter. You then supply the command line for a tool that reads SQL from standard input and writes the formatted result to standard output. Any CLI formatter works — for example the popular Node sql-formatter:

sql-formatter --language postgresql

Or pg_format for PostgreSQL, or sqlfluff format --dialect postgres. The advantage is that the same binary can run in your editor, in a pre-commit hook and in CI, so the output is byte-for-byte identical everywhere.

Route 2: format-on-commit with a hook

The more robust pattern is to leave DBeaver's own formatter on for interactive work and enforce the canonical style at commit time. A pre-commit hook using SQLFluff does exactly that — DBeaver reloads the modified file from disk, so the SQL you committed is the SQL you see:

# .pre-commit-config.yaml
- repo: https://github.com/sqlfluff/sqlfluff
  rev: 3.0.0
  hooks:
    - id: sqlfluff-fix
      args: ["--dialect", "postgres"]

SQLFluff is deliberately stricter than DBeaver's formatter: it is rule-based, dialect-aware and configurable through a .sqlfluff file that you commit alongside the SQL. That makes it the natural way to keep a large repository consistent when several people format on different machines, or with different DBeaver profiles.

5. DBeaver vs DataGrip vs SSMS vs VS Code

The four tools people most often compare for SQL formatting behave quite differently. The table below is the honest summary — DBeaver is the only free option with a genuinely configurable built-in formatter and a documented external-formatter hook.

Short version: DBeaver for a free, capable formatter inside a database client; DataGrip if you already pay for JetBrains tools; SSMS only if a basic reformat is enough. For format-on-save in an editor, see our VS Code SQL formatter guide and formatting SQL in SSMS.

6. Common DBeaver Formatting Problems and Fixes

Chinese (CJK) characters and comments shift position

This is the most common complaint from developers who write SQL with Chinese comments or string literals. DBeaver's formatter measures a line in characters, not in display columns, and a full-width CJK character occupies roughly two monospace cells. When alignment is enabled, the formatter pads a comment or a column based on character count, so the visible result is a ragged edge — comments jump left or right, and aligned AS aliases no longer line up.

What actually helps, in order of effort:

• Turn off the alignment options on the Formatting page. Without alignment the formatter never pads, so nothing can drift.
• Keep line comments on their own line. A trailing -- 注释 on a long expression is the case that moves most often; moving it above the statement removes the problem.
• Format a selection, not the whole file, when the script is mostly comments.
• Use an external formatter. SQLFluff and most CLI formatters compute width from Unicode east-asian width properties, so CJK text stays aligned where DBeaver's does not.

The editor freezes on large files

Formatting a multi-thousand-statement dump — the kind of file you get from a full pg_dump — can hang the DBeaver UI for tens of seconds or exhaust the heap entirely. The formatter parses the whole script before it emits output, and on a huge file that is simply a lot of work.

• Raise the heap. Add -Xmx2g (or more) to the VM arguments in dbeaver.ini. The default allocation is modest and is the usual cause of an OutOfMemoryError during formatting.
• Format in chunks. Select the statement you are working on rather than running the shortcut on the entire script.
• Do not keep the whole dump open. Split a generated dump into individual files and format just the parts you need to read.
• Fall back to a CLI or online tool for the truly huge ones — for example our guide on formatting large SQL files online covers the chunked approach that avoids loading everything into one editor at once.

Quoted identifiers get re-cased

If your schema uses quoted mixed-case identifiers ("UserAccount") and the formatter rewrites them to "useraccount", the query silently stops matching the table. Set Identifiers and Functions to Keep as is in the profile. Keyword casing is safe; identifier casing is not.

The formatted result is not what you wanted

Press Ctrl+Z immediately — the format is a single editor operation and undoes cleanly. Then change the profile rather than hand-fixing the SQL, because the next format will undo your hand edits anyway.

7. FAQ — DBeaver SQL Formatter