はじめに
こんにちは！
アプリケーションサービス本部ディベロップメントサービス１課の森山です。
2026年2月、Amazon Aurora DSQL に複数のアップデートがありました。
今回はその中から特に気になった2つをピックアップして、実際に統合クエリエディタから試してみます。
2026年2月のアップデート一覧
2月に発表されたアップデートは以下の5つです。(2/25時点)
| # | アップデート | 日付 |
|---|---|---|
| 1 | NUMERIC型のインデックスサポート | 2026/02/03 |
| 2 | リージョン拡大（Melbourne, Sydney, Canada Central, Calgary） | 2026/02/11 |
| 3 | IDENTITY列とSEQUENCEオブジェクトのサポート | 2026/02/13 |
| 4 | Kiro powers・AIエージェントスキルとの統合 | 2026/02/18 |
| 5 | Go, Python, Node.js 向け新コネクタのリリース | 2026/02/19 |
今回は 1 と 3 を実際に動かしながら確認していきます。
この記事で学べること
- Aurora DSQL における IDENTITY 列と SEQUENCE オブジェクトの使い方
- NUMERIC 型カラムへのインデックス作成
前提知識・条件
- DSQL の概要の説明は割愛します
- PostgreSQL の基本的な SQL 構文の知識
1. IDENTITY列とSEQUENCEオブジェクトのサポート
まずはこのアップデートについて紹介します。
これまで Aurora DSQL でオートインクリメントな整数 ID を使いたい場合、アプリケーション側で ID 生成ロジックを実装する必要がありました。
今回のアップデートでオートインクリメントな整数 ID を DSQL にお任せできるようになりました。
やってみた
クラスターの作成
まずは Aurora DSQL のクラスターを作成します。
マネジメントコンソールから「Aurora DSQL」を開き、「クラスターを作成」からクラスターを作成します。
また、今回は動作確認のため、シングルリージョンでの作成とします。
なお、2025年12月のアップデートにより、クラスターの作成が数分から数秒に短縮されました。
実際に試してみると、本当にあっという間に作成が完了します。（3秒くらいです。）
統合クエリエディタで接続
クラスターが作成できたら、そのまま統合クエリエディタで SQL を実行していきます。
統合クエリエディタは 2025年11月に追加された機能で、外部クライアントのインストールや接続設定なしに、マネジメントコンソール上から直接 SQL を実行できます。
構文ハイライトやオートコンプリートも備わっており、ちょっとした動作確認にはとても便利です。
クラスター作成から数秒でクエリを実行できる環境が整うので、今回のようなアップデートの検証にもぴったりですね。
IDENTITY列を使ったテーブル作成
では、アップデート内容の検証をしてみます。
まず、IDENTITY 列を持つシンプルなテーブルを作成します。
CREATE TABLE orders ( id bigint GENERATED ALWAYS AS IDENTITY (CACHE 1), item_name varchar(100), amount numeric(10, 2), PRIMARY KEY (id) );
GENERATED ALWAYS AS IDENTITY を指定すると、INSERT 時に id を省略しても自動で連番が振られます。
テーブルの作成は成功しますが、統合クエリエディタ上ではエラーが出ています。まだ統合クエリエディタの対応が追いついていない模様です。
CACHE はシーケンスの値を事前にメモリに確保しておく数を指定するパラメータです。
CACHE 1 を指定しているのは、Aurora DSQL では CACHE の明示的な指定が必須であるためです。
なお、DSQL の CACHE は 1 または 65536 以上 のみ指定可能となっています。
CACHE の挙動やワークロードに応じた使い分けについては、下記ページに詳細があるのでご確認ください。
では、データを挿入してみます。
INSERT INTO orders (item_name, amount) VALUES ('ノートPC', 128000.00); INSERT INTO orders (item_name, amount) VALUES ('マウス', 3500.00); INSERT INTO orders (item_name, amount) VALUES ('キーボード', 12800.00);
結果を確認します。
id が自動で 1, 2, 3 と採番されていますね。
SEQUENCEオブジェクトの作成
次に、SEQUENCE オブジェクトを直接作成して使ってみます。
CREATE SEQUENCE order_seq CACHE 65536 START WITH 1001;
こちらもまだ統合クエリエディタが対応できていないみたいです。
SEQUENCE を使ってデータを挿入します。
INSERT INTO orders (id, item_name, amount) OVERRIDING SYSTEM VALUE VALUES (nextval('order_seq'), 'モニター', 45000.00);
GENERATED ALWAYS で定義した IDENTITY 列に明示的に値を入れるため、OVERRIDING SYSTEM VALUE を指定しています。
動作確認してみます。
SELECT * FROM orders;
order_seq から採番された 1001 が入っていることが確認できました。
UUIDとの使い分け
Aurora DSQL の公式ドキュメントでは、スケーラビリティが重要なワークロードでは UUID を推奨しています。
UUID はセッション間の調整なしに生成できるため、分散システムである DSQL との相性が良いです。
一方、SEQUENCE / IDENTITY は人間が読みやすい連番が必要なケース（注文番号、サポートケース番号など）に向いています。
用途に応じて使い分けるのが良さそうですね。
2. NUMERIC型のインデックスサポート
次の検証をしていきます。
これまで Aurora DSQL では NUMERIC 型のカラムにインデックスを作成できませんでした。
今回のアップデートにより、NUMERIC カラムをプライマリキーやセカンダリインデックスに使用できるようになりました。
やってみた
先ほど作成した orders テーブルの amount カラム（NUMERIC型）にインデックスを作成してみます。
なお、Aurora DSQL では CREATE INDEX ではなく CREATE INDEX ASYNC を使用します。
CREATE INDEX ASYNC idx_orders_amount ON orders (amount);
これで、例えば金額の範囲検索などでインデックスが活用されるようになります。
レコードを1000件程度に増やして、インデックスの効果を確認してみます。generate_series を使ってテストデータを投入します。
INSERT INTO orders (item_name, amount) SELECT 'item-' || g, (random() * 100000)::numeric(10,2) FROM generate_series(1, 1000) AS g;
以下のSQLを実行してみます。
SELECT amount FROM orders WHERE amount >= 10000.00;
ここで SELECT * ではなく SELECT amount としているのは、インデックスに含まれるカラムだけを取得することで、テーブル本体へのアクセスなしにインデックスのみで結果を返せる（Index Only Scan）ようにするためです。
SELECT * だとオプティマイザが主キーのスキャンを選択するケースがあります。
EXPLAIN ANALYZE で実行計画を確認してみます。
Limit (cost=95978.27..96463.31 rows=10000 width=9) (actual time=1.281..5.958 rows=898 loops=1)
-> Index Only Scan using idx_orders_amount on orders (cost=95978.27..133181.99 rows=767026 width=9) (actual time=1.280..5.876 rows=898 loops=1)
Index Cond: (amount >= 10000.00)
-> Storage Scan on idx_orders_amount (cost=95978.27..133181.99 rows=767026 width=9) (actual rows=898 loops=1)
Projections: amount
-> B-Tree Scan on idx_orders_amount (cost=95978.27..133181.99 rows=767026 width=9) (actual rows=898 loops=1)
Index Cond: (amount >= 10000.00)
Planning Time: 0.081 ms
Execution Time: 6.026 ms
Index Only Scan using idx_orders_amount と表示されており、NUMERIC 型のカラムに作成したインデックスが正しく使われていることが確認できました。
まとめ
今回は Aurora DSQL の 2026年2月のアップデートから、IDENTITY 列・SEQUENCE オブジェクトのサポートと NUMERIC 型のインデックスサポートを試してみました。
IDENTITY 列と SEQUENCE により、これまでアプリケーション側で実装が必要だった連番 ID の生成がデータベース側で完結できるようになりました。
NUMERIC 型のインデックスサポートも需要がありそうです。
PostgreSQL からの移行もよりスムーズになりそうですね！
ただし、CACHE の制約や引き続き残る制約もあるので、導入時には以下の公式ドキュメントで対応状況をご確認ください。
個人的には、DSQL が着実に PostgreSQL 互換性を高めてきている印象を受けました。
今後のアップデートも楽しみです。
