On August 27, 2026, AWS announced that Amazon Aurora DSQL now supports foreign key constraints. Anyone planning an Aurora DSQL migration just stopped having to give something up. The referential integrity you declared in Oracle, SQL Server, MySQL or PostgreSQL no longer has to be dropped on the way in. HexaRocket has supported DSQL as a migration target from all four of those sources for a while now, across schema conversion, data migration, change data capture and validation, and today we are adding foreign keys to Aurora DSQL to that list. One day after the announcement by AWS. As far as we know, HexaRocket is the only migration tool on the planet doing end to end Aurora DSQL migration at all, and we have made a point of tracking DSQL feature by feature as AWS ships them instead of waiting for a quarterly roadmap slot.
Same-engine and cross-engine migrations into AWS, covering schema conversion, data migration, CDC and rollback.
Register for the webinarHexaRocket, is an end-to-end database migration tool from HexaCluster, the creators of Ora2Pg, pgBadger, credcheck and more tools and extensions for PostgreSQL. HexaRocket supports database migration with live replication and rollback from Oracle, SQL Server, MySQL, MariaDB, Sybase ASE and DB2 to PostgreSQL and Postgres compatible databases like AWS RDS/Aurora PostgreSQL, YugabyteDB, Percona Distribution for PostgreSQL, EDB and other forks.
DSQL as a HexaRocket target is not new. Schema migration, data migration, log-based (transaction log-based) CDC, batch CDC (ETL mode), validation and reverse replication were already running into DSQL from Oracle, SQL Server, MySQL and PostgreSQL sources before this week.
You can now declare FOREIGN KEY constraints on new and existing tables in a DSQL cluster. See the foreign key documentation from AWS for more details. All five referential actions, NO ACTION, RESTRICT, CASCADE, SET NULL and SET DEFAULT, both the MATCH FULL and MATCH SIMPLE match types, and deferrable constraints are all now available in every region where DSQL runs.
How DSQL enforces the constraint is something important to know. There is no locking in the PostgreSQL sense. A transaction verifies the constraint against its start-time snapshot, then DSQL implicitly applies KEY SHARE to the referenced rows and settles the argument at commit. If a concurrent transaction deleted the row you were pointing at, your commit fails with ERROR: change conflicts with another transaction (OC000) (SQLSTATE 40001) instead of waiting on a lock. That is just DSQL's optimistic concurrency model doing its job. What it means for a migration tool is a separate question, and I get to it further down.
AWS is also explicit that referential integrity checks cost extra reads on every DML against a referenced or referencing table. Benchmark before you put a foreign key on a hot table. That is their advice, and it is good advice.
HexaRocket has always supported PostgreSQL as a target, including AWS RDS PostgreSQL and Aurora PostgreSQL, from source databases like Oracle, SQL Server, MySQL, Sybase and DB2. It has been extracting DDL from those sources for years, for every target we support. That extraction does not change per target. What changes is what happens next.
When the target is DSQL, the conversion stage walks the extracted object set and filters out whatever DSQL cannot accept. Triggers go. PL/pgSQL bodies go, since DSQL supports SQL functions but not procedural languages. Temporary tables, tablespaces and TRUNCATE go, per the PostgreSQL to Aurora DSQL migration guidance. Until August 27, foreign keys went too.
We already had the constraint fully parsed. Referencing table and columns, referenced table and columns, the ON DELETE and ON UPDATE actions, the match type, the deferrability. All of it sitting in the parse tree. We just refused to emit it, and printed an unsupported-object message instead.
So the change was to stop refusing. Update the grammar to emit the constraint in DSQL's dialect, map each source's referential action vocabulary onto DSQL's, let it through. The transformation and the end to end testing across all four sources took less than a few hours.
That is only possible because HexaRocket's schema conversion is deterministic. There is no AI and no LLM anywhere in the conversion path. The engine parses source DDL into a real parse tree and emits target dialect DDL through grammar rules, so a new target capability is a grammar change with a test suite behind it rather than a prompt to re-tune.
Had the conversion been model-generated, the same change would have been non-deterministic. The same source foreign key could come out one way on one run and another way on the next, and every emitted constraint would need validating by hand before anyone could sign off on the schema. That is days or weeks of work rather than hours during the conversion of large volumes of schema objects and databases, and no amount of extra testing makes it go away.
The one part that needed real thought was the referential action vocabulary, because the four sources (Oracle, SQL Server, MySQL, PostgreSQL) do not agree on it. Oracle only implements ON DELETE CASCADE and ON DELETE SET NULL, and has no ON UPDATE clause at all. SQL Server and MySQL carry the wider set. PostgreSQL sits closest to DSQL, since DSQL follows PostgreSQL constraint semantics. So the Schema conversion engine of HexaRocket maps each source's vocabulary onto what DSQL accepts instead of assuming a passthrough.
In the following screenshot, we can see the HexaRocket dashboard that shows the DDL of one of the Foreign keys in MySQL and the converted foreign key constraint in DSQL.
Foreign keys join an object set HexaRocket already converts and deploys for DSQL from Oracle, SQL Server, MySQL and PostgreSQL sources.
CREATE INDEX ASYNC, which is what DSQL wants for non-blocking creationFollowing is a screenshot showing the Schema Conversion status from MySQL to Aurora DSQL.
DSQL is PostgreSQL compatible on the wire and through most of the language, but its DDL is not PostgreSQL's DDL. Copy a schema straight across from a PostgreSQL source and it will fail on index syntax, on temporary tables, on trigger definitions and on procedural function bodies. Emitting DSQL's own dialect is why the schema deploys instead of handing you a list of errors to work through by hand.
PostgreSQL consulting across tuning, architecture and day to day operations.
Automated conversion of the code objects that decide a migration timeline.
Homogeneous and heterogeneous data movement, validated end to end.
Loading large volumes of data into a distributed database is a different exercise from loading into a single-node PostgreSQL instance. DSQL's architecture brings a few real challenges that migration tooling has to handle well, and HexaRocket engineered its data migration path around each of them.
Transaction sizing
DSQL bounds how much a single transaction can change, in both rows and size. A loader that ignores this will see writes rejected partway through a migration. HexaRocket sizes each write batch to stay within those bounds and, when a batch still comes back too large, automatically splits and shrinks it and retries, so the load keeps moving without manual tuning.
Concurrency conflicts
DSQL uses a lock-free, optimistic concurrency model. Rather than blocking, it surfaces conflicts at commit time as serialization errors, so under parallel load a share of commits will be rejected and need to be retried. HexaRocket detects these conflicts and retries automatically with exponential backoff and jitter, so parallel workers converge instead of failing.
Multiple sources
Data migration to DSQL is available from Oracle, SQL Server, MySQL, and PostgreSQL sources. The result is that migrating data into DSQL at scale works reliably, with HexaRocket absorbing the distributed-system details so the user does not have to.
Following screenshot from hexaRocket shows the Data Migration Progress of one of the migration projects from MySQL to DSQL.
Log-based CDC reads the source's change log directly, whether that is Oracle redo, the SQL Server transaction log, the MySQL binlog or PostgreSQL WAL. HexaRocket converts each captured row change into the DSQL dialect statement and applies it continuously, so the target tracks the source in near real time. In a typical migration it runs after the initial load. It also runs standalone against an already-populated target when only ongoing changes need to flow. The apply path obeys the same DSQL rules as the initial load, batch bounds and serialization retries included, which is what keeps replication healthy through wide-row episodes and write spikes with nobody watching it.
HexaRocket CDC dashboard for a DSQL target. Replication lag, applied change counts and per-table status.
Batch CDC is the alternative where log-based capture is not the right fit, whether because of source permissions, a source that exposes no usable log, or tables where polling is simply cheaper. It tracks changed rows through a watermark column and applies them to DSQL through a stageless, conflict-aware upsert path. Same discipline on the target side, different way of capturing the change.
Reverse replication out of DSQL is supported too, which is what allows you to achieve rollback from DSQL to MySQL and other supported databases using HexaRocket. How all three work underneath, the log position tracking, the ordering guarantees, the conflict-aware apply path, deserves its own articles and will get them.
| Capability | Status |
|---|---|
| Schema migration (tables, primary keys, unique constraints, indexes, sequences, views, functions) | Supported |
| DSQL-specific datatype handling | Supported |
| Foreign keys to Aurora DSQL | Supported, August 28, 2026 |
| Data migration to DSQL (Oracle, SQL Server, MySQL, PostgreSQL) | Supported |
| Log-based CDC to DSQL (Oracle, SQL Server, MySQL, PostgreSQL) | Supported |
| Batch CDC to DSQL | Supported |
| Data validation | Supported |
| Reverse replication out of DSQL | Supported |
If you are weighing Amazon Aurora DSQL as a target for an Oracle, SQL Server, MySQL or PostgreSQL database, we will show you what your schema looks like on the other side, foreign keys included. Ask us for a demo at hexacluster.ai/contact-us, or read more about HexaRocket and the database migrations we support. If you want a migration effort estimate before you commit to anything, start with DMAT, our free assessment tool.
If you are migrating off legacy or complex Oracle, SQL Server, DB2, Sybase, MySQL, MariaDB workloads, HexaCluster provides end to end database migration to PostgreSQL and application migration and modernization, with HexaRocket automating the schema and code conversion. Once you are live, we also offer managed DBA services and 24x7x365 support.
To start a conversation, write to us at connect@hexacluster.ai or reach the HexaCluster PostgreSQL consulting team.
Subscribe to our newsletter and stay tuned.
Akhil is a Senior Development Manager at HexaCluster with expertise in architecting and developing enterprise applications using Java Spring Boot, Golang, Python, and other modern technologies. He has worked extensively with Oracle, PostgreSQL, SQL Server, MySQL, Snowflake, and various other databases, and is highly experienced in complex database and application migrations.
Suman Michael, Technical Director for R&D at HexaCluster, with a focus on machine learning (ML), deep learning (DL), and generative AI (GenAI), brings a wealth of expertise to the table. With a mastery of languages such as C, Go, Rust, Java, Python, and JavaScript, he excels in crafting robust, data-intensive, and concurrent systems. Michael’s proficiency extends to PostgreSQL development and administration, showcasing his well-rounded technical prowess. A devoted advocate of open source, he remains actively engaged in contributing to its community, further enriching the collaborative landscape of technology.
Start your migration journey 🚀
start your migration journey with our expert team
Database & Application Migration Assessment Tool
End-to-End Database Migration & Modernization Tool
Database Code Object Conversion to PostgreSQL
MyBatis Mapper Conversion to PostgreSQL
Enterprise Data Replication & Live CDC
Oracle Compatibility Layer for PostgreSQL