Audience
Database migration teams — migration leads, DBAs, architects, application developers, and project managers responsible for SQL governance during legacy-system modernization or database migration.Problem
Database migration projects usually start with “can this SQL run on the target database?”, but production soon raises a harder question — “will it still run fast enough?”. After moving SQL from Oracle to PostgreSQL, openGauss, GaussDB, Kingbase, DM, TDSQL, or OceanBase, even syntactically converted SQL can develop new performance problems from differences in optimizer behavior, indexing, data types, hint handling, pagination, and distributed execution. Migration must therefore solve not only syntax compatibility, but also performance compatibility.Goal
Take migration from “it runs” to “it runs stably and efficiently” — elevating syntax migration to SQL Migration Engineering, and keeping legacy performance problems out of the new database.Workflow
PawSQL turns migration SQL governance into an end-to-end pipeline:Dependencies
Built from the following capabilities (see each capability page for check items and rewrite logic):SQL Quality Check
Query Rewrite
Index Recommendation
Execution Plan Analysis
Performance Validation
Distributed SQL Optimization
Success Criteria
Four Categories of SQL Risk in Migration
Migration SQL risk usually falls into four categories:- Syntax compatibility — database-specific functions, keywords, hints, pagination syntax, DDL, and stored procedures (e.g.
NVL→COALESCE) - Semantic compatibility — the SQL runs but results differ (NULL handling, empty strings, date precision, collation, implicit conversion)
- Performance compatibility — the access path breaks after conversion, e.g.
TRUNC(create_time)→DATE(create_time)prevents efficient index use - Distributed execution — moving from centralized to distributed adds cross-node joins, data redistribution, mismatched distribution keys, and shuffle