PostgreSQL
SQL Server

PostgreSQL to SQL Server Migration Tool

Move PostgreSQL data into SQL Server, Azure SQL, or Amazon RDS for SQL Server. Schema conversion, type mapping, and optional two-way sync.

Convert PostgreSQL to SQL Server when the destination application, reporting stack, or operations team is standardized on Microsoft tooling.

DBConvert reads PostgreSQL sources, creates SQL Server-compatible tables, maps data types, copies rows, and recreates supported indexes and foreign keys. There is no Microsoft SSMA path for PostgreSQL to SQL Server, and PL/pgSQL code still needs a separate T-SQL rewrite.

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

  • Reads PostgreSQL sources from on-prem servers, Amazon RDS / Aurora, Azure Database for PostgreSQL, Google Cloud SQL, or Supabase.
  • Creates SQL Server-compatible tables, maps types, copies rows, and recreates supported indexes and foreign keys.
  • Writes to SQL Server, SQL Server Express, Azure SQL, or Amazon RDS for SQL Server.

What it does not do: PostgreSQL functions, triggers, rules, and PL/pgSQL code are not translated into T-SQL. Treat that code as an application / database rewrite task.

Which tool: DBConvert or DBSync?

DBConvert for PostgreSQL → SQL Server

One-time migration. Use it when SQL Server is the destination and you need PostgreSQL schema, table data, indexes, foreign keys, and type mapping moved through a desktop wizard.

DBSync for PostgreSQL ↔ SQL Server

Repeat synchronization. Use it when PostgreSQL and SQL Server must keep exchanging Insert / Update / Delete changes during a staged migration or recurring workflow; see database synchronization concepts for ownership and conflict-handling basics.

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

How DBConvert handles the PostgreSQL → SQL Server differences

DBConvert handles the table-level migration in the wizard: schema selection, naming policy, generated keys, type mapping, indexes, and transfer. PL/pgSQL and application SQL remain separate rewrite tracks.

Schemas and names

PostgreSQL schemas and search_path behavior are mapped into SQL Server schemas, usually with dbo as the target default. Quoted mixed-case identifiers can be normalized or preserved with SQL Server bracket quoting.

Generated keys

serial, bigserial, identity columns, and standalone sequences are moved to SQL Server IDENTITY columns or sequence-backed defaults, with reseeding checked after the bulk load.

Type mapping review

DBConvert proposes SQL Server storage for PostgreSQL scalar, binary, text, date/time, JSON, and less direct types. You review those choices before the target table is created.

Indexes and constraints

Partial and expression indexes can move to filtered indexes or computed-column patterns where the SQL Server semantics match. GiST, GIN, and exclusion constraints are flagged for review.

Procedural code boundary

DBConvert covers tables, fields, defaults, indexes, views, and foreign keys. PL/pgSQL functions, triggers, rules, custom operators, and extension-backed behavior are rewritten manually in T-SQL.

Application SQL portability

ILIKE, RETURNING, ON CONFLICT, DISTINCT ON, LIMIT/OFFSET, :: casts, arrays, and jsonb operators need an application SQL review before SQL Server becomes the write target.

Type mapping checkpoints

PostgreSQL source type SQL Server target type Migration note
uuid uniqueidentifier Direct mapping for IDs and foreign keys.
bytea varbinary(max) Binary payloads and file-like values.
boolean bit True / false storage in SQL Server.
timestamp with time zone datetimeoffset Keep offset-aware values where the application needs them.
text, jsonb nvarchar(max) JSON remains text, with SQL Server JSON functions as the access path.
Arrays, ranges, enums, domains, interval, network types Selected SQL Server storage policy Confirm per column when there is no direct SQL Server equivalent.

Why migrate PostgreSQL workloads to SQL Server?

Microsoft application stack

SQL Server is often the target when .NET applications, SQL Server Agent jobs, SSIS / SSRS / Power BI workflows, and DBA operations are already standardized around Microsoft tooling.

Azure SQL target

Azure SQL can be easier to approve in Microsoft-centered environments because identity, access, auditing, backup, and monitoring policies often already exist around Azure and SQL Server.

Reporting copy

SQL Server is a practical reporting target when PostgreSQL keeps serving the application. DBConvert performs the first migration; DBSync can keep selected tables current during validation.

DBConvert vs other PostgreSQL to SQL Server paths

Choose by the workflow you need, not by the longest feature list.

Route Where it fits Where it falls short
SSMA Microsoft Migration Assistant — SSMA covers Access, DB2, MySQL, Oracle, and SAP ASE → SQL Server; not PostgreSQL. Does not cover PostgreSQL → SQL Server at all.
Manual CSV export / import Small table-only move where CSV files and hand-built SQL Server tables are acceptable. Risky with many schemas, foreign keys, custom types, large binary fields, partial indexes, or repeat runs.
SSIS with PostgreSQL ODBC source Microsoft ETL When the migration is part of a larger Microsoft data pipeline that has to run inside SSIS anyway. PostgreSQL-specific data types and schema objects still need explicit planning; SSIS package is a separate tool to maintain.
AWS DMS log-based CDC, AWS-native Target is Azure SQL or Amazon RDS for SQL Server and the cutover needs full-load plus change replication. Coupled to AWS endpoints and AWS billing; no desktop GUI for type-mapping review.
Code-conversion products PL/pgSQL → T-SQL Project is mostly PL/pgSQL-to-T-SQL rewrite work and stored-procedure portability. Code-translation focus; schema and data transfer are a separate problem.
DBConvert / DBSync commercial desktop, Windows Local GUI migration with mapped schema + data transfer to SQL Server, Azure SQL, or Amazon RDS for SQL Server, type-mapping review, and optional DBSync for staged cutover. Commercial license; desktop tool (Windows). PL/pgSQL is not translated to T-SQL (the same is true of the manual, SSIS, and DMS routes).

Supported versions

  • PostgreSQL 8.x through 17.x
  • Amazon RDS / Aurora for PostgreSQL, Azure Database for PostgreSQL, Google Cloud SQL, Supabase
  • PostgreSQL schemas (public, custom schemas)
  • 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

Supported in this path

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

All PostgreSQL Tools

Other directions and pairs
SQL Server

All SQL Server Tools

Migration & sync options

Reverse Conversion

SQL Server to PostgreSQL

Using PostgreSQL to SQL Server 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 PostgreSQL source database

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

Connect to PostgreSQL source database from DBConvert

PostgreSQL source

Allow connections from the DBConvert machine. For self-managed servers, review the PostgreSQL connection guide; managed sources need firewall or authorized-network rules.

2

Connect to SQL Server destination database

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

Connect to SQL Server target database from DBConvert

SQL Server target

Use the regular SQL Server connection settings. Azure SQL uses SSL on port 1433; Amazon RDS for SQL Server normally uses SQL authentication.

More guides for PostgreSQL ↔ SQL Server

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