OCI MySQL HeatWave実践Vol1 Always Freeで分析加速を体験

1. なぜOCI MySQL HeatWaveか

1-1. 本記事のゴール

本記事は、「OCI MySQL HeatWave実践」シリーズの第1弾として、Always Free枠でMySQL HeatWaveを実際に作成し、HeatWaveクラスターによるquery acceleration・AutoML・HeatWave Lakehouseまでを無料枠のまま実践することを目的としています。

本記事を読み終えると、次の状態になることを目指しています。

• MySQL HeatWaveが、AWSのRDS for MySQLやAurora MySQLとの共通点・相違点を、AWS実務者の言葉で説明できる
• Always Free枠のMySQL HeatWaveを実際に作成し、HeatWaveクラスターを有効化できる
• Always Free枠でどこまで分析加速を実演できるか、そして有償枠でなければ手が届かない機能はどこからかを、線引きとして把握できる

なお、本記事(Vol1)では、Always Free枠での作成からHeatWaveクラスター・Lakehouseトグルの有効化、そしてquery accelerationやAutoMLの実践(§4〜§5)までを、無料枠の範囲内で扱います。

本記事の対象範囲を明確にするため、扱わない内容もあらかじめ整理しておきます。

• HeatWave GenAI(Vector Store・LLM連携)の詳細設定(Always Free枠では利用できない機能のため、別記事で扱う可能性があります)
• Terraform等のIaCによるMySQL HeatWaveのプロビジョニング
• マルチノードHeatWaveクラスターやHA構成といった、有償枠でのみ利用できる高度な構成

本記事はあくまで、Always Free枠の範囲でMySQL HeatWaveの基本的な仕様と作成手順を押さえることに絞って解説します。

1-2. 読者像

本記事は、AWSでRDS for MySQLやAurora MySQLの運用経験をお持ちの方で、OCIのMySQL HeatWaveには初めて触れる方を主な読者として想定しています。

「HeatWave」という名前から、単にクエリが速いMySQLだろうと想像して読み進めると、後述する「分析統合MySQL」という設計思想の本質を見落としがちです。特に次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• MySQL HeatWaveはRDS for MySQLに近いのか、Aurora MySQLに近いのか、それとも全く別物なのか
• 「分析も速くなる」と聞いたが、具体的にRedshiftやAthenaのような別サービスを組み合わせずに何ができるのか
• Always Free枠でどこまで試せるのか、無料のままでは何ができないのか
• 「Lakehouse」という言葉をOCIの別の記事でも見た気がするが、同じ機能なのか

なお、本記事は「OCI入門シリーズ」Vol4(コンピュート)で触れたAlways Free枠の基礎、および「OCI Autonomous Database実践」シリーズVol1で扱ったAlways Free枠特有の制約の考え方を前提知識として活用しますが、未読の方でも読み進められるよう、本記事に必要な範囲は本文中で補足します。

OCIアカウント自体をまだ持っていない方は、先にOCI入門シリーズVol1を参照し、テナンシのサインアップとホームリージョンの選択を済ませておくことをお勧めします。

1-3. MySQL HeatWaveとは — AWSのRDS for MySQL/Aurora MySQLとの違い

MySQL HeatWaveは、Oracleが開発したMySQLの高速インメモリクエリアクセラレーションエンジンを組み込んだ、フルマネージドのMySQLデータベースサービスです。公式ドキュメントには「MySQL HeatWave is the only fully managed MySQL database service that combines transactions, analytics, machine learning, and GenAI services」と明記されています。ETLによるデータ複製(ETL duplication)なしに、トランザクション処理・分析・機械学習・GenAIという複数のワークロードを1つのMySQLインスタンスの中で完結させることが最大の特徴です。

AWSのRDS for MySQLやAurora MySQLと比較する際にまず押さえておきたいのは、この「分析統合」という設計思想そのものが、RDS/Auroraには存在しない概念だという点です。RDS for MySQLやAurora MySQLは、あくまでOLTP(トランザクション処理)に最適化されたマネージドMySQLであり、分析クエリを高速化したい場合は、Amazon RedshiftやAthenaといった別サービスへデータをETLで複製し、分析基盤を別途構築するのが一般的な構成です。

一方MySQL HeatWaveは、既存のMySQLテーブルに対して「HeatWaveクラスター」と呼ばれるインメモリの分析アクセラレーション層を追加するだけで、同じデータに対してOLTPクエリと分析クエリの両方を、データを複製せずに実行できます。この方式はOracleの用語で「query acceleration」と呼ばれ、対象テーブルをHeatWaveクラスターにロードすることで、通常のMySQL(InnoDB)エンジンでは時間のかかる集計クエリを、大幅に高速化できるとされています。

この表が示す通り、MySQL HeatWaveの最大の特徴は「分析・機械学習・外部データ分析までを、追加サービスの組み合わせなしにMySQL単体で完結できる」という点です。AWSでいえば、Aurora MySQLの先にRedshift・SageMaker・Redshift Spectrumを個別に組み合わせて構築する構成が、MySQL HeatWaveでは1つのマネージドサービスの中に統合されています。この対応関係で捉えると理解しやすくなります。

具体的な場面を想定すると、この違いがイメージしやすくなります。例えば、Aurora MySQLで日次の売上データを蓄積しているチームが「月次の集計レポートを高速に出したい」と考えた場合、AWSではAurora単体だけで完結せず、AWS GlueやDMSなどでRedshiftへデータを移送するパイプラインを別途構築し、集計クエリはRedshift側で実行するのが一般的な構成です。一方MySQL HeatWaveであれば、対象テーブルをHeatWaveクラスターにロードするだけで、同じMySQLエンジン上で集計クエリを高速化でき、別サービスへのデータ移送パイプライン自体が不要になります。

この「データを動かさずに分析を速くする」という発想は、RDS/Auroraの延長線上の機能追加では出てこない設計思想です。AWSの世界観でいえば、Aurora ZeroETLによるRedshift連携が近い発想ですが、これはAuroraとRedshiftという2つの異なるサービスをデータレプリケーションでつなぐ構成であり、MySQL HeatWaveのように単一のデータベースエンジン内でOLTPと分析の両方を処理する構成とは、アーキテクチャ上の前提が異なります。

1-4. 本記事の差別化軸

MySQL HeatWaveを扱う入門記事の多くは、Always Free枠での作成手順のみを紹介して終わるか、逆に有償枠を前提とした高度な分析機能の紹介に終始しがちです。本記事は、次の3つの軸で差別化を図ります。

1. AWSエンジニア向けのRDS/Aurora MySQL対比レンズ: §1-3で見た通り、MySQL HeatWaveは「MySQLの延長線上にある高速化オプション」ではなく、そもそもRDS/Aurora MySQLには存在しない「分析統合MySQL」という設計思想を持つサービスとして捉えます。
2. HeatWaveクラスター・query acceleration・AutoML・Lakehouseの一気通貫実践: 入門記事にありがちな概要紹介の再説にとどめず、Always Free枠でHeatWaveクラスターを実際に有効化し、query acceleration・AutoMLまで実践します(§3〜§5)。
3. Always Free枠で分析加速を実測できるという無料枠の強み: 後述するように、Always Free枠はMySQL.Freeシェイプに加えて1ノードのHeatWave.Freeクラスターを含み、Lakehouseトグルも有効化できます。無料枠のままquery accelerationを体験できる点は、本シリーズの他のOCIデータベースサービスとも対照的な強みです。

「OCI Autonomous Database実践」シリーズVol1では、Always Free枠のAutonomous AI Databaseが固定リソース(1 OCPU・ストレージ20GB)のまま自動化された運用体験を提供する一方、オートスケールなどの高度な機能は有償枠に限定されるという構図を扱いました。MySQL HeatWaveのAlways Free枠は、これとは異なる強みを持ちます。単一ノードという制約の中でも、分析統合MySQLの中核であるquery acceleration・AutoML・Lakehouseという3つの機能そのものは無料のまま体験できる、という点が本記事を通じて伝えたい最大のポイントです。

1-5. 用語整理 — 「Lakehouse」は2つの別製品を指す

MySQL HeatWaveについて調べていると、「Lakehouse」という言葉が2つの異なる文脈で登場し、混同しやすいポイントになっています。本記事および本シリーズでは、混乱を避けるため次のように整理します。

• (a) MySQL HeatWave Lakehouse: 本記事が扱う機能です。公式ドキュメントには「MySQL HeatWave also includes MySQL HeatWave Lakehouse, allowing users to query data stored in object storage in a variety of file formats.」と明記されており、オブジェクトストレージ上に置かれた各種フォーマットのファイルを、MySQLから直接クエリできるようにする機能です。
• (b) Autonomous AI Lakehouse: OCIの別サービスであるAutonomous Databaseにおいて、旧称ADW(Autonomous Data Warehouse)がリブランディングされた、ワークロードタイプの名称です。「OCI Autonomous Database実践」シリーズVol1で扱った、Autonomous AI Databaseの4つのワークロードタイプ(Transaction Processing・Lakehouse・JSON・APEX)のうちの1つがこれにあたります。

この2つは、名前は同じ「Lakehouse」であっても、(a)はMySQL HeatWaveというデータベースエンジン上でオブジェクトストレージのファイルをクエリする機能、(b)はAutonomous Databaseという別のデータベースエンジンのワークロードタイプという、根本的に異なるサービス上の別機能です。ウェブ検索で「OCI Lakehouse」と調べると、どちらの製品の情報なのか判別しにくい記事も見られるため、本記事ではこの後、単に「Lakehouse」と書く場合は常に(a)のMySQL HeatWave Lakehouseを指すものとします。

1-6. 名称について — MySQL HeatWave / MySQL HeatWave Service / HeatWave MySQL

MySQL HeatWaveの名称についても、文脈によって表記が揺れるため整理しておきます。MySQL公式ドキュメントでは一貫して「MySQL HeatWave」という名称が使われていますが、OCI公式ドキュメントの一部ページ(仕様ページや作成手順ページ)では「MySQL HeatWave Service」という表記も使われています。本記事では、サービスそのものを指す場合は「MySQL HeatWave」を主表記としつつ、OCI側のドキュメント表記に言及する箇所では「MySQL HeatWave Service」という表記も併用します。また、ブログや技術記事では語順を入れ替えた「HeatWave MySQL」という表記も見られますが、これは同じサービスを指す非公式な言い換えです。検索エンジンで情報を探す際は、いずれの表記でも同じサービスを指している点を押さえておいてください。

1-7. シリーズでの位置づけ — OCI入門シリーズからの接続

本記事は、「OCI入門シリーズ」Vol4(コンピュート)が予告していなかった、MySQL HeatWaveというサービスに絞った実践シリーズの第1弾という位置づけです。OCI入門シリーズVol4では、Always Free枠のArmインスタンス(Ampere A1)の用途例としてMySQLへの言及が2文ほど登場しますが、あくまでOSSスタックの一例としての紹介にとどまり、MySQL HeatWave固有の分析統合機能には触れていませんでした。

本記事はその延長として、MySQL HeatWaveというサービス単体に踏み込んだ実践記事の第1弾に位置づけられます。OCI入門シリーズで学んだコンパートメントやVCN・プライベートサブネットの考え方は、本記事のAlways Free枠作成手順(§3)でもそのまま前提知識として使います。

本シリーズと、既存の「OCI Autonomous Database実践」シリーズとの関係も整理しておきます。両シリーズはいずれもOCIのマネージドデータベースサービスを扱いますが、対象とするデータベースエンジン(MySQL vs Oracle Database)、主要機能(query acceleration/AutoML/Lakehouse vs APEX/Database Actions)、検索されるキーワードがいずれも異なるため、独立したシリーズとして扱います。

← OCI入門 Vol4(コンピュート・Always Free枠)を読む

それでは、まずAlways Free枠のMySQL HeatWaveが具体的にどのような仕様・制約を持つのか、§2で詳しく見ていきましょう。

2. Always Free MySQL HeatWaveの仕様と制約

Always Free枠のMySQL HeatWaveは、無料である代わりにいくつかの重要な制約を持ちます。この制約を知らずに設計・検証を始めると、「HeatWaveクラスターは有償だと思っていた」「PITRができず焦った」「自動停止のタイミングが分からず不安になった」といったつまずきにつながります。本章では、公式ドキュメント(取得日: 2026年7月25日)に基づき、これらの制約を正面から整理します。

以降の各節では、まず固定リソース仕様(§2-1)とhome region限定(§2-2)というAlways Free枠全体に共通する制約を確認し、続いてバックアップ仕様(§2-3)・非対応機能一覧(§2-4)という個別機能の制約を整理します。そのうえで、無料枠と有償枠の線引き(§2-5)・自動停止/回収ルール(§2-6)・向き不向き(§2-7)・よくある誤解(§2-8)という形で、実際に手を動かす前に押さえておくべき判断材料を積み上げていきます。

2-1. 固定リソース仕様 — MySQL.Freeシェイプ・ストレージ・HeatWave.Freeクラスター

Always Free枠のMySQL HeatWave DBシステムは、次の固定リソースで提供されます。

バックアップ専用ストレージについては、Always Free Resourcesページに「An extra 50 GB of backup storage is available.」と明記されています。データ・ログ用の50GiBに加えて、バックアップ用のストレージが別枠で50GB用意されている点は、ストレージ容量を見積もる際に見落としやすいポイントです。

公式ドキュメントには、Always Freeテンプレートを選択した場合の説明として「Sets up a Always Free standalone DB system with recommended defaults. Shape, storage, and HeatWave cluster nodes are restricted.」と明記されています。DBシステムはStandalone(単一ノード)構成に固定され、シェイプ・ストレージ・HeatWaveクラスターのノード数はすべて変更できません。

DBシステム本体のシェイプはMySQL.Free固定で、ストレージは50GiB固定です。これに加えて、HeatWaveクラスターを有効にする場合はHeatWave.Freeシェイプの1ノードクラスターが利用できます。作成ダイアログでは、HeatWaveクラスターの有効・無効を切り替えられるほか、有効にした状態でMySQL HeatWave Lakehouseのトグルもあわせて有効化できます。

なお、DBシステムのバージョンについても公式ドキュメントに「The DB system is always created with the latest version. It is also upgraded to the latest version in each maintenance cycle.」と明記されています。Always Free枠では、バージョンを利用者が選択できず、常に最新版が使われ、メンテナンスサイクルごとに自動的にアップグレードされる仕様です。

AWSのRDS無料利用枠と比較すると、この「常に最新版」という仕様は対照的です。RDSの無料利用枠ではエンジンバージョンを利用者が選択でき、メジャーバージョンアップグレードのタイミングも基本的に利用者が制御できますが、MySQL HeatWaveのAlways Free枠ではバージョン管理自体がOracle側に委ねられている点に注意してください。

2-2. Home Region限定

Always Free枠のMySQL HeatWaveには、「home region限定」という制約があります。公式ドキュメントには「Each tenancy in the Commercial realm (whether free or paid) can create one Always Free DB system free-of-charge in the home region of the tenancy.」と明記されており、Always Free枠のDBシステムは、テナンシあたり1つまで、かつテナンシのホームリージョンでのみ作成できます。

この制約は、「OCI Autonomous Database実践」シリーズVol1で扱ったAutonomous AI DatabaseのAlways Free枠と同様の考え方です。ホームリージョン以外の登録リージョンをサブスクライブしていても、そちらではAlways Free枠のMySQL HeatWaveを作成できません。ご自身のテナンシのホームリージョンが分からない場合は、OCIコンソール右上のリージョンセレクターで確認できます。

なお、MySQL HeatWave自体のサービス提供(有償枠を含む一般的な利用)については、MySQL公式ドキュメントに「MySQL HeatWave is natively available on public cloud in all available OCI regions…」と明記されている通り、利用可能なすべてのOCIリージョンで提供されています。今回の制約はあくまで「Always Free枠として無料で使えるDBシステムをどのリージョンで作成できるか」という話であり、有償枠でのMySQL HeatWave自体の可用性とは区別して理解してください。

OCIでは、テナンシのホームリージョンに加えて複数の登録リージョンをサブスクライブできますが、これは「OCI Autonomous Database実践」シリーズVol1で扱ったAutonomous AI Databaseの制約と同様、Always Free枠には影響しません。後から別リージョンを追加登録しても、そちらでAlways Free枠のMySQL HeatWaveを新規に作ることはできず、あくまでホームリージョンの1インスタンスのみが無料枠の対象です。マルチリージョン構成を検討する場合、2つ目以降のインスタンスは有償枠での作成が前提になります。

2-3. バックアップ仕様 — 自動バックアップ1日保持・PITR無効

Always Free枠のバックアップ構成は、次の内容で固定されています。公式ドキュメントには「The configuration is fixed for an Always Free DB system, and you cannot change it」と明記された上で、次のように整理されています。

公式ドキュメントには「Automatic backup with 1 day retention is enabled by default.」および「Manual backup and point-in-time recovery are not available.」と明記されています。自動バックアップ自体は有効になっているものの、保持期間はわずか1日に固定され、手動バックアップとPITR(特定時点への復旧)はいずれも利用できません。

AWSのRDS無料利用枠と比較すると、RDSの無料利用枠は自動バックアップの保持期間を最大35日まで利用者が設定でき、PITRも利用可能です。一方MySQL HeatWaveのAlways Free枠は、バックアップの選択肢が大きく絞られており、「無料枠のデータは学習・検証用であり、本番相当の障害復旧を前提としていない」という位置づけが、バックアップ仕様からも読み取れます。学習で作成したテーブルやデータを長期間保護したい場合は、この1日保持という制約を踏まえた運用(重要なデータは別途エクスポートしておく等)を意識してください。

実際に起こりうる場面として、学習用にHeatWaveクラスターへロードしたテーブルを誤って削除してしまった、というケースを想定してみます。RDS無料利用枠であれば長期保持されたバックアップから特定時点に復元できる可能性がありますが、MySQL HeatWaveのAlways Free枠では、直近1日分の自動バックアップからの復元しかできません。誤操作から1日以上経ってから気づいた場合、バックアップからの復旧は期待できないため、重要なSQLスクリプトやテーブル定義は、mysqldump等で手元にもエクスポートしておく運用が安全です。

2-4. 非対応機能一覧

§2-1・§2-3で触れた内容に加えて、Always Free枠では次の機能が利用できません。公式ドキュメントの記載に基づき、一覧として整理します。

これらの非対応機能に共通するのは、いずれも「高可用性」「災害復旧」「エンタープライズサポート」「GenAI関連の高度な機能」といった、本番運用や先端機能に関わる観点であるという点です。Always Free枠は、あくまで学習・検証・PoC用途を想定した無料枠であり、本番運用の代替にはなりません。

Database ManagementやOps Insightsとの連携が利用できない点についても補足します。これらはOCI側で提供される監視・診断サービスであり、AWSでいえばCloudWatchやPerformance Insightsに近い位置づけの機能です。Always Free枠では、これらの外部監視サービスとの統合ができないため、パフォーマンスの監視はMySQL標準のステータス変数やSHOW PROCESSLIST等、MySQL自体が提供する手段に頼ります。

AWSとの対比でいうと、High Availabilityが利用できないという制約は、RDSのMulti-AZ配置が無料利用枠では使えないことに近い理解です。この点は「無料枠では高可用性構成は組めない」という考え方自体はAWS・OCIで共通しています。一方、Vector Store(GenAI関連)が非対応という制約は、MySQL HeatWaveならではの制約です。HeatWave GenAIはバージョン9.3.1以降でAlways Free枠でも一部利用できるようになっていますが、その中核機能であるVector Storeは引き続きAlways Free枠の対象外とされています。GenAI機能を本格的に検証したい場合は、有償枠への切り替えが前提となる点に注意してください。

またリードレプリカが非対応という制約についても補足しておきます。AWSのAurora MySQLでは、無料利用枠の対象外ではあるものの、リードレプリカを追加して読み取り負荷を分散する構成が一般的です。MySQL HeatWaveのAlways Free枠では、この読み取り分散という選択肢自体が存在しないため、複数人での同時アクセスが多いワークロードを想定した検証には向きません。読み取り負荷分散を検証したい場合も、有償枠へのアップグレードが前提になります。

2-5. 無料枠と有償枠の線引き — 何が無料で、何が有償か

ここまでの内容を踏まえ、Always Free枠でできることと、有償枠が必要になることの境界線を整理します。

この線引きから分かる通り、Always Free枠は「単一ノードの範囲内であれば、query acceleration・AutoML・Lakehouseという分析統合MySQLの中核機能そのものは、無料のまま体験できる」という設計になっています。無料枠であっても分析機能自体は利用でき、あくまでノード数・可用性・バックアップ・GenAIの高度機能といった「スケールと本番運用に関わる部分」が有償枠との境界線になっている点が、他のOCIマネージドデータベースサービスと比べても特徴的です。

この線引きの考え方は、「機能そのものを制限する」のではなく「スケールと冗長性を制限する」というOracleの無料枠設計の一貫した方針を反映しています。学習目的であれば、単一ノードのままquery acceleration・AutoML・Lakehouseのすべてを試すことができ、実務での採用を検討する段階になって初めて、ノード数やHA構成といったスケール面での有償枠への切り替えを検討すればよい、という段階的なアプローチが取りやすい設計だといえます。

2-6. 自動停止・回収ルールについて — 本記事執筆時点で未文書化

「OCI Autonomous Database実践」シリーズVol1では、Always Free枠のAutonomous AI Databaseについて、7日間非アクティブで自動停止、停止が累積90日続くと削除される可能性があるという公式ルールを確認しました。MySQL HeatWaveのAlways Free枠についても同様のルールがあるのではと推測したくなりますが、本記事執筆時点(2026年7月25日)で確認できたOCI公式ドキュメント(DBシステム作成ページ・Always Free Resourcesページ・MySQL HeatWave Service仕様ページ)には、MySQL HeatWaveのAlways Free DBシステムに対する自動停止・自動削除ルールの具体的な記載は見当たりませんでした。

Always Free Resourcesページには、コンピュートインスタンス(Always Free Compute)に対する「Idle Always Free compute instances may be reclaimed by Oracle.」という一般的なアイドルリソース回収ポリシーが明記されています。対象となる基準は、7日間においてCPU使用率(95パーセンタイル値)・ネットワーク使用率・メモリ使用率(A1シェイプのみ)がいずれも20%未満の場合です。ただしこれはコンピュートインスタンスに関する記述であり、MySQL HeatWaveを含むデータベース系Always Freeリソースに対して同様のルールが適用されるとは明記されていません。

この点は、Autonomous AI Databaseの7日/90日ルールをそのまま本記事に転用しないよう、特に注意が必要な箇所です。MySQL HeatWaveのAlways Free枠を長期間使い続ける予定がある場合は、本記事の情報を鵜呑みにせず、OCIコンソールの通知やOCI公式ドキュメントの最新版で、ご自身のテナンシに適用されるポリシーを都度確認することをお勧めします。本記事では、確認できた事実(自動停止・削除に関する明記が見当たらないこと)のみを正確に記載するにとどめます。

AWSのRDS無料利用枠と比較すると、この「ルールの有無」自体が対照的です。RDSの無料利用枠は、新規アカウント登録から12か月間という明確な期限が定められており、期限が切れると自動的に課金対象へ切り替わります。一方MySQL HeatWaveのAlways Free枠は期限の定めがなく、無期限に使い続けられる建前ですが、非アクティブ時の扱いについては本記事執筆時点で公式ドキュメント上の明記が見当たらないという、いわば「グレーな余白」が残っています。「無料=何もしなくても未来永劫使える」と楽観視せず、Oracleの公式アナウンスやコンソール通知を継続的にウォッチする姿勢が、Always Free枠全般を扱う上での実務的な心構えといえます。

2-7. Always Free枠が向いている用途・向いていない用途

ここまで整理してきた制約を踏まえ、Always Free枠が向いている用途と向いていない用途を整理します。

この向き不向きの整理から分かる通り、Always Free枠は「MySQL HeatWaveというサービスの分析統合という中核体験を無料で試す」ことに主眼を置いた無料枠であり、本番運用の代替にはなりません。この前提を理解した上で、§3では実際にAlways Free枠のDBシステムを作成していきます。

2-8. よくある誤解 — AWS実務者が陥りやすいポイント

ここまでの内容を踏まえ、AWS実務者がAlways Free枠のMySQL HeatWaveについて抱きやすい誤解を整理します。

誤解1: HeatWaveクラスターは有償オプションで、Always Freeでは触れない

「HeatWave」という名前が有償の高機能オプションのように聞こえるため、Always Free枠では利用できないと考えてしまうケースです。§2-1で見た通り、Always Free枠には1ノードのHeatWave.Freeクラスターが含まれており、query acceleration自体は無料枠のまま体験できます。

誤解2: 「Lakehouse」はAutonomous Databaseの機能であり、MySQLには関係ない

§1-5で整理した通り、「Lakehouse」という名称はAutonomous AI DatabaseのワークロードタイプとMySQL HeatWave Lakehouseの2つで使われています。MySQL HeatWaveにも同名の機能が存在するため、検索の際はどちらの製品を指しているのか注意してください。

誤解3: 無料である以上、放置していても永続的に残り続ける

Autonomous AI Databaseの7日/90日ルールを知っている方ほど、MySQL HeatWaveにも同様のルールがあるはずだと考えがちですが、§2-6で見た通り、本記事執筆時点の公式ドキュメントにはMySQL HeatWave特有の自動停止・削除ルールの明記が見当たりません。だからといって「絶対に消えない」という保証があるわけでもなく、確認できていない事実を過度に安心材料として扱わないことが重要です。

誤解4: RDSと同じ感覚でパブリックサブネットに配置できる

AWSのRDSは、パブリックサブネットへの配置も選択肢として用意されていますが、§3で見る通り、MySQL HeatWaveのDBシステムはプライベートサブネットへの配置が前提です。パブリックサブネットを選ぼうとしても、作成ダイアログの選択肢に表示されないか、選択できても意図通りに機能しない可能性があります。

これら4つの誤解に共通するのは、「HeatWaveという名前の響き、あるいはAutonomous Databaseなど別サービスで得た知識を、そのままMySQL HeatWaveのAlways Free枠に当てはめてしまう」という点です。本記事のここまでの内容を踏まえておけば、これらの誤解にはまることなく、次章のハンズオンへ進めるはずです。

2-9. 作成前チェックリスト

§3のハンズオンへ進む前に、本章で整理した制約を踏まえて確認しておきたい項目を整理します。

• 対象テナンシのホームリージョンを確認したか(§2-2)
• テナンシ内に既存のAlways Free MySQL DBシステムが存在しないか確認したか(1テナンシにつき1つまで、§2-1)
• PITRや手動バックアップが必要な検証ではないことを確認したか(§2-3)
• High Availability・リードレプリカ・Vector Storeが必要な検証ではないことを確認したか(§2-4)
• 自動停止・削除ルールが本記事執筆時点で未文書化であることを理解し、長期利用時は公式情報を都度確認する前提を持てたか(§2-6)
• DBシステムを配置するVCN・プライベートサブネットを準備済みか(§3で必要になります)
• リードレプリカによる読み取り分散が必要な検証ではないことを確認したか(§2-4)

これらの項目にすべて問題がなければ、Always Free枠でのMySQL HeatWave作成に進む準備が整っています。

次章では、実際にOCIコンソールを操作してDBシステムを作成し、HeatWaveクラスターとLakehouseトグルを有効化する手順を見ていきます。

準備が整ったら、さっそく§3のハンズオンへ進みましょう。

3. Always Free MySQL HeatWave作成ハンズオン

本章では、§2で確認した制約を踏まえた上で、実際にOCIコンソールを操作してAlways Free枠のMySQL HeatWave DBシステムを作成する手順を解説します。本章の手順は、OCI公式ドキュメントに記載されたコンソール操作フローを踏まえています。実際の画面レイアウトはOCIのアップデートにより変わる場合があるため、項目名や配置が本記事と異なる場合は、公式ドキュメントもあわせてご確認ください。

3-1. 作成前に準備するもの

作成を始める前に、次の項目を準備・確認しておきます。

• OCIアカウント(テナンシ)とホームリージョン(§2-2参照)
• リソースを作成するコンパートメント、VCN、プライベートサブネット(MySQL DBシステムはプライベートサブネットへの配置が前提です)
• テナンシ内に既存のAlways Free MySQL DBシステムが存在しないこと(§2-1参照)
• 管理者ユーザー名とパスワード(予約済みユーザー名は使用不可、強固なパスワードを用意してください)

3-2. DBシステム作成ダイアログを開く

OCIコンソールにサインインしたら、左側のナビゲーションメニューから「Databases」配下の「MySQL HeatWave」を選択します。画面右上のリージョンセレクターで対象リージョン(ホームリージョン)を選択し、リソース一覧画面のコンパートメントセレクターから、§3-1で準備したコンパートメントを選択します。

対象リージョン・コンパートメントを選択した状態で、画面上部の「Create DB System」ボタンをクリックすると、作成ダイアログが開きます。

3-3. Always Freeテンプレートの選択と基本情報

作成ダイアログでは、まず「Select a template」のセクションで「Always Free」テンプレートを選択します。公式ドキュメントには、このテンプレートについて「Sets up a Always Free standalone DB system with recommended defaults. Shape, storage, and HeatWave cluster nodes are restricted.」と説明されています。

続いて、DBシステムの基本情報を入力します。

• Compartment: §3-1で準備したコンパートメントを選択します
• Display name: コンソール上に表示される名前を入力します(例: mysql-heatwave-vol1-alwaysfree)。一意である必要はなく、OCID(Oracle Cloud Identifier)がシステムを一意に識別します
• Description: 任意でシステムの説明を入力します

Always Freeテンプレートを選択した時点で、システムタイプは自動的に「Standalone」に固定されます。公式ドキュメントには「High availability is not available in Always Free DB system.」と明記されており、Always Free枠ではHA構成のオプション自体が選択できません。

3-4. 管理者認証情報とネットワーキングの設定

「Create administrator credentials」のセクションでは、管理者ユーザー名とパスワードを設定します。ユーザー名には、MySQLの予約済みユーザー名(rootなど)は使用できません。パスワードは、確認用の入力欄とあわせて2回入力します。

「Configure networking」のセクションでは、DBシステムを配置するVCNとプライベートサブネットを選択します。MySQL HeatWaveのDBシステムはプライベートサブネットへの配置が前提となっており、パブリックサブネットは選択できません。あわせて、必要に応じてネットワークセキュリティグループ(NSG、最大5個まで)を設定できます。

「Configure placement」のセクションでは、アベイラビリティドメインが自動的に選択されます。公式ドキュメントによれば、MySQL.Freeシェイプのサービス制限を満たすアベイラビリティドメインが自動選択されます。フォルトドメインについても、Oracle側が自動的に割り当てます。利用者が明示的に選択する項目ではありません。

3-5. HeatWaveクラスターとLakehouseトグルの設定

DBシステムの基本設定に続けて、「Configure hardware」のセクションでシェイプとストレージを確認します。Always Freeテンプレートを選択している場合、DBシステムシェイプはMySQL.Free、ストレージは50GiBに固定表示され、変更できません。

続いて、「Add a HeatWave cluster」のトグルを確認します。デフォルトで有効になっており、無効にするとHeatWaveクラスターを持たないDBシステムとして作成されます。本記事では、query accelerationを実践するため、有効なままにします。

HeatWaveクラスターが有効な状態で「Edit」リンクを選択すると、クラスター構成の詳細を確認・変更できます。Always Free枠では、クラスターシェイプはHeatWave.Free、ノード数は1ノードに固定されています。あわせて、「Configure HeatWave cluster」から「MySQL HeatWave Lakehouse」のチェックボックスを選択することで、Lakehouse機能(オブジェクトストレージ上のファイルをクエリする機能)を有効化できます。本記事では、§5でLakehouseを実践する前提として、このチェックボックスを有効にしたまま進めます。

3-6. 作成の実行とプロビジョニング完了の確認

すべての項目を入力・確認し終えたら、ダイアログ下部の「Create」ボタンをクリックします。これにより、Always Free枠のMySQL HeatWave DBシステムの作成が開始されます。

作成ボタンをクリックすると、コンソールはDBシステムの詳細ページへ遷移します。この時点で、画面上のLifecycle State(ライフサイクル状態)は「Creating」と表示されます。

プロビジョニングが完了するまで数分程度待つと、Lifecycle Stateが「Active」に変わります。この状態になれば、DBシステム本体の作成は完了です。HeatWaveクラスターを追加している場合は、DBシステムがActiveになった後、HeatWaveクラスター側の状態も別途「Active」に変わるまで確認してください。詳細ページには、作成時に指定したDisplay name・Shape・ストレージ・HeatWaveクラスターの設定状況・OCIDなどの情報が表示されます。

なお、コンソールを使わずCLIから作成する場合は、次のようにMySQL.Freeシェイプを指定してDBシステムを作成できます。公式ドキュメントには「This does not create a HeatWave cluster together with the DB system, you can add a HeatWave cluster to the DB system after it has been created successfully.」と明記されており、CLIでの作成時はHeatWaveクラスターを同時に作成できないため、DBシステム作成後に別途HeatWaveクラスターを追加する操作が必要です。

oci mysql db-system create \
  --compartment-id <compartment-ocid> \
  --shape-name MySQL.Free \
  --subnet-id <subnet-ocid> \
  --availability-domain <AD-name> \
  --admin-username <admin-username> \
  --admin-password <admin-password> \
  --display-name mysql-heatwave-vol1-alwaysfree

Always Free枠のMySQL HeatWave DBシステムが作成できました。続く§4・§5では、実際にHeatWaveクラスターへテーブルをロードし、query accelerationとAutoMLの効果を実測する手順を見ていきます。

4. HeatWaveでのin-database分析実践

§3でActive状態になったAlways Free枠のDBシステムを使って、本章ではHeatWaveクラスターへテーブルをロードし、query acceleration(分析クエリの高速化)を実際に確認します。§1-3で整理した「分析統合MySQL」という設計思想を、操作を通じて体感していきましょう。

4-1. Auto Parallel Loadの概要 — なぜAWSにはこの発想がないか

MySQL HeatWaveでテーブルをHeatWaveクラスターへロードする際は、sysスキーマに用意されたHEATWAVE_LOADストアドプロシージャ(通称Auto Parallel Load)を使うのが標準的な方法です。公式ドキュメントには「The HeatWave Auto Parallel Load utility automates the process of preparing and loading tables into HeatWave and loads data using an optimized number of parallel load threads.」と明記されており、対象テーブルの選定・データ型の互換性チェック・並列ロードのスレッド数最適化までを、Auto Parallel Loadが自動的に行います。

AWSの世界観に置き換えると、この操作に相当するのは「Aurora MySQLからRedshiftへ、AWS GlueやDMSでETLパイプラインを構築してデータを複製する」という一連の作業です。MySQL HeatWaveでは、この複製先の分析基盤そのものが不要で、同じMySQLインスタンス内のHeatWaveクラスターへ、SQLのCALL文1つでロードが完結します。

Auto Parallel Loadはmodeオプションで動作を切り替えられ、dryrun(実際にはロードせず、ロード計画とレポートのみ生成)、normal(実際にロードを実行、既定値)、validation(事前作成済みテーブルの検証)の3種類が用意されています。実行結果はsys.heatwave_autopilot_reportテーブルに記録され、ロード対象外になった列や警告もここで確認できます。

4-2. 分析対象テーブルの準備

Auto Parallel Loadを試すため、まず簡単なサンプルテーブルを用意します。ここでは、ECサイトの注文データを模したテーブルを例に進めます。

CREATE DATABASE IF NOT EXISTS heatwave_demo;
USE heatwave_demo;

CREATE TABLE ec_orders (
  order_id  INT AUTO_INCREMENT PRIMARY KEY,
  product_category VARCHAR(30) NOT NULL,
  amount INT NOT NULL,
  order_dateDATE NOT NULL
);

INSERT INTO ec_orders (product_category, amount, order_date) VALUES
  ('家電', 12000, '2026-06-01'), ('書籍', 2400, '2026-06-01'),
  ('家電', 8800, '2026-06-02'), ('食品', 1500, '2026-06-02'),
  ('書籍', 3200, '2026-06-03'), ('家電', 21000, '2026-06-03'),
  ('食品', 980, '2026-06-04'), ('書籍', 1800, '2026-06-04'),
  ('家電', 15600, '2026-06-05'), ('食品', 2200, '2026-06-05'),
  ('書籍', 2900, '2026-06-06'), ('家電', 9400, '2026-06-06');

実務では数百万行規模のテーブルを対象にすることが多いですが、本記事ではAlways Free枠での操作感を掴むことを目的とし、小規模なサンプルデータで進めます。§4-5で、小規模データ特有の注意点にも触れます。

4-3. Auto Parallel Loadの実行 — dryrunでの事前確認

いきなり本番ロードを実行する前に、dryrunモードでロード計画を確認します。

CALL sys.heatwave_load(JSON_ARRAY("heatwave_demo"), JSON_OBJECT("mode", "dryrun"));

SELECT log FROM sys.heatwave_autopilot_report WHERE stage = "VERIFICATION";

dryrunモードでは、実際にはHeatWaveクラスターへデータをロードせず、ロード対象テーブル・推定メモリ使用量・データ型の互換性チェック結果などを含むレポートのみを生成します。公式ドキュメントには「In dryrun mode, Auto Parallel Load sends the load script to the heatwave_autopilot_report table only. It does not load data into HeatWave.」と明記されており、本番ロード前の安全な確認手段として位置づけられています。

4-4. 本番ロードの実行とHeatWaveクラスターへの格納確認

dryrunの結果に問題がなければ、modeを省略(既定値のnormal)して本番ロードを実行します。

CALL sys.heatwave_load(JSON_ARRAY("heatwave_demo"), NULL);

ロードが完了すると、対象テーブルのセカンダリエンジンがRAPIDに設定され、HeatWaveクラスターのメモリ上にデータが展開された状態になります。ロード後の状態は、次のSQLでテーブル定義を確認することで把握できます。

SHOW CREATE TABLE ec_orders\G

SECONDARY_ENGINE=RAPIDという設定がテーブル定義に含まれていれば、HeatWaveクラスターへのロードが成功しています。ロード中にエラーや警告が出た場合は、§4-3と同様にsys.heatwave_autopilot_reportを確認してください。

4-5. query accelerationの実践 — EXPLAINでの確認

HeatWaveクラスターへのロードが完了したら、実際に集計クエリを実行してquery accelerationを確認します。

SELECT product_category, SUM(amount) AS total_amount, COUNT(*) AS order_count
FROM ec_orders
GROUP BY product_category
ORDER BY total_amount DESC;

このクエリがHeatWaveクラスターにオフロードされたかどうかは、EXPLAINで確認できます。公式ドキュメントには「If a query is supported by MySQL HeatWave, the Extra column of EXPLAIN output includes “Using secondary engine RAPID”.」と明記されており、EXPLAIN結果のExtra列にこの文字列が表示されれば、通常のInnoDBエンジンではなくHeatWaveエンジン側でクエリが実行されたことを意味します。

EXPLAIN SELECT product_category, SUM(amount) AS total_amount, COUNT(*) AS order_count
FROM ec_orders
GROUP BY product_category
ORDER BY total_amount DESC;

ここで1点、小規模データ特有の注意点があります。MySQLのオプティマイザは、クエリの推定コストがsecondary_engine_cost_thresholdシステム変数の閾値を超えない場合、HeatWaveへオフロードせず通常のInnoDBエンジンで実行します。本記事のサンプルのように数十行程度のテーブルでは、この閾値を下回りオフロードされないケースがあります。動作確認のためにオフロードを強制したい場合は、次のようにセッション変数use_secondary_engineをFORCEDに設定します。

SET SESSION use_secondary_engine = FORCED;

FORCEDに設定すると、HeatWaveへオフロードできないクエリはエラーになる一方、オフロード可能なクエリは必ずHeatWaveエンジン側で実行されます。実務で大規模なテーブルを扱う場合は、オプティマイザの既定判断(use_secondary_engine = ON)に任せるのが基本ですが、少量データでの動作確認時にはこのFORCED設定が有効です。

4-6. RDS/Auroraにはない「MySQL内蔵の分析アクセラレータ」という差別化ポイント

§4-1〜§4-5を通じて確認した通り、MySQL HeatWaveでは「テーブルをHeatWaveクラスターへロードする」「EXPLAINでオフロードを確認する」という2つの操作だけで、通常のMySQLエンジンでは時間のかかる集計クエリを高速化できます。AWSのRDS for MySQLやAurora MySQLでは、この種の分析アクセラレータ自体が存在しないため、同様の高速化を実現するにはRedshiftやAthenaへのデータ移送パイプラインを別途構築する必要があります。

この「データベースエンジン自体に分析アクセラレータが内蔵されている」という点こそが、§1-4で整理した本記事の差別化軸2の核心です。次章では、同じHeatWaveクラスターを使ってAutoMLによる予測モデル構築と、Lakehouseによるオブジェクトストレージ上データの直接クエリを実践します。

5. AutoML・Lakehouseの実践

§4ではHeatWaveクラスターによるquery accelerationを確認しました。本章では、同じHeatWaveクラスターの機能として、AutoMLによる予測モデル構築とLakehouseによるオブジェクトストレージ上データの直接クエリを実践します。いずれも§1-4で整理した差別化軸2・3の中核にあたる機能です。

5-1. HeatWave AutoMLの概要 — RDS+SageMakerとの対比

MySQL HeatWave AutoMLは、SQLのCALL文だけで機械学習モデルの訓練・評価・推論までを行える機能です。公式ドキュメントには「With HeatWave AutoML and a set of training data, you can train a predictive machine learning model with a single call to the ML_TRAIN SQL routine.」と明記されており、ML_TRAINルーチンへの1回の呼び出しで、特徴量選定・アルゴリズム選択・ハイパーパラメータ調整までが自動的に行われます。タスクの種類は、カテゴリを予測するclassification(既定値)、連続値を予測するregression、日時列を使ったforecastingの3種類から選択できます。

AWSでAurora MySQLのデータから予測モデルを構築しようとすると、SageMakerへデータをエクスポートし、特徴量エンジニアリングやアルゴリズム選定を別途行うワークフローが必要です。MySQL HeatWave AutoMLは、この一連の作業をデータベースエンジン内のSQLだけで完結させる点が特徴です。

5-2. モデル訓練の実践 — ML_TRAINの実行

AutoMLを試すには、まず訓練用のテーブルを用意します。公式のHeatWave AutoML Quickstart(取得日: 2026年7月25日)では、Iris(あやめ)の花弁・がく片の計測値から品種を分類する、教師あり学習のサンプルデータセットが提供されています。具体的な訓練データの準備手順は公式Quickstartに譲り、本記事ではモデル訓練から予測までの操作の流れを追います。

SET @model = 'ec_category_model';

CALL sys.ML_TRAIN('ml_data.iris_train', 'class',
 JSON_OBJECT('task', 'classification'), @model);

ML_TRAINは、訓練対象テーブル(schema.table形式)・目的変数となる列名・タスク設定・モデルハンドルを格納するセッション変数を引数に取ります。訓練が完了すると、モデルはML_SCHEMA_<ユーザー名>.MODEL_CATALOGテーブルに登録され、次のSQLで確認できます。

SELECT model_id, model_handle, train_table_name
FROM ML_SCHEMA_user1.MODEL_CATALOG
WHERE model_handle = 'ec_category_model';

5-3. 予測の実践 — ML_PREDICT_ROW / ML_PREDICT_TABLE

訓練したモデルで予測するには、まずML_MODEL_LOADでモデルをメモリへロードします。

CALL sys.ML_MODEL_LOAD(@model, NULL);

1件のデータに対する予測はML_PREDICT_ROW、テーブル単位のバッチ予測はML_PREDICT_TABLEで行います。

SET @row_input = JSON_OBJECT(
  "sepal length", 7.3, "sepal width", 2.9,
  "petal length", 6.3, "petal width", 1.8);

SELECT sys.ML_PREDICT_ROW(@row_input, @model, NULL)\G

CALL sys.ML_PREDICT_TABLE('ml_data.iris_test', @model,
 'ml_data.iris_predictions', NULL);

公式ドキュメントに掲載されている実行例では、ML_PREDICT_ROWの戻り値としてJSON形式で予測クラスと各クラスの確率が返ります(実際の値は訓練データや実行環境によって変動します)。バッチ予測のML_PREDICT_TABLEは、入力テーブルと同じ行数の出力テーブルを自動生成し、各行に予測結果と確率を付与します。

5-4. Always Free枠でAutoMLを完結させる範囲

Always Free枠でAutoMLがそもそも使えるのか、という点は本記事の差別化軸3に関わる重要な確認事項です。OCI公式ドキュメントのAlways Free Service節(取得日: 2026年7月25日)には「MySQL HeatWave AutoML and MySQL HeatWave Lakehouse are supported.」と明記されており、Always Free枠のHeatWave.Freeクラスター(1ノード)上でも、AutoMLとLakehouseはいずれも制限された機能ではなく、正式にサポートされています。

ただし、1ノードのHeatWave.Freeクラスターというメモリ容量の制約は存在するため、訓練データが極端に大規模な場合はクラスターのメモリ上限に収まらない可能性があります。本記事のような学習・検証目的のデータ規模であれば、Always Free枠のままAutoMLの操作感を一通り体験できます。

5-5. HeatWave Lakehouseの概要 — Redshift Spectrumとの対比

HeatWave Lakehouseは、オブジェクトストレージ上に置かれたファイルを、MySQLへロードすることなく直接クエリできる機能です。公式ドキュメントには「MySQL HeatWave Lakehouse… allowing users to query data stored in object storage in a variety of file formats.」と明記されています。対象データはlakehouseストレージエンジンを主エンジンとする「外部テーブル(external table)」として定義され、HeatWaveクラスターのメモリへロードすることで、通常のHeatWaveテーブルと同様にquery accelerationの対象にできます。

AWSでいえば、Redshift SpectrumやAthenaを使ってS3上のファイルを直接クエリする構成に近い発想です。ただしAWSの場合、この機能はRedshiftやAthenaという分析専用サービス側の機能であるのに対し、MySQL HeatWaveでは同じMySQLエンジンの機能としてLakehouseが提供され、§4で実践したquery accelerationの仕組みをそのまま外部テーブルにも適用できる点が異なります。

5-6. Lakehouse外部テーブルの作成実践 — PARを使ったアクセス

Lakehouse外部テーブルからOCI Object Storageへアクセスするには、URI・Resource Principal・Pre-Authenticated Request(PAR)の3種類の認証方式が用意されています。本記事では、個人の学習用途で手軽に試せるPARを使う方法を紹介します。

まず、OCIコンソールでバケットを作成し、サンプルのCSVファイル(例: sample_orders.csv)をアップロードします。続いてバケットの詳細画面から、読み取り専用のPre-Authenticated Requestを作成します。個別のオブジェクトを対象にする場合は「Permit Object Reads」のみ、バケット・プレフィックス単位で複数ファイルを対象にする場合は「Permit Object Reads」に加えて「Enable Object Listing」を有効にします。

PARのURLが発行できたら、次のSQLで外部テーブルを作成します。

CREATE EXTERNAL TABLE lakehouse_orders (
  order_id INT,
  product_category VARCHAR(30),
  amount INT
)
FILE_FORMAT = (FORMAT csv HEADER ON FIELDS TERMINATED BY ',')
FILES = (URL = 'https://objectstorage.ap-tokyo-1.oraclecloud.com/p/<PARトークン>/n/<namespace>/b/<bucket-name>/o/'
FILE_NAME = 'sample_orders.csv');

外部テーブルの作成後は、§4と同じAuto Parallel Loadの仕組みでHeatWaveクラスターのメモリへロードします。

CALL sys.heatwave_load(JSON_ARRAY("heatwave_demo"), JSON_OBJECT("refresh_external_tables", "true"));

ロード後は、通常のInnoDBテーブルと同様にSELECT文でクエリでき、§4-5と同じ要領でEXPLAINによりHeatWaveへのオフロードを確認できます。PARを使う際は、読み取り専用のPARのみを発行し、有効期限をデータ取り込み計画に合わせて短めに設定した上で、URLを公開の場に残さないよう注意してください。より高いセキュリティを求める場合は、公式ドキュメントでもResource Principalの利用が推奨されています。

5-7. Always Free枠でLakehouseまで無料で完結するという強み

§5-4で確認した通り、AutoMLとLakehouseはいずれもAlways Free枠で公式にサポートされています。「OCI Autonomous Database実践」シリーズVol1で扱ったAlways Free枠のAutonomous AI Databaseが、固定リソース(1 OCPU・ストレージ20GB)の範囲内で自動化された運用体験を提供する一方、オートスケールなどのスケール面の機能は有償枠に限定されていたのとは対照的に、MySQL HeatWaveのAlways Free枠は、query acceleration・AutoML・Lakehouseという分析統合MySQLの中核機能そのものを、単一ノードの制約内で無料のまま体験できます。この点が、§1-4で整理した差別化軸3の実践的な裏付けです。

6. まとめ・落とし穴チェックリスト

本章では、§1〜§5で解説してきた内容を振り返り、Always Free枠のMySQL HeatWaveを扱う際に陥りやすい落とし穴を、チェックリスト形式で整理します。

§1では、MySQL HeatWaveがRDS/Auroraの延長線上にある高速化オプションではなく、トランザクション・分析・機械学習を1つのMySQLエンジンで完結させる「分析統合MySQL」という設計思想を持つサービスであることを確認しました。§2では、Always Free枠特有の固定リソース仕様・home region限定・バックアップ制約・非対応機能・自動停止ルールの未文書化という制約を整理しました。§3では実際にAlways Free枠のDBシステムを作成し、§4ではAuto Parallel Loadによるquery accelerationを、§5ではAutoMLとLakehouseの実践を、いずれもAlways Free枠のまま行いました。

Always Free枠のMySQL HeatWaveは、単一ノードという制約の中でも、query acceleration・AutoML・Lakehouseという分析統合MySQLの中核機能そのものを無料で体験できる、学習・検証用途として強力な選択肢です。一方で、「Lakehouse」という名称の混同や、自動停止ルールが未文書化であるという「グレーな余白」など、AWSでの経験則だけでは気づきにくい落とし穴も存在します。まずはAlways Free枠でMySQL HeatWaveの操作感を掴み、大規模データや高可用性構成が必要になった段階で、マルチノードのHeatWaveクラスターや有償枠のDBシステムへの移行を検討してみてください。