組み込み型の分析用データベースとして人気を集めるDuckDBの開発元であるDuckLabsが、AWSの子会社になると発表されました。2026年8月26日にDuckLabsの公式ブログが、翌27日にはAWSの公式ブログがそれぞれこの動きを明らかにしています。データ基盤を扱うエンジニアにとって、まず気になるのは「OSSはこれからどうなるのか」という点でしょう。

結論から言えば、DuckDBやDuckLakeといったプロジェクトはMITライセンスのオープンソースとして維持され、ロードマップやガバナンスにも変更はないと明言されています。本記事ではDuckDBの特徴から今回の発表の要点、AWSの狙い、この秋登場が予定されるDuckDB 2.0、そして実務で注視すべきポイントまでを、一次情報にもとづいて整理します。

DuckDBとはどんなデータベースなのか

DuckDBは、シングルバイナリで動作し、アプリケーションへ組み込めるOLAP（分析用途）向けのデータベースです。SQLiteのように複雑なクライアントとサーバの基盤を必要とせず、手元の環境でそのまま動く手軽さが大きな特徴だとPublickeyは伝えています。分析処理をローカルで完結させたい場面や、単一プロセスに埋め込んで使いたい場面に向いています。

AWSの説明によれば、DuckDBはアプリケーションと同じプロセス内で動くインプロセス方式を採用しています。これにより、たとえば SELECT * FROM table のような単純なクエリで重いコンパイラのオーバーヘッドを避けられ、データのやり取りがシンプルかつ高速になります。さらにベクトル化実行を備え、サブテラバイト級の分析クエリに最適化されている点も強みです。AWSは、実世界のデータクエリの90%以上がこの規模に収まるという見立てを示しており、この数字はAWS側の位置づけである点に留意してください。

対応フォーマットも幅広く、CSVやParquet、JSONに加え、MySQLやPostgreSQL、SQLiteへの接続もサポートします。Publickeyは、Amazon S3などのクラウド上に置かれた大規模なCSVやParquetファイルを読み込んで高速に分析できる点を挙げています。実際、S3上のファイルへ直接アクセスして集計する使い方は、次のような短いSQLで表現できます。パスの部分をS3上のオブジェクトへ向ければ、そのままクラウドのファイルを対象にできます。

SELECT region, SUM(amount) AS total_sales
FROM read_parquet('sales/*.parquet')
GROUP BY region
ORDER BY total_sales DESC;

DuckLabsがAWSの子会社になる発表の要点

今回の発表は、2026年8月26日のDuckLabs公式ブログと、翌27日のAWS公式ブログという2つの一次情報から確認できます。要点は、DuckDBの開発を担うDuckLabsがAWSの子会社になるというものです。開発チームはそのままAWSの一員として活動を続けます。

完了の時期については、ソース間で粒度に差がある点に注意が必要です。DuckLabs公式ブログは「early September」、すなわち2026年9月初旬に効力が生じる見込みだと明記しており、Publickeyも同様に9月初旬と記載しています。一方でAWSの日本語ブログは具体的な月を示しておらず、通常のクロージング条件が満たされ次第まもなく完了する見込みだとだけ述べています。したがって「9月初旬」はDuckLabs公式を根拠とする一方、AWS日本語版は具体月を示さず「まもなく完了見込み」としている、という併記が正確です。

買収の金額や財務条件については、3つのソースいずれも開示しておらず非公表です。契約面についてもAWSは、通常のクロージング条件を満たし次第完了する、と示すにとどめています。金額や条件を推測することはできないため、ここでは事実として非公表である点だけを押さえておきます。なお創業者であるHannes Mühleisen氏とMark Raasveldt氏は、AWS配下でも引き続きチームとオープンソースプロジェクトの技術的方向性を率いていくとAWSは伝えています。

買収後もMITライセンスとOSSガバナンスは維持される

エンジニアが最も気にするOSSの継続について、DuckLabs公式ブログは踏み込んだ表現で明言しています。DuckDB、DuckLake、Quack、そしてその他の拡張は、これまでどおりMITライセンスのフリーかつオープンソースソフトウェアとして維持される、と対象を名指しで示しています。ライセンスが変わるのではないか、という懸念に対して具体的なプロジェクト名で答えている点は、裏取りとして強い材料です。

さらに公式ブログは、プロジェクトのロードマップ、ライセンス、ガバナンスモデルに変更はないと述べています。開発体制についても、非営利団体であるDuckDB Foundationの統括のもとで継続されるとしています。AWSブログも、DuckDBのオープンソースプロジェクトは引き続きDuckLabsチームが推進し、独立したFoundationの下でオープンソースとして維持され、現在と同様にMITライセンスで利用可能だと説明しており、両ソースが一致しています。

ガバナンスの新しい仕組みとして、Foundationはステークホルダー諮問委員会（advisory board）を設置し、プロジェクトの方向性に影響を与えられるようにするとされています。これはコミュニティや利用者の声を反映させるための枠組みですが、後述するとおり構成や権限はこれから固まる段階であり、実効性は運用を見ながら判断していくことになります。

AWSがDuckLabsを取り込む狙い

AWSは今回の狙いを、DuckDBが得意とするサブテラバイト級の処理性能を、エクサバイト規模のAmazon S3や、Redshift、Athena、EMR、Glue、SageMakerといった既存サービス群と組み合わせる構想として説明しています。小回りの利く分析エンジンと大規模ストレージを結び付け、両者の間を埋めようという発想です。

直接的なユースケースとして挙げられているのが、S3上のParquetやCSV、JSONファイルをSQLで直接クエリする使い方です。ETL工程を挟まずにS3のファイルをそのまま分析することで、これまでにない性能とコスト削減を実現できるとしています。ここではあえて「ゼロETL」という言葉ではなく、ETLの工程を挟まず直接クエリできるという機能事実として捉えるのが正確です。あわせて、S3 Tablesで直接利用できるApache Iceberg機能や、データレイク内のベクトルストレージへの言及もあり、構造化データからベクトル検索までを見据えた構想がうかがえます。

既存の統合実績も示されています。AWSによれば、Amazon QuickSightではすでにDuckDBが活用されており、2025年10月以降に25億を超えるクエリを処理し、レイテンシを約30%削減したとのことです。単なる将来構想ではなく、本番サービスでの成果がある点は説得力を与えます。Publickeyはこの動きをAWSのデータストレージ戦略を強化するものと整理しています。競合他社との関係を論じる向きもありますが、ここでは他社を貶める文脈には踏み込まず、AWSの戦略的な取り込みという事実の範囲で捉えます。

この秋登場予定のDuckDB 2.0で何が変わるのか

今回の買収発表とは別に、DuckDB本体も大きな節目を迎えようとしています。DuckDB公式ブログが2026年8月17日に公開したプレビュー発表によれば、DuckDB v2.0（コードネーム Cyanoptera）はこの秋の登場が予定されています。v1.5が2026年3月に出ていることを踏まえると、比較的短い間隔での大型リリースになります。以下はいずれも正式リリース前の内容のため、プレビュー時点での見込みとして受け止めてください。

• クライアントとサーバの機能が安定化に向かい、quack拡張がv2.0でstableに昇格する見込みで、公式は「year of DuckDB as a server」と位置づけています
• スキーマレスに扱えるVARIANT型はv1.5で登場し、v2.0でエンジン全体を通してend-to-endに整備される見込みです
• BEFOREやAFTER、FOR EACH ROWやFOR EACH STATEMENTといったトリガーが本格的に提供される予定です
• 非同期I/Oがエンジン全体に導入される見込みで、I/O待ちの多い処理の効率が高まると期待されます

これらの機能は、組み込み用途にとどまらずサーバとしての運用も視野に入れた進化を示しています。ただし時期や個々の仕様は正式版で確定するため、現時点では公式のプレビュー発表を出典とした見込みとして扱うのが妥当です。

エンジニアが実務で注視すべきポイント

最後に、データ基盤を運用する立場から押さえておきたい観点を整理します。第一に、AWSサービスとの統合が今後さらに強化される可能性です。S3やS3 Tables（Iceberg）、Redshift、Athena、EMR、Glue、SageMaker、QuickSightとの組み合わせが示されましたが、具体的な製品化や提供形態はまだ発表されていません。あくまで方向性として読み取り、断定は避けるのが安全です。

第二に、OSSコアとAWS固有の統合を切り分けて評価する視点です。DuckDB本体はMITライセンスでローカルやインプロセスで動くため、ポータビリティは高く保たれています。一方で、S3 Tables連携やQuickSight統合といったAWS固有機能への依存が増えるほど、環境を移す際の移植性は下がり、ベンダーロックインの懸念が生じます。どこまでがOSSで再現でき、どこからがAWS前提なのかを意識して設計することが重要です。

第三に、諮問委員会はまだ新設の段階であり、その構成や権限、実際にどこまで方向性へ影響を与えられるかは、これからの運用を見て判断する必要があります。第四に、創業者2名の継続関与は、開発の継続性や人材面を評価するうえで前向きな材料です。統合の具体像や料金、提供時期といった未発表の事項は推測せず、注視すべきポイントとして冷静に追っていくのがよいでしょう。OSSとしての強みを保ちながらAWSの規模とどう結び付くのか、今後の続報に注目したいところです。