Read this before migrating to Aurora DSQL
I worked on a production migration move from RDS to DSQL which took substantial migration and testing work.
These are the areas I would investigate and things I would consider if knowing what I know now. Some describe what I experienced; others reflect features DSQL has added since its early releases.
Primary-key: Preserve the identifiers people already use
If you are coming from MySQL/mariadb/etc databases, you likely already use auto incrementing integers, and you might have other systems or teams that rely on your data.
UUID is recommended by AWS, but for existing systems this might break contracts with external systems as mentioned above. In such cases, you can define your own sequences and identity columns which have been supported since February 2026.
For a new target table, an identity column can accept imported IDs while generating later ones.
CREATE TABLE customer (
id BIGINT GENERATED BY DEFAULT AS IDENTITY
(START WITH 8420001 CACHE 65536) PRIMARY KEY,
name TEXT NOT NULL
);DSQL requires an explicit sequence cache: 1 or at least 65536. Large caches trade closer allocation ordering for throughput; gaps and out-of-order allocation are normal. For an existing sequence, START WITH alone does not move its current value, review RESTART WITH and cached allocations during a controlled cutover.
Transactions: Find every large write transaction
The 3,000-row mutation limit was particularly painful for us. Existing code could update many records in one transaction without considering batches. Migrating meant revisiting those paths.
Get theoneamin’s stories in your inbox
Join Medium for free to get updates from this writer.
Search bulk updates, cleanup jobs, imports and batch writers. Count every table changed by the transaction, including metadata and cascading changes. Then measure modified bytes: a small number of wide rows can still reach the 10 MiB limit.
Before splitting a job, agree what partial completion means. If the business operation requires all records to change atomically, batching requires a redesign of that operation.
Locks: Test contention and retries together
Review pessimistic JPA locks, shared counters and frequently updated records. DSQL’s OCC means concurrent work may fail instead of waiting. A retry must start a fresh transaction and repeat the decision using fresh data.
Test competing workers, bounded retries and duplicate prevention together. An ORM’s optimistic version column does not replace handling database-level conflicts.
Password: Plan authentication and connection renewal
DSQL authenticates with IAM. The connection still has a database username; a signed token goes in the driver’s password field. Token expiry affects new authentication, not an established connection. Use a DSQL connector where available and test pool renewal with your application’s IAM role.
Retries: Expect occasional transient failures
We occasionally saw server-unavailable errors. AWS Support advised us to retry. That is our production experience; AWS also documents transient connection and concurrency errors during some recovery scenarios.
Keep the retry policy sensitive to the operation’s outcome: reconnecting is different from safely replaying a possibly committed write. Record errors and operation IDs so you can reconcile uncertain results.
An occasional error does not by itself establish an SLA breach. The SLA has defined monthly availability calculations and conditions; the frequency of errors alone cannot settle that question.
For the next migration, I would require a rehearsal that covers existing IDs, oversized jobs, competing writers, batch restarts and connection replacement. That is the work that tells you whether DSQL’s operational benefits justify the application changes.
