SQL Server
PostgreSQL

SQL Server to PostgreSQL Migration Tool

Schema conversion, type mapping, and optional two-way sync between on-prem and cloud Postgres.

Convert a SQL Server or MSSQL database to PostgreSQL with a migration tool that handles schema, data, and type mapping.

DBConvert reads the SQL Server catalog, creates PostgreSQL-compatible tables, maps data types, recreates supported indexes and constraints, and transfers rows into on-prem or managed PostgreSQL targets. The hard parts are identity columns, identifier case, SQL Server data types, and T-SQL code that does not run on PostgreSQL.

What DBConvert does on this path: works as a local MSSQL to PostgreSQL converter and repeatable desktop workflow:

  • Reads SQL Server catalogs from on-prem SQL Server, Express, Azure SQL, or Amazon RDS.
  • Maps data types and recreates supported indexes and constraints.
  • Transfers rows in parallel into PostgreSQL, Amazon RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.

What it does not do: stored procedures, functions, and triggers are not translated. T-SQL rewrites are a separate engineering task.

Which tool: DBConvert or DBSync?

DBConvert for SQL Server → PostgreSQL

The one-time migration. Connect both ends in the wizard, pick tables and columns to transfer, run. Schema + data, parallel transfer, on-prem or cloud target.

DBSync for SQL Server ↔ PostgreSQL

The separate tool when both databases must keep exchanging changes after cut-over — Insert / Update / Delete, one-way or bi-directional, optionally trigger-based.

Both are Windows desktop tools with a GUI wizard, not a scripted CLI. If you also need scheduled or command-line runs across 30+ database engines, see DBConvert Studio.

Need more context? Compare DBConvert and DBSync side by side →

How DBConvert handles the SQL Server → PostgreSQL differences

SQL Server and PostgreSQL differ in identity columns, type mapping, identifier case, index scoping, and server-side code. DBConvert maps most of those differences in the wizard with sensible defaults that you can review or override per table; T-SQL code rewrite is the one item that still needs a human.

  • Identity columns and sequences. Maps SQL Server IDENTITY to PostgreSQL GENERATED ... AS IDENTITY (or SERIAL on older targets) and sets the sequence's next value to MAX(id)+1 after the bulk load — so the next insert does not hit a duplicate-key error. bcp + COPY pipelines need that step scripted manually.
  • Type translations that aren't 1:1. Defaults to DATETIME → TIMESTAMP, MONEY → NUMERIC(19,4), UNIQUEIDENTIFIER → UUID, NVARCHAR(max) → TEXT, BIT → BOOLEAN, VARBINARY(max) → BYTEA, and treats SQL Server's TIMESTAMP as a row-version counter (mapped to BYTEA), not a datetime. Each mapping is overridable per column in the type-mapping review.
  • Identifier case. Normalizes SQL Server mixed-case names (OrderHeader, CustomerID) to lowercase on the PostgreSQL target by default, or preserves quoting as-is — pick the policy in the wizard so PostgreSQL's case-folding does not surface at application boot.
  • Indexes and constraints. Disambiguates SQL Server's per-table index names into schema-unique names on the PostgreSQL side (PostgreSQL requires index names unique within a schema), and handles foreign-key restrictions on partitioned tables that SQL Server allows but PostgreSQL constrains differently.
  • Stored procedures, triggers, and other procedural code — outside DBConvert's scope. DBConvert's migration covers tables (with their fields, types, defaults, and indexes), views, and foreign keys. T-SQL stored procedures, functions, triggers, and table-valued parameters stay in the source and are rewritten manually in PL/pgSQL — T-SQL MERGE, GOTO, and table-valued parameters have no direct PL/pgSQL equivalent. The SQL Server to PostgreSQL migration guide covers the rewrites in depth. Typically a small fraction of the schema, but the one item the tool does not handle.

Why migrate from SQL Server to PostgreSQL?

Licensing cost

SQL Server Enterprise is licensed per core — several thousand USD per core, plus Software Assurance. PostgreSQL is BSD-licensed: no per-core, per-user, or per-database fees on any edition. On a 16-core box, that's the difference between a five-figure annual line item and zero.

No Express ceiling

SQL Server Express is free but capped: 10 GB per database, 1 socket / 4 cores, 1.4 GB buffer pool. PostgreSQL has no edition tiers — the free build is the build everyone runs in production.

Cross-platform parity

PostgreSQL runs natively on Linux, macOS, Windows, and BSD. SQL Server has run on Linux since 2017, so this is no longer a gap by itself — but PostgreSQL on Linux is the default shape for most managed cloud offerings, which is the practical reason teams move.

Open ecosystem

PostgreSQL extensions — PostGIS, TimescaleDB, pgvector, Citus, pgBouncer — are first-party-quality OSS, installable into any deployment. SQL Server's analogous features ship as paid editions or separate products. If your roadmap touches geo, time-series, vector search, or sharding, the cost gap compounds.

When DBConvert is the right fit — and when it isn't

Pick by what you're optimising for. The categories below are the realistic alternatives; we name them honestly so you don't end up with the wrong tool.

DBConvert / DBSync — pick this when

  • You want a visual wizard, not a scripted CLI.
  • You need parallel data transfer and selective tables / columns / rows.
  • You want optional bi-directional sync to keep both databases matched during a staged cut-over.
  • Target is on-prem PostgreSQL or any managed cloud Postgres (RDS / Aurora / Cloud SQL / Azure / Supabase).

A different tool is a better fit when

  • You need zero-downtime CDC into AWS — AWS Schema Conversion Tool + Database Migration Service is the native stack for Amazon RDS / Aurora targets.
  • The project is mostly T-SQL rewrites — a transpiler that converts stored procedures, functions, and triggers into PL/pgSQL is the right primary tool; data transfer is then secondary.
  • You can't rewrite the application at all — a TDS-wire-protocol compatibility layer that lets unmodified SQL Server clients talk to PostgreSQL is what you want; this isn't a migration, it's a translation shim.
  • It's a one-shot bulk load from the command line — tools such as sqlserver2pgsql, scripted dumps, or bcp + PostgreSQL COPY can work if you're comfortable with config files and don't need ongoing sync.

What DBConvert and DBSync actually do

1

Wizard with object selection

Connect source and target through the desktop wizard, choose schemas, tables, columns, and row filters, review the type mapping, then run. The session is saved and can be re-run from the scheduler or the command line.

2

Parallel migration engine

The transfer splits each large table into ranges and copies them concurrently across multi-core CPUs. For tables in the millions-of-rows range, this is the difference between an overnight run and a coffee break.

3

Bi-directional synchronization (DBSync)

When the cut-over has to be staged — the source database stays live while the target catches up — DBSync replays Insert / Update / Delete one-way or bi-directionally, with a trigger-based mode that avoids full-table compares on subsequent runs. Separate desktop product, same connectors. Use it to keep both databases matched during a step-by-step cut-over, not as a CDC replacement.

Supported versions

  • SQL Server 2008–2022, including Express editions
  • Azure SQL Database and Amazon RDS for SQL Server
  • SQL Server schemas (dbo, custom schemas)
  • Windows authentication or SQL authentication
  • PostgreSQL 8.x through 17.x
  • Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL, Supabase
  • PostgreSQL schemas (public, custom schemas)

Supported in this path

Source SQL Server
Target PostgreSQL
Microsoft SQL Server Azure SQL Database Amazon RDS for SQL Server PostgreSQL Amazon RDS / Aurora for PostgreSQL Azure Database for PostgreSQL Google Cloud SQL for PostgreSQL Supabase
SQL Server

All SQL Server Tools

Other directions and pairs
PostgreSQL

All PostgreSQL Tools

Migration & sync options

Reverse Conversion

PostgreSQL to SQL Server

Using SQL Server to PostgreSQL Tools

When launching the DBConvert or DBSync application in GUI mode, it guides you through the steps to start database migration or synchronization:

1

Connect to SQL Server source database

Specify the username/password and host/port parameters if your source database requires login credentials.

Connect to SQL Server source database from DBConvert

SQL Server source

Connect by TCP/IP or Named Pipes, use Azure SQL, or read from Amazon RDS for SQL Server.

2

Connect to PostgreSQL destination database

Specify parameters for the destination database similar to the source, defining connection settings and username/password pairs.

Connect to PostgreSQL target database from DBConvert

PostgreSQL target

Connect to self-hosted PostgreSQL, Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.

More guides for SQL Server ↔ PostgreSQL

Next steps: configure, validate, run

After connecting source and target, the remaining steps are the same for every database pair:

  • Configure migration options — pick tables, fields, indices, views.
  • Issue detection — the built-in checker flags integrity problems before migration starts.
  • Execute — commit the job, monitor progress, save the session for reuse.
  • Schedule and CLI — rerun saved sessions on a schedule or from the command line.
Open the full guide

Steps 3–5, software features, command-line mode, scheduler, and system requirements.

See all features