書き込み性能がスケールアウトする Amazon Aurora PostgreSQL Limitless Database が一般提供となったので、実際に機能して試してみました!

書き込み性能がスケールアウトする Amazon Aurora PostgreSQL Limitless Database が一般提供となったので、実際に機能して試してみました!

AWS re;Invent 2023 で発表された書き込み性能がスケールアウトする Amazon Aurora PostgreSQL Limitless Database が一般提供となりました!

ウィスキー、シガー、パイプをこよなく愛する大栗です。

昨年の AWS re:Invent 2023 で発表されていた、書き込み性能をスケールできる Amazon Aurora PostgreSQL Limitless Database が一般提供となりました!早速レポートします。

Amazon Aurora PostgreSQL Limitless Database

Amazon Aurora PostgreSQL Limitless Database(以降 Limitless Database) は AWS re:Invent 2023 で発表されていた書き込み性能をスケールできる Aurora です。

Limitless Database はデータベースのシャーディング構成をマネージドな構成で提供することで、既存のような読み込み性能のスケールだけでなく、書き込み性能のスケールも行うためのデータベースです。複数ノード間にまたがるトランザクションなどもサポートして書き込み性能もスケールアウトするため、いわゆる NewSQL の一種と呼べると思います。

re:Invent 2023 での Limitless Database に関するブレイクアウトセッションの内容は以下のエントリをご覧ください。

https://dev.classmethod.jp/articles/report-achieving-scale-with-amazon-aurora-limitless-database/

Limitless Database は複数のデータベース ノードで構成される2階層アーキテクチャになっています。ルーターはデータベースの分散を管理してクライアントからの SQL 接続を受け入れて解析してシャードへ送信して、シャードはシャーディングされたテーブルのサブセットです。

limitless_high_level_arch_GA

Limitless Database を実際に試した内容はエントリの後半です。

キーワード

Limitless Database では以下の重要なキーワードがあります。

  • DB シャードグループ:Limitless Database のコンテナ
  • ルーター:クライアントから SQL 接続を受け、SQL コマンドをシャードに送信して、システム全体の一貫性を維持し結果をクライアントへ返す
  • シャード:シャードテーブルのサブセット、リファレンステーブルの完全なコピー、スタンダードテーブルを格納します
  • シャードテーブル:データがシャード間で分割されたテーブル
  • シャードキー:シャード間のパーティション分割を決定するためのシャードテーブル内のカラム
  • 共存テーブル:同じシャードキーを共有し、明示的に共存として定義されている複数のシャードテーブルで、同じシャードキーのすべてのデータは同じシャードへ送信される
  • リファレンステーブル:すべてのシャードにデータが完全にコピーされたテーブル
  • スタンダードテーブル:Limitless Database の標準のテーブルタイプで、システムで内部的に選ばれたシャードの一つに保存されて、シャードテーブルやリファレンステーブルに変換できます

Limitless Database を使用可能なリージョン

現在利用可能なリージョンは以下のようになっています。

  • アジアパシフィック (香港)
  • アジアパシフィック (シンガポール)
  • アジアパシフィック (シドニー)
  • アジアパシフィック (東京)
  • 欧州 (フランクフルト)
  • 欧州 (アイルランド)
  • 欧州 (ストックホルム)
  • 米国東部 (バージニア北部)
  • 米国東部 (オハイオ)
  • 米国西部 (オレゴン)

Limitless Database の要件

Limitless Database には以下の要件[1]があります。

  • Limitless Database は、Aurora I/O 最適化 DB クラスターのストレージ構成のみをサポートします
  • Limitless Database は、専用の特別な Aurora PostgreSQL DB エンジン バージョン 16.4-limitless を使用します
  • DB クラスターには、ライター DB インスタンスまたはリーダー DB インスタンスを含めることはできません
  • 拡張モニタリングとパフォーマンス インサイトを使用する必要があります
  • PostgreSQL ログを Amazon CloudWatch Logs にエクスポートする必要があります

Limitless Database に関する考慮事項

Limitless Database の DB シャードグループには、次の考慮事項[2]が適用されます。

  • DB クラスターごとに 1 つの DB シャードグループのみを成できます
  • リージョンごとに最大 5 つの DB シャードグループを作成できます
  • シャードグループの最大容量は 16~6144 ACU に設定できます
  • DB シャードグループの最大容量を変更しても、ルーターとシャードの数は変わりません
  • ルータごとに 1 つの IP アドレスが必要で、DB シャードグループ内のシャードごとに最大 3 つの IP アドレスが必要です
  • DB シャードグループをパブリックにアクセス可能にする場合は、VPC にインターネット ゲートウェイを設定してください
  • SQL 関数を使用してシャードを分割やルーター追加を行います
  • シャードのマージはサポートされていません
  • 個々のシャードとルーターを削除することはできません
  • テーブル行の値の変更を含め、シャードキーをいかなる方法でも変更 (UPDATE 操作など) することはできません
  • 分離レベルは REPEATABLE READ、READ COMMITTED、READ UNCOMMITTED がサポートされています
  • 一部の SQL コマンドはサポートされていません[3]
  • すべての PostgreSQL 拡張機能がサポートされているわけではありません[4]
  • シャードグループを作成するとき、または新しいシャードグループノード (シャードまたはルーター) を追加するとき、それらのノードは DB クラスターで使用可能な AZ の 1 つに作成されます
  • コンピューティングの冗長化を「2 つのフェイルオーバーターゲットを使用したコンピューティングの冗長性」にする場合は、DB サブネット グループに少なくとも 3 つの AZ があることを確認してください

Limitless Database DB クラスターには、次の考慮事項[2:1]が適用されます。

  • AWS 管理ポリシーを使用して、データベースとアプリケーションに対するアクセス許可をユーザーのユースケースに必要なアクセス許可に制限することが推奨されます
  • Aurora PostgreSQL Limitless Database DB クラスターを作成するときは、DB シャードグループのスケーリング パラメータのみを設定します
  • DB シャードグループを含む DB クラスターを停止または起動できません
  • DB クラスターを削除する必要がある場合は、まず DB シャードグループを削除する必要があります
  • Aurora PostgreSQL Limitless データベースはレプリケーション ソースにできません

Limitless Database でサポートされていない機能

以下の機能は Limitless Database でサポートされていません[4:1]

  • Active Directory (Kerberos) 認証
  • Amazon DevOps Guru
  • Amazon ElastiCache
  • Amazon RDS ブルー/グリーンデプロイ
  • Amazon RDS Proxy
  • Aurora Auto Scaling (DB クラスターにリーダーインスタンスを自動的に追加する)
  • Aurora Global Database
  • Aurora 機械学習
  • Aurora recommendations
  • Aurora Serverless v1
  • AWS Lambda integration
  • AWS Secrets Manager
  • Babelfish for Aurora PostgreSQL
  • DB クラスタークローン
  • データベースアクティビティストリーム
  • リードレプリカ

Limitless Database の料金

データベースインスタンスの料金設定

Limitless Database は Aurora Serverless v2 と同じ料金体系となっています。ただし、Limitless Database は Aurora I/O 最適化 DB クラスターのストレージ構成のみをサポートします。そのため、東京リージョンでは 1 ACU 時間あたり USD 0.26 となっています。

ただし Limitless Database は最小 16 ACU であるので

USD 0.26 * 16 ACU = USD 4.16

最小構成で 1 時間あたり USD 4.16(USD 1 を 153 円とすると 636.48 円)からで、「1 つのフェイルオーバーターゲットを使用したコンピューティングの冗長性」の場合は USD 8.32(1272.96 円)から、「2 つのフェイルオーバーターゲットを使用したコンピューティングの冗長性」の場合は USD 12.48(1909.44 円)からとなります。

データベースストレージの料金設定

Aurora I/O 最適化が前提であるため

USD 0.27/毎月の GB あたり

なっており I/O 料金はストレージ料金に含まれます。

やってみる

ここでは東京リージョンを前提とします。

Limitless Database の作成

RDS のデータベースを作成します。作成方法は 標準作成 を選択して、エンジンは Aurora (PostgreSQL Compatible) を選択します。

スクリーンショット 2024-11-01 7.29.02

エンジンバージョンは Aurora PostgreSQL with Limitless Database (Compatible with PostgreSQL 16.4) を選択します。

スクリーンショット 2024-11-01 7.32.23

テンプレートは、ここでは 本番稼働用 を選択します。

スクリーンショット 2024-11-01 7.33.32

DB クラスター識別子は任意、マスターユーザー名はここではデフォルト、認証情報管理はセルフマネージド(現在 Limitless Database は AWS Secrets Manager がサポートされていない)、パスワードを任意に入力します。

スクリーンショット 2024-11-01 7.36.19

Limitless Database 特有の設定を行います。

DB シャードグループ識別子は任意に入力します。DB シャードグループのキャパシティ範囲は最小が 16 ACU 以上で最大が 6144 ACU 以下の値を設定します。DB シャードグループのデプロイは必要に応じて冗長性を設定しますが、ここでは「2 つのフェイルオーバーターゲットを使用したコンピューティングの冗長性」をしました。

スクリーンショット 2024-11-01 7.38.21

クラスターストレージ設定はAurora I/O 最適化を選択します。標準クラスター設定をサポートしていません。

スクリーンショット 2024-11-01 7.44.00

接続の設定は任意に行います。「2 つのフェイルオーバーターゲットを使用したコンピューティングの冗長性」を設定している場合には、DB サブネットグループで 3 AZ が含まれているものを選択します。

スクリーンショット 2024-11-01 7.51.04のコピー2

ここではパブリックアクセスはせず、VPC セキュリティグループで PostgreSQL アクセス用のものを選択します。RDS Proxy はサポートされていません。

スクリーンショット 2024-11-01 7.54.40

タグは任意に設定します。Babelfish はサポートされていません。データベース認証は Kerberos 認証がサポートされていないため「パスワード認証」か「パスワードと IAM データベース認証」を選択します。

スクリーンショット 2024-11-02 9.31.20

モニタリングではパフォーマンスインサイトと拡張モニタリングが有効化され無効化できません。

スクリーンショット 2024-11-01 8.02.03のコピー

データベースの作成 を実行します。

スクリーンショット 2024-11-01 8.04.01のコピー

DB インスタンスの作成に失敗しました。DB サブネットグループで apne1-az1, apne1-az3, apne1-az4 のサブネットを選択していましたが、おそらく apne1-az3 を使用しているためと思われます。DB シャードグループのデプロイで「単一のフェイルオーバーターゲットを使用したコンピューティングの冗長性」を選択し直します。一旦作成された DB クラスターを削除してデータベースを再度作成します。

スクリーンショット 2024-11-01 8.07.08のコピー

DB クラスターが作成されるまでしばらく(実績で100分以上)待ちます。

スクリーンショット 2024-11-01 8.19.48

起動しました。

スクリーンショット 2024-11-01 10.24.05

クラスターのアクションは以下の様になっています。

スクリーンショット 2024-11-01 10.03.20

DB シャードグループのアクションは再起動と削除だけになっています。

スクリーンショット 2024-11-01 10.03.41

ドキュメント上に記載はありませんでしたが、RDS Data API もサポートされていないようです。

スクリーンショット 2024-11-01 10.31.03

Limitless Database へのアクセス

Limitless Database へアクセスします。まずはアクセス先を確認します。

クラスターのエンドポイントを確認すると、Writer と Reader のエンドポイントが存在します。

スクリーンショット 2024-11-01 10.34.55のコピー

DB シャードグループでは以下の形式のエンドポイントが存在しているようです。

<DB シャードグループ名>.shardgrp-<ランダム>.<リージョンコード>.rds.amazonaws.com

スクリーンショット 2024-11-01 10.35.20のコピー

各々のエンドポイントの名前解決を確認すると、以下のようになっていることが分かりました。Limitless Database では、クラスターには1つの DB シャードグループしか存在できないため、DB シャードグループ エンドポイントへアクセスしても良さそうです。

Writer エンドポイント 5 IN CNAME DB シャード グループ エンドポイント
Reader エンドポイント 5 IN CNAME DB シャード グループ エンドポイント

では Limitless Database へアクセスします。ここで使用する psql のバージョンは 16.4 です。

$ psql --version
psql (PostgreSQL) 16.4
$ psql -h limitless-shard-a.shardgrp-csflnixuc5w7.ap-northeast-1.rds.amazonaws.com -U postgres -d postgres_limitless
Password for user postgres:
psql (16.4)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, compression: off)
Type "help" for help.

postgres_limitless=>

Limitless Database へのテーブル作成

ドキュメントの Examples using variables to create limitless tables を参考にテーブルを作成します。

item_id カラムと item_cat カラムで構成されるシャードキーを持つ、items という名前のシャードテーブルを作成します。

postgres_limitless=> BEGIN;
BEGIN
postgres_limitless=*> SET LOCAL rds_aurora.limitless_create_table_mode='sharded';
SET
postgres_limitless=*> SET LOCAL rds_aurora.limitless_create_table_shard_key='{"item_id", "item_cat"}';
SET
postgres_limitless=*> CREATE TABLE items(item_id int, item_cat varchar, val int, item text);
CREATE TABLE
postgres_limitless=*> COMMIT;
COMMIT

item_id カラムと item_cat カラムで構成されるシャードキーを持つ、item_description という名前のシャードテーブルを作成し、前の例の items テーブルと共存させます。

postgres_limitless=> BEGIN;
BEGIN
postgres_limitless=*> SET LOCAL rds_aurora.limitless_create_table_mode='sharded';
SET
postgres_limitless=*> SET LOCAL rds_aurora.limitless_create_table_shard_key='{"item_id", "item_cat"}';
SET
postgres_limitless=*> SET LOCAL rds_aurora.limitless_create_table_collocate_with='items';
SET
postgres_limitless=*> CREATE TABLE item_description(item_id int, item_cat varchar, color_id int);
CREATE TABLE
postgres_limitless=*> COMMIT;
COMMIT

colors という名前のリファレンステーブルを作成します。

postgres_limitless=> BEGIN;
BEGIN
postgres_limitless=*> SET LOCAL rds_aurora.limitless_create_table_mode='reference';
SET
postgres_limitless=*> CREATE TABLE colors(color_id int primary key, color varchar);
CREATE TABLE
postgres_limitless=*> COMMIT;
COMMIT

rds_aurora.limitless_create_table_mode セッション変数をリセットします。

postgres_limitless=> RESET rds_aurora.limitless_create_table_mode;
RESET

rds_aurora.limitless_tables ビューで Limitless Database のテーブルとそのタイプに関する情報が含まれます。

postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables;
 table_gid | local_oid | schema_name |    table_name    | table_status | table_type |     distribution_key
-----------+-----------+-------------+------------------+--------------+------------+--------------------------
     16003 |     17771 | public      | colors           | active       | reference  |
     16002 |     17765 | public      | item_description | active       | sharded    | HASH (item_id, item_cat)
     16001 |     17750 | public      | items            | active       | sharded    | HASH (item_id, item_cat)
(3 rows)

rds_aurora.limitless_table_collocations ビューで共存テーブルに関する情報が含まれます。

postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocations ORDER BY collocation_id;
 collocation_id | schema_name |    table_name
----------------+-------------+------------------
          16001 | public      | items
          16001 | public      | item_description
(2 rows)

rds_aurora.limitless_table_collocation_distributions ビューで各コロケーションのキー分布が含まれます。

postgres_limitless=> SELECT * FROM rds_aurora.limitless_table_collocation_distributions ORDER BY collocation_id, lower_bound;
 collocation_id | subcluster_id |     lower_bound      |     upper_bound
----------------+---------------+----------------------+---------------------
          16001 |             5 | -9223372036854775808 |                   0
          16001 |             4 |                    0 | 9223372036854775807
(2 rows)

Limitless Database へのデータ投入とクエリ

データを投入してクエリを発行してみます。

以下のように items テーブルにデータを投入します。

postgres_limitless=> INSERT INTO items (item_id, item_cat, val, item)
VALUES
  (1, 'AAA', 101, '111'),
  (2, 'BBB', 102, '222'),
  (3, 'CCC', 103, '333'),
  (4, 'DDD', 104, '444'),
  (5, 'EEE', 101, '111'),
  (6, 'FFF', 102, '222'),
  (7, 'GGG', 103, '333'),
  (8, 'HHH', 104, '444');
INSERT 0 8
postgres_limitless=> SELECT * FROM items;
 item_id | item_cat | val |  item
---------+----------+-----+--------
       3 | CCC      | 103 | 333
       5 | EEE      | 101 | 111
       2 | BBB      | 102 | 222
       8 | HHH      | 104 | 444
       1 | AAA      | 101 | 111
       6 | FFF      | 102 | 222
       7 | GGG      | 103 | 333
       4 | DDD      | 104 | 444
(8 rows)

以下のように item_description テーブルにデータを投入します。

postgres_limitless=> INSERT INTO item_description (item_id , item_cat , color_id)
VALUES
  (1, 'AAA', 201),
  (2, 'BBB', 201),
  (3, 'CCC', 202),
  (4, 'DDD', 202),
  (5, 'EEE', 201),
  (6, 'FFF', 201),
  (7, 'GGG', 202),
  (8, 'HHH', 202);
INSERT 0 8
postgres_limitless=> SELECT * FROM item_description;
 item_id | item_cat | color_id
---------+----------+----------
       3 | CCC      |      202
       5 | EEE      |      201
       2 | BBB      |      201
       8 | HHH      |      202
       1 | AAA      |      201
       6 | FFF      |      201
       7 | GGG      |      202
       4 | DDD      |      202
(8 rows)

以下のように colors テーブルにデータを投入します。

postgres_limitless=> INSERT INTO colors (color_id , color)
VALUES
  (201, 'WHITE'),
  (202, 'BLACK');
INSERT 0 2
postgres_limitless=> SELECT * FROM colors;
 color_id | color
----------+-------
      201 | WHITE
      202 | BLACK
(2 rows)

rds_aurora.limitless_explain_options セッション変数で shard_plans, single_shard_optimization を設定して、実行計画を見てみます。shard_plans を設定しているので、どこのシャードにデータがあるかを確認できます。またシャードキー全体を WHERE 句で指定しているため Single Shard Optimized となっています。

postgres_limitless=> SET rds_aurora.limitless_explain_options = shard_plans, single_shard_optimization;
SET
postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM items WHERE item_id = 1 AND item_cat = 'AAA';
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Foreign Scan
   Output: item_id, item_cat, val, item
   Remote Plans from Shard 5:
         Seq Scan on public.items_ts00155 items
           Output: items.item_id, items.item_cat, items.val, items.item
           Filter: ((items.item_id = 1) AND ((items.item_cat)::text = 'AAA'::text))
         Query Identifier: 7481820692763206803
   Remote SQL:  SELECT item_id,
     item_cat,
     val,
     item
    FROM public.items
   WHERE ((item_id = 1) AND ((item_cat)::text = 'AAA'::text))
 Query Identifier: 37372719470985300
 Single Shard Optimized
(15 rows)

実際にクエリを実行しても普通にレコードが返ってきます。

postgres_limitless=*> SELECT * FROM items WHERE item_id = 1 AND item_cat = 'AAA';
 item_id | item_cat | val |  item
---------+----------+-----+--------
       1 | AAA      |   1 | 111
(1 row)

分散トランザクション

シャードをまたがったトランザクションを実行してみます。

items テーブルで WHERE item_id = 1 AND item_cat = 'AAA' の条件ではシャードが 5 になっています。

postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM items WHERE item_id = 1 AND item_cat = 'AAA';
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Foreign Scan
   Output: item_id, item_cat, val, item
   Remote Plans from Shard 5:
・
・
・

items テーブルで WHERE item_id = AND item_cat = 'DDD' の条件ではシャードが 4 になっています。

postgres_limitless=> EXPLAIN (VERBOSE, COSTS OFF) SELECT * FROM items WHERE item_id = 4 AND item_cat = 'DDD';
                                     QUERY PLAN
------------------------------------------------------------------------------------
 Foreign Scan
   Output: item_id, item_cat, val, item
   Remote Plans from Shard 4:
・
・
・

この異なるシャードにまたがったクエリを実行してみますが、問題なく実行できます。

postgres_limitless=> BEGIN;
BEGIN
postgres_limitless=*> UPDATE items SET item = '一一一' WHERE item_id = 1 AND item_cat = 'AAA';
UPDATE 1
postgres_limitless=*> UPDATE items SET item = '四四四' WHERE item_id = 4 AND item_cat = 'DDD';
UPDATE 1
postgres_limitless=*> COMMIT;
COMMIT
``
次は分散デッドロックを確認してみます。2個のトランザクション A と B で実行してみます。

トランザクション A で `item_id = 1 AND item_cat = 'AAA'` のレコードを更新します。プロンプトはすぐに戻ってきます。

```sql
-- transaction A
postgres_limitless=> BEGIN;
BEGIN
postgres_limitless=*> UPDATE items SET item = '一一一一' WHERE item_id = 1 AND item_cat = 'AAA';
UPDATE 1

トランザクション B で item_id = 4 AND item_cat = 'DDD' のレコードを更新します。プロンプトはすぐに戻ってきます。

-- transaction B
postgres_limitless=> BEGIN;
BEGIN
postgres_limitless=*> UPDATE items SET item = '二二二二' WHERE item_id = 4 AND item_cat = 'DDD';
UPDATE 1

トランザクション A でトランザクション B と同じ item_id = 4 AND item_cat = 'DDD' のレコードを更新すると、ロックが掛かり、プロンプトが返ってこず待ちになります。

-- transaction A
postgres_limitless=*> UPDATE items SET item = '三三三三' WHERE item_id = 4 AND item_cat = 'DDD';

トランザクション B でトランザクション A と同じ item_id = 1 AND item_cat = 'AAA' のレコードを更新します。プロンプトはすぐに戻ってきます。

-- transaction B
postgres_limitless=*> UPDATE items SET item = '四四四四' WHERE item_id = 1 AND item_cat = 'AAA';
UPDATE 1

トランザクション A はプロンプトが返ってこず待ちになっていましたが、上記のトランザクション B で item_id = 1 AND item_cat = 'AAA' のレコードを更新した直後に以下のエラーを出力しました。異なるシャード間でのデッドロックを検出してロールバックされました。

ERROR:  aborting transaction participating in a distributed deadlock

トランザクション A でコミットしてもロールバックされます。

postgres_limitless=!> COMMIT;
ROLLBACK

トランザクション B でコミットします。

-- transaction B
postgres_limitless=*> COMMIT;
COMMIT

更新した結果を確認すると、正常に実行できたトランザクション B の内容が反映されています。

postgres_limitless=> SELECT * FROM items WHERE item_id = 1 AND item_cat = 'AAA';
 item_id | item_cat | val |   item
---------+----------+-----+----------
       1 | AAA      | 101 | 四四四四
(1 row)

postgres_limitless=> SELECT * FROM items WHERE item_id = 4 AND item_cat = 'DDD';
 item_id | item_cat | val |   item
---------+----------+-----+----------
       4 | DDD      | 104 | 二二二二
(1 row)

発生したエラーは CloudWatch Logs にも出力されます。

スクリーンショット 2024-11-01 19.10.17

最後に

昨年の AWS re:Invent 2023 からずっと待っていた Limitless Database がようやく GA となりました。Aurora のマネージドなシャード環境として NewSQL に生まれ変わりました。しかし NewSQL であるためデータが分散しているので、シャードごとのデータ配置などを意識する必テーブル設計が必要となっています。1 台のインスタンスでまかなえるワークロードである限りは既存の Aurora の方が効率的に動作するし、テーブル設計も用意です。

そのため無闇矢鱈と Limitless Database を使用するのではなく、各込みの大きなスケールの必要性が見えている場合に検討すべきものだと思います。とは言え超大規模環境では既存の Aurora では書き込み性能が不足する場合もあったので、必要に応じて採用を検討しましょう、ただしテーブル設計とクエリを十分に考慮することも合わせて実施してください。

NewSQL としての Aurora である Limitles Database は今後も検証していきたいと思いますので、続報をお楽しみに!

脚注
  1. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-reqs-limits.html#limitless-requirements ↩︎

  2. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-reqs-limits.html#limitless-limitations ↩︎ ↩︎

  3. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-reference.html ↩︎

  4. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/limitless-reqs-limits.html#limitless-not-supported ↩︎ ↩︎

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.