Convert PostgreSQL to SQL Server
A free online converter that translates PostgreSQL queries into SQL Server. Paste your SQL, press Translate, and Query Studio rewrites the syntax that differs between the two databases — instantly, with no login and nothing stored.
Mostly a mechanical rewrite. Identifiers, row limiting and RETURNING/OUTPUT are the three things that change on nearly every query; the type system maps closely enough that the schema is rarely the hard part.
PostgreSQL → SQL Server example
Here is a real PostgreSQL query and the SQL Server output Query Studio produces:
SELECT u.id, u.name, COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at > '2024-01-01' AND u.active = TRUE
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 3
ORDER BY orders DESC
LIMIT 10;SELECT
TOP 10 u.id,
u.name,
COUNT(o.id) AS orders
FROM
users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE
u.created_at > '2024-01-01'
AND u.active = TRUE
GROUP BY
u.id,
u.name
HAVING
COUNT(o.id) > 3
ORDER BY
orders DESC;What changes from PostgreSQL to SQL Server
- Identifier quoting is rewritten from double-quoted "identifiers" to bracketed [identifiers].
- Row limiting is converted from PostgreSQL's LIMIT n to SQL Server's TOP n, including any OFFSET for pagination.
- Null-handling functions such as COALESCE() are mapped to ISNULL().
- Current-timestamp functions like NOW() / CURRENT_TIMESTAMP become GETDATE().
- The result is re-indented and keyword-cased in SQL Server style so it's ready to paste and run.
PostgreSQL to SQL Server data type mapping
Query Studio translates queries, not schemas. When you come to move the tables themselves, this is what changes between PostgreSQL and SQL Server:
| PostgreSQL | SQL Server | Watch out for |
|---|---|---|
| SERIAL | INT IDENTITY(1,1) | Direct equivalent. |
| TEXT | NVARCHAR(MAX) | Direct equivalent. |
| BOOLEAN | BIT | Direct equivalent. |
| TIMESTAMPTZ | DATETIMEOFFSET | Direct equivalent. |
| UUID | UNIQUEIDENTIFIER | Direct equivalent. |
| BYTEA | VARBINARY(MAX) | Direct equivalent. |
| JSONB | NVARCHAR(MAX) + JSON_VALUE/OPENJSON | SQL Server has JSON functions but no JSON storage type. |
| TEXT[] | No equivalent | Arrays need a join table or a JSON column. |
| LIMIT n | TOP n or OFFSET … FETCH | TOP cannot be combined with OFFSET; paginated queries need the OFFSET/FETCH form, which requires an ORDER BY. |
PostgreSQL to SQL Server: what actually catches people out
Syntax is the part a translator can fix. These are the differences that survive a clean conversion and show up later as wrong results rather than as errors.
Every paginated query now needs an ORDER BY
SQL Server's OFFSET … FETCH is only valid after an ORDER BY. A PostgreSQL query using LIMIT/OFFSET without one is legal but non-deterministic, and translating it produces T-SQL that will not compile — which is arguably the database catching a bug for you.
String concatenation with NULL behaves differently
In PostgreSQL, 'a' || NULL is NULL. In SQL Server, 'a' + NULL is NULL too by default — but CONCAT() treats NULL as an empty string in both. If the original relied on || propagating NULL, using CONCAT() in the target silently changes the result.
RETURNING becomes OUTPUT, with different placement
PostgreSQL's RETURNING clause goes at the end. SQL Server's OUTPUT goes between the statement and the VALUES/FROM, and refers to the pseudo-tables `inserted` and `deleted`.
INSERT INTO t (n) VALUES (1) RETURNING id;INSERT INTO t (n) OUTPUT inserted.id VALUES (1);Identifier case folding runs the other way
PostgreSQL lowercases unquoted identifiers, so a schema migrated from it is all lowercase. SQL Server preserves whatever case it is given and compares case-insensitively under the usual collation, so this direction is the forgiving one — but a case-sensitive collation on the target will bite.
What this converter will not do
Query Studio translates SQL syntax. Being honest about the boundary is more useful than claiming there isn’t one — and on PostgreSQL → SQL Server specifically, these are the three that matter most:
Stored procedures, functions and triggers
Procedural code — PL/pgSQL, T-SQL procedures, MySQL routines — is a different language in every engine, with different control flow, error handling, variable declaration and transaction semantics. Query Studio translates queries, not programs. These have to be ported by hand.
Anything that depends on data rather than syntax
Whether a value fits the target type, whether a date is real, whether a text column's contents are valid UTF-8 — none of that is visible in the query. A translation can be syntactically perfect and still fail on the first row of the import.
Vendor-specific extensions
PostGIS geometry, MySQL spatial functions, SQL Server's FOR XML and hierarchyid, BigQuery's nested/repeated model, Snowflake's time travel. Where there is no equivalent concept, there is no translation — only a redesign.
The full list of what a syntax translator cannot do is on the Query Studio page.
How to convert PostgreSQL to SQL Server
- Open the Query Studio editor and choose PostgreSQL as the “From” dialect.
- Choose SQL Server as the “To” dialect.
- Paste your PostgreSQL query and press Translate — copy the SQL Server result.
Try it with your own query
The editor is preloaded with PostgreSQL → SQL Server. You can also explain, format, validate and analyze the result.
Convert PostgreSQL to SQL Server now →Working with the data rather than the schema? Open a large CSV, JSON or Parquet file and query it with SQL — no upload, no row limit, and files far past what Excel will open.
PostgreSQL to SQL Server FAQ
Is this PostgreSQL to SQL Server converter free?
Yes — it's completely free with no account, no sign-up and no usage limits. Your query is processed to return the result and never stored.
Is the PostgreSQL to SQL Server conversion accurate?
Query Studio rewrites syntax deterministically using real SQL parsers, so it gives the same result every time — there is no AI involved and no variation between runs. It handles the differences listed above automatically. What it cannot do is anything semantic: stored procedures, triggers, vendor extensions and performance characteristics all need a human. Review complex, vendor-specific queries before running them in production.
What breaks when migrating from PostgreSQL to SQL Server?
The differences that most often cause problems on this pair: Every paginated query now needs an ORDER BY; String concatenation with NULL behaves differently; RETURNING becomes OUTPUT, with different placement; Identifier case folding runs the other way. Each is explained in full above, with before-and-after examples where seeing it is quicker than reading about it.
How do PostgreSQL data types map to SQL Server?
The full mapping table is above and covers 9 types. The ones that are not a straight rename: JSONB → NVARCHAR(MAX) + JSON_VALUE/OPENJSON, TEXT[] → No equivalent, LIMIT n → TOP n or OFFSET … FETCH. Note that Query Studio translates queries rather than schemas — the table is there to tell you what your CREATE TABLE statements need, not to rewrite them for you.
Does this PostgreSQL to SQL Server converter use AI?
No. Every result is computed by real SQL parsers and rule engines, which is what makes it free, instant, unlimited and identical on every run. Nothing is sent to a model, so there are no rate limits, no per-request cost to pass on, and no possibility of a confidently wrong answer that looks plausible.
Can I convert SQL Server back to PostgreSQL?
Yes. Use the SQL Server to PostgreSQL converter, or press the Swap (⇄) button inside the editor to flip the direction instantly. Note that a round trip is not guaranteed to return your original text — both directions normalise formatting, and where one dialect has no equivalent for a feature the information is genuinely lost rather than recoverable.