Move schema and data from Microsoft SQL Server to a PostgreSQL cluster running the ParadeDB extension.
ParadeDB adds vector search, columnar storage, and advanced indexing on top of PostgreSQL. Migrating lets you keep relational power while adding AI-friendly features at lower licence cost.
Use sqlpackage
or bcp
to dump SQL Server data, pgloader
for one-shot schema + data moves, and psql
for replaying generated DDL into ParadeDB.
Run sqlpackage /Action:Script /TargetFile:schema.sql
.The file contains T-SQL DDL that you will translate to PostgreSQL syntax.
Map NVARCHAR
→TEXT
, BIT
→BOOLEAN
, DATETIME
→TIMESTAMP
, MONEY
→NUMERIC(19,4)
. Replace IDENTITY with GENERATED BY DEFAULT AS IDENTITY
or SERIAL
.
Connect with psql
, enable the extension, then run the adapted DDL:CREATE EXTENSION IF NOT EXISTS paradedb;\i schema_postgres.sql
Dump each table with bcp "SELECT * FROM dbo.Customers" queryout customers.csv -c -t"|"
.Then load with \COPY customers FROM 'customers.csv' WITH (FORMAT csv, DELIMITER '|');
Run row-count and checksum comparisons on both sides.Example: SELECT COUNT(*) FROM customers;
vs the SQL Server result.
Add embedding columns and ParadeDB indexes: ALTER TABLE products ADD COLUMN name_embedding vector(768);
then SELECT create_vector_index('products','name_embedding');
Migrate in stages, disable triggers while loading, keep transactions small, and test application queries under load before switchover.
Avoid trusting auto-converted DDL; always review types and constraints.Do not copy SQL Server COLLATION settings blindly—use PostgreSQL defaults unless case sensitivity is critical.
.
Yes. pgloader
can connect to SQL Server and ParadeDB simultaneously, converting types on the fly. However, manual review is still recommended.
ParadeDB runs inside PostgreSQL, so use PL/pgSQL. T-SQL procedures must be rewritten manually.
Terabyte-scale moves succeed when you batch tables, disable indexes during load, and use parallel \COPY
.