# Why this combination Tortoise ORM is an async-native Python ORM with a Django-like model API and an asyncpg backend. Aurora DSQL is a serverless, distributed PostgreSQL-compatible engine where connection efficiency and concurrency matter. Together they form a stack suited for high-concurrency async applications—provided you make a few concrete changes to how you model data, open connections, apply schema changes, and handle concurrent writes.
# Core adaptations you must make The article demonstrates these four practical adaptations used in a sample rideshare application (riders, drivers, rides, payments):
- UUID primary keys: Use UUID v4 for primary keys to avoid coordinated ID generation across Aurora's distributed architecture. Tortoise supports fields.UUIDField(primary_key=True, default=uuid.uuid4).
- IAM-authenticated asyncpg connections: Replace static passwords with short-lived IAM tokens generated by boto3's DSQL client. Initialize Tortoise with asyncpg using the IAM token as the password and TLS enabled. Patch asyncpg's connection reset so the connection pool works with IAM token semantics.
- Individual DDL execution: Aurora DSQL does not accept multiple DDL statements in one transaction. Run schema creation and other DDL statements one at a time through a raw asyncpg connection rather than batching DDL into a single transaction.
# How the sample rideshare app flows The sample models riders, drivers, rides, and payments as Tortoise ORM models mapped to Aurora tables. At runtime:
- 1The app generates an IAM authentication token using boto3's DSQL client.
- 2It patches asyncpg's connection reset behavior to make pooling compatible with IAM tokens.
- 3Tortoise ORM initializes using the asyncpg backend with TLS and the IAM token as the password.
- 4Schema creation executes each DDL statement individually through a raw asyncpg connection.
- 5App code runs async CRUD flows: creating users, requesting rides, completing trips, and processing payments. Writes that can conflict use OCC retry with exponential backoff and jitter.
# Practical implications for engineers
# When to follow these patterns Apply these changes when building async, high-concurrency Python services that connect directly to Aurora DSQL via asyncpg and when you need serverless scaling, short-lived credentials, and efficient use of async coroutines. If you rely on integer sequences or identity columns for IDs, Aurora DSQL still supports sequences and identity with CACHE, but the sample recommends UUID v4 for distributed-friendly ID generation.
# Quick checklist before production
- Switch primary keys to fields.UUIDField(primary_key=True) where cross-node generation matters.
- Patch asyncpg connection reset so connection pools remain stable with IAM tokens.
- Run DDL statements individually during schema creation/migrations.
- Add OCC detection and async retry with exponential backoff and jitter for conflicting writes.
# Bottom line Tortoise ORM and Aurora DSQL work together for async Python services if you adapt model keys, connection authentication, DDL execution, and write concurrency handling. The sample rideshare app provides concrete patterns you can reuse for similar high-concurrency domains.