Use Aurora DSQL instead of Aurora Serverless v2

[tmokmss]

This project currently uses Amazon Aurora PostgreSQL Serverless v2 + Prisma ORM. I propose migrating to Amazon Aurora DSQL.

Benefits of Migration

Pain Points of Aurora Serverless v2

• Cold start: When Scale to Zero is enabled, resuming takes 15–30 seconds. This is unacceptable for user-facing applications
• Scale to Zero is hard to benefit from: Although Scale to Zero exists, configurations where cron jobs access the DB every 10 minutes keep the cluster warm at all times, completely negating cost savings
• VPC required: Requires NAT Gateway/Instance, which adds architectural complexity and cost
• Connection management: RDS Proxy is needed for handling many concurrent connections from Lambda, but it doesn't fully solve the problem

Advantages of Aurora DSQL

• Truly serverless: No infrastructure management, automatic scaling, no cold starts when idle
• No VPC required: Connects via public endpoint. Eliminates the need for NAT Gateway/Instance, greatly simplifying the architecture
• IAM authentication: No database password management needed

Migration Blockers

1. ORM Compatibility Issues

This project uses Prisma ORM, which has known issues when used with DSQL.

• Prisma: db push fails under certain conditions → prisma/prisma#26643
  • AWS has released official DSQL support for Prisma (announcement), including the aurora-dsql-prisma CLI tool that can automatically handle DDL transaction constraints, FK constraint removal, etc.
  • For db migration, generating migrations against a local PostgreSQL and applying them to DSQL via the CLI tool can work around the db push issues
• Drizzle ORM: DSQL support feature request is in progress → drizzle-team/drizzle-orm#5248
  • A member of the DSQL service team is actively working on a patch, but it is still in early stages

2. Unsupported PostgreSQL Features

DSQL is PostgreSQL-compatible, but some features are not supported. If the current codebase uses any of these features, application-side changes will be required.

→ Unsupported PostgreSQL features in Aurora DSQL

3. Different Transaction Model

• DSQL uses Optimistic Concurrency Control (OCC)
• Transactions may be aborted on write conflicts, so retry logic needs to be implemented
• Isolation level is fixed at Repeatable Read

[konokenj]

Prisma → Drizzle ORM 同時移行の提案

DSQL移行と同時に、ORMをDrizzle ORMに移行することを提案します。

Prismaからの移行理由

1. prisma generate への依存

Prisma 7でRustバイナリは不要になりましたが、prisma generate は引き続き必要です（v7リリースブログ: 出力先が node_modules からプロジェクトソースに変わったのみ）。現在のstarter-kitでもDockerfileに RUN npx prisma generate が必要です。Drizzle ORMはスキーマがpure TypeScriptで、コード生成ステップが不要です。

2. DSQLのFK非サポートとの整合性

Prismaの @relation はスキーマレベルでFK制約を前提としており、DSQLでは aurora-dsql-prisma CLIツールでFK文を除去する追加ステップが必要です。一方、Drizzleの relations はアプリケーション層のみで機能し、DBスキーマにFK制約を生成しません（Drizzle公式ドキュメント: "they are used to define relations between tables on the application level only... which allows them to be used with databases that do not support foreign keys"）。

3. Prisma 7のアーキテクチャ変更

現在のstarter-kitはPrisma 6ですが、将来のv7移行時にリスクがあります。Prisma 7はRustランタイムからTypeScriptへアーキテクチャを移行しており、高並行の小クエリで性能低下が報告されています。Prisma公式はこれを認めた上で改善中としています（Prisma 7 AMA: "If your workload previously benefited from Rust-level threading, you may see parity or regressions. This was a deliberate trade-off"）。

DDL制約とマイグレーション戦略の補足

Issue本文の「Migration Blockers」に補足です。DSQLの主要なDDL制約:

制約	内容
1トランザクション1DDL	複数DDLを1トランザクションで実行不可
CREATE INDEX ASYNC必須	同期INDEXは使用不可
SERIAL非サポート	UUIDまたはIDENTITY列を使用
FK非サポート	アプリ層で参照整合性を担保
ALTER COLUMN TYPE / DROP COLUMN非サポート	テーブル再作成が必要

drizzle-kit migrate は全未適用マイグレーションを1トランザクションで実行するため、DSQLと衝突します。Prisma側の aurora-dsql-prisma も破壊的DDL変更（ALTER COLUMN TYPE等）は未対応で、この点は両ORM共通です。

推奨アプローチは drizzle-kit generate + 自前ランナー（1文ずつ実行） です。Vercel公式の aws-dsql-movies-demo でもこのパターンが採用されています。

リトライ要件の補足

Issue本文でOCCのリトライに言及されていますが、ネットワーク一時障害からの復旧も必要です。一時的エラー（接続断）と永続的エラー（認証失敗）を区別するリトライ戦略が求められます。

[konokenj]

DSQL移行に合わせてVPCを完全に削除します。