PostgreSQL → SQL Server Migration

I inventoried every table, column, constraint, index, trigger, and sequence in the source PostgreSQL database across two schemas, flagged PostgreSQL-specific types with no direct SQL Server equivalent, and discovered mid-project that Microsoft's SSMA no longer supports PostgreSQL as a source — so I pivoted to a custom Python ETL instead.

I converted every table, key, and index across two schemas to T-SQL, mapped PostgreSQL-specific types to their SQL Server equivalents, and rewrote a generic PL/pgSQL audit-logging trigger — shared across multiple tables via dynamic metadata — as two dedicated T-SQL triggers using the native JSON type and FOR JSON PATH.

I built a Python ETL pipeline that migrated 20.5 million rows in the correct referential order, disabling the audit triggers during the bulk load to avoid flooding the audit table with migration noise, then re-enabled them and reseeded the identity counter — validating zero rows leaked into the audit log afterward.

I validated the migration across three layers: aggregate checksums matching exactly between source and target, four constraint-enforcement tests confirming SQL Server rejects bad data the same way PostgreSQL did, and three representative queries returning identical results on both systems.

I baselined six representative queries against both systems, then investigated a real regression: SQL Server ran one join nearly 2× slower than PostgreSQL. Four different tuning attempts all confirmed the same conclusion: a genuine structural bottleneck, not a missing index.

I documented every phase as I completed it — architecture, decisions, real errors and how I fixed them, and results — and packaged the project into this standalone, presentable portfolio piece with full source code and commit history on GitHub.