MySQLレプリケーション環境でAUTO_INCREMENT列を追加するマイグレーションを実施したところ、ソースとレプリカでIDの割り当て順序が異なる事態が発生。binlog_formatがMIXEDだったため、5つの関連テーブルはSTATEMENT形式で正しくレプリカ側のIDを参照できたが、AUTO_INCREMENT関連の操作はMySQLがROW形式に自動切り替えするため、1つのテーブルだけソース側のIDがそのままコピーされ、レプリカ上では全く別の行を指す不整合が発生した
UCLA発の新しいクエリ言語Prelaを紹介する記事。全ての関係を2列の二項関係に分解し、関数合成のようにselect・where・&演算子を組み合わせることで、SQLより大幅に短いクエリを書ける仕組みをPythonでのトイ実装を通じて解説している。
Turso Cloudが早期プレビューとしてMVCCベースの並行書き込み(BEGIN CONCURRENT)を提供開始。SQLiteの単一ライター制約を回避し、行レベルでの競合検出によりチェックアウト処理や高頻度データ取り込みなどのワークロードでSQLite比最大4倍のスループットを実現する。tursodbデータベースの作成とダッシュボードでの有効化が必要で、TypeScript/Python/Rustでの実装例と競合リトライ、ホットロー問題への対処法を解説している。
Amazon Aurora MySQL 3.13.0（MySQL 8.0.45互換）がGAになったことを受け、Aurora Serverless v2の最小構成でRDS Data APIを有効化したクラスターを作成し、MySQLクライアント不要でバージョン情報を取得する検証を実施。あわせてリリースカレンダーを整理し、サポート期間重視ならLTSの3.10系、最新修正重視なら3.13を選ぶ指針を示している。
BigQueryの変更履歴関数APPENDS/CHANGESがGAとなり、タスク管理テーブルでINSERT・UPDATE・DELETEを実行して両関数の挙動を検証した記事。APPENDSは追加行のみをINSERT当時の値で返し、CHANGESはenable_change_history=TRUE設定が必要な代わりにUPDATE・DELETEも_CHANGE_TYPEと_CHANGE_IS_FOR_UPDATEフラグ付きで追跡できる。Time travel（全体スナップショット）との使い分け指針も整理している。
Aurora DSQLが外部キー制約に対応し、psqlとPythonから並行トランザクションの競合挙動を検証した記事。既存テーブルへの制約追加はNOT VALID必須でASYNC VALIDATEによる非同期検証が必要、また子行なし親行の削除と子行挿入が競合した場合はロック待ちではなくSQLSTATE 40001のシリアライゼーションエラーで後発コミットが失敗する点をpsycopgでの実装例とともに確認している。
TurboKVはRust製の組み込み型キーバリューストア。非同期API、アトミックなバッチ書き込み、順序付きレンジスキャン、fast/durable/paranoidの3段階の永続性設定、圧縮、バックグラウンドコンパクションを備える。fjallやredbとのベンチマークを掲載し、特にdurableモードでの高スループットを主張している。
APIマネジメント企業SensediaがPrometheus互換のメトリクス監視基盤としてVictoriaMetricsを採用した事例。15日間のメトリクス保存・スケーラビリティ・高可用性という要件のもと、PoCを経て2020年のブラックフライデー直前に本番導入し、監視スタックの不安定化なく過去最大のメトリクス量を処理した。既存のGrafanaダッシュボードやPromQLをそのまま流用できる互換性、少ないハードウェアリソースでの高効率な動作、Docker/Helmでの導入容易性、TLSとvmauthによる認証機能が採用理由。
ロボティクス企業Groove Xが、PrometheusおよびThanosで直面したレイテンシ課題を解決するためVictoriaMetricsへ移行した事例。並行運用による検証を経て、性能・運用容易性・メトリクスの正確性を評価し採用を決定した。
ドイツのAI研究機関DFKIが、Slurmクラスタのメトリクス長期保存基盤としてPrometheusからVictoriaMetricsへ移行した事例。省設定・低CPU/RAM消費・ストレージ使用量が1/3という結果を評価し採用。promxyによる冗長構成で運用し、34億サンプルの移行も約13分で完了するなど安定稼働している。
日本オラクル監修による書籍で、2025年12月開始の新試験「Oracle AI Database 26ai Administration Associate」（1Z0-182）合格を目指す学習書。DB管理の基本から高度機能まで解説し、練習問題約150問と模擬試験1回分、Webアプリを収録。2026年10月28日発売予定、A5判560ページ。
Aurora DSQLが外部キー制約に対応した。REFERENCES句での新規作成やON DELETE CASCADE/SET NULLはPostgreSQLと同様に動作するが、既存テーブルへの追加はNOT VALID前提でVALIDATE CONSTRAINTは未サポート、CASCADE削除は1トランザクション3,000行制限の対象になるなど、DSQL特有の制約がある。
MySQL 8.4でSELECT MAX(id) FOR UPDATEによるID採番を並列実行するとデッドロックが発生する事象を検証。原因はレコードロックとギャップロック（末尾supremumへのロック）の取得順序がセッション間で交差するため。対策としてAUTO_INCREMENT、シーケンステーブル、GET_LOCKによるアドバイザリーロック、UUID採番の4方式を比較し、AUTO_INCREMENTかMySQL公式シーケンスパターンを推奨している。
AWS DMSでMySQLのTIME型をRedshiftのTIME型にマッピングしようとすると、型不一致エラーが発生する。DMSはMySQLのTIME型をいったんSTRING型に変換し、Redshiftではそれが VARCHAR として書き込まれるため、TIME型で事前定義したカラムとは型が一致しない。MySQLのTIME型が24時間を超える値域を持つのに対しRedshiftのTIME型は00:00:00〜24:00:00までしか扱えないという値域の違いも背景にある。対応策として、移行先カラムをVARCHARとして定義することが推奨されている。
Testcontainers上のPostgreSQLコンテナ内にスレッドごとのDatabaseを用意し、実DBを使ったテストを並列実行する基盤の設計事例。Schemaではなくデータベース単位で分離し、Migration済みTemplate DatabaseからCREATE DATABASE TEMPLATEで複製することでFlywayの実行を1回に抑え、テスト間のリセットはTRUNCATE+初期データ再投入（DROP&再作成より高速）を採用。pg_dumpで初期データを抽出する際のセッション設定混入やシーケンスのずれといった実装上のハマりどころも紹介している。
本番DB障害調査を「探索SQL→原因特定→修正SQL」の反復ループとしてAIエージェントに任せる方法論。probe/fix/impact/timelineの4種類にクエリを役割分担し、probeは読み取り専用で多段に重ねて仮説検証する。fix/restoreの実行は必ず人間が承認する境界を設け、破壊的操作には影響行数カウントやトランザクション巻き戻しを組み込む。調査の再現性・影響見積もりの精度・スループットの向上が得られる一方、本番でSELECT以外を自動実行させない安全設計を最重要事項として強調している。
BigQueryが非構造化データ活用を強化。自律型エンベディング生成(GA)でスキーマ定義だけで自動的にエンベディングを生成・同期でき、AI.SEARCH(GA)は単一クエリのスロット効率を最大133倍向上、ハイブリッド検索(プレビュー)はベクトル検索とキーワード検索を統合し専門用語の検索精度を高める。臨床試験文書の分析を例に、アクセス・処理・グラウンディング・関連付け・活用のライフサイクル全体をBigQuery上で完結できるようになった。
DuckDBの開発元DuckLabsが2026年9月初旬にAWSの子会社になると発表。DuckDBおよびDuckLakeはMITライセンスのオープンソースとして維持され、ライセンス・開発体制・ガバナンス・ロードマップも継続される。AWSにとっては、S3上の大規模データを高速分析できるDuckDBを自社のデータ戦略（S3、Redshift、S3 Tables等）を補完する要素として取り込み、SnowflakeやDatabricks、Google Cloudなど競合への接近を防ぐ狙いがあると見られる。
Google CloudがAI駆動のデータベース運用エージェント群を発表。自然言語で要件を伝えるとIOPSやレイテンシ等の要件から最適な構成を推奨・検証しプロビジョニングコマンドを生成するOnboarding Agentと、Database Insights・Cloud Monitoring・Logging・Traceを横断してクエリのホットスポットやロック競合の根本原因分析を数分で行うObservability Agentの2種。Gemini Cloud Assist経由でコンソール・CLI・Antigravity等のIDE、MCPサーバー経由でも利用可能で、Cloud SQL・Spanner・AlloyDB・Firestore・Memorystore・Bigtableなど主要DBサービスを横断してサポートする。
ベクトル検索インデックスのベンチマーク手法を解説する記事。HNSWとIVFの仕組み、recallとthroughputはセットで測る必要があること、ef_searchやM等のパラメータがトレードオフを生むこと、インデックスが使われず暗黙にフルスキャンへフォールバックする落とし穴、ビルド方式（incremental/bulk）の違いやフィルタ検索での正しいground truthの取り方など、公平な比較のために必要な計測設計と実装時に踏んだ落とし穴を詳細に説明している。
Percona Server for MySQL 8.4系の3バージョン（8.4.8-8、8.4.10-10、8.4.11-11）についてsysbench OLTP Read-Writeベンチマークで性能推移を検証。8.4.11-11はInnoDB LRUページフラッシュ最適化により、スレッド数が物理コア数を超える高並行・I/Oバウンド環境で他バージョンを大きく上回るTPSを達成。8.4.10-10はPGO導入により8.4.8-8より高性能。ただしデータが完全にバッファに収まる環境では8.4.10-10がわずかに優位。
AWSがDuckDBの開発元DuckLabsを買収する最終契約を締結。DuckDBはインプロセスで動作する分析データベースで、1TB以下の日常的なSQLクエリを高速処理する点に強みがある。創業者のHannes MühleisenとMark RaasveldtはAWSに参画し、DuckDBオープンソースプロジェクトは独立したFoundationの下でMITライセンスのまま維持される。Amazon QuickやAllen Instituteでの活用事例も紹介され、AWSはS3やRedshiftなど既存分析サービスとDuckDBの統合を進める方針。
Go の context を使い、DBクエリのタイムアウトとクライアント切断のキャンセルをhandler/usecase/repositoryの3層に貫通させる方法を実験付きで解説。context なしでは接続断後もDBがクエリを実行し続けること、WithTimeoutでの期限管理、ctx.Err()による確実なタイムアウト判定、504返却の実装例までを扱う実践的なGo学習記事。
PostgreSQLはオープンソースで移植性が高い一方、DBaaSベンダーが独自の拡張機能・運用基盤で囲い込む「Walled Garden」化が進んでいると指摘する記事。プロプライエタリな独自機能、移行コストの非対称性（導入は安く離脱は高くつく）、周辺サービス（バックアップ・IAM・分析基盤）との統合による「エコシステムの重力」という3つのロックイン機構を解説し、透明性・相互運用性・可搬性を重視する商用モデル（Perconaを例示）の重要性を論じている。
「直近10件」を意図したSQLが ORDER BY target_date ASC LIMIT 10 と書かれていたため、実際には最古10件を返す逆向きのバグとなっていた事例。行数がLIMIT以下のうちは正しく見え、本番でデータが増えてから発症するため発見が遅れた。修正はサブクエリで「選ぶ向き（DESC LIMIT）」と「見せる向き（ASC）」を分離し、さらにORDER BYが全順序になるようタイブレーク列（business_day_id）を追加。回帰テストはLIMITより多い行数を投入し「最古が含まれないこと」まで検証する必要があると指摘している。
自社DBを社内から自然言語で問い合わせられるようにするため、Google製OSS「MCP Toolbox for Databases」でMCPサーバを構築した事例。AIにSQLを直接生成させる方式は再現性・業務ルール反映の面で破綻したため、人間がレビュー済みのSQLをYAMLでツール定義し、AIはツール選択のみ行う方式に変更。認証は自前実装だが本家機能への移行を検討中、読み書きエンドポイントの分離やtoolsetsによるツール管理、運用後は利用ツールが偏る傾向が判明したことなどを紹介している。
Oracle Autonomous AI DatabaseとMicrosoft Excelを連携するアドイン「Oracle Database for Excel」の検証記事。データベース・アクションからのインストール手順、接続ファイルを使った接続設定、ダイレクトSQLの実行、GUIベースのデータ分析機能、自然言語によるクエリ機能（19cのため未検証）を紹介し、業務利用時の権限管理やセキュリティポリシー面の留意点も整理している。
DuckDB開発元のDuck LabsがAmazonに買収されると発表された。DuckDB Foundationが引き続きIPを管理し、ライセンスもパーミッシブなオープンソースのまま維持される。MotherDuckのCEOは、この買収がDuckDBコミュニティにとって長期的に良い方向に働くとの見解を示しつつ、Amazonが将来独自のDuckDBベースサービスを出す可能性にも言及。MotherDuckはDuck Labsとの協業を継続し、エンタープライズサポートの提供やDuckDBへの貢献を拡大する方針。
DuckDBの開発元DuckLabsがAWSの子会社として参画することを発表。DuckDB・DuckLake等のプロジェクトはMITライセンスのオープンソースのまま、非営利のDuckDB Foundationが管理を継続し、ロードマップやガバナンスに変更はない。
Percona Server for MongoDBがバージョン7.0.39-21、8.0.28-12、8.3.7-1以降でSBOM（CycloneDX形式）とVEXドキュメントを提供開始。SBOMをGrypeやOWASP Dependency Trackでスキャンすると多数の脆弱性が検出されるが、Go実装限定の脆弱性やビルド時無効化された機能、独自パッチ適用済みコードなど誤検知が多く含まれる。PerconaはVEXドキュメントを公式提供し誤検知を除外可能にした。ランタイムでリンクされる共有ライブラリ（libc, OpenSSL等）は別途SBOMスキャンが必要と注意喚起している。
個人開発の監視カメラサービスにおいて、設計ER図と実際のDB永続化状況にはギャップがあり、店舗・カメラ関連の4テーブルのみを先に永続化している。優先順位の基準は「プロセス再起動時に失われると困る度合い」で、ログインやカメラ識別に関わるデータを先に永続化し、再取得・再生成可能なイベント・通知はインメモリのまま残すという判断をMVP開発における実装順序の考え方として解説している。
DuckDB v2.0では再帰CTEの実行エンジンを刷新し、各イテレーション（epoch）ごとに使い捨てていたパイプラインスケジュールやハッシュビルドなどの実行状態を、再帰不変な部分は呼び出し(invocation)スコープで再利用するよう変更した。ジョインの向きを再構成して不変な辺テーブル側をビルド側に固定する、フロンティアの実サイズに応じてinline実行とスケジュール実行を動的に切り替える、USING KEYのキー付き状態を凍結したハッシュテーブルとして直接プローブ可能にする、といった最適化により、到達可能性クエリで4.051秒から0.095秒へ42.6倍高速化した。また意味論的な変更として、USING KEY ... UNIONで実際に変化した新規/更新キーのみを次イテレーションに伝播するようにした。
DuckDB Java クライアントが純粋な Java でテーブル関数を書けるようになった。C++ 拡張のビルドなしに、MongoDB など Java ドライバでアクセスできる任意のデータソースを SQL のテーブル関数として登録でき、ローカルの Parquet/CSV とジョインできる。bind/init/apply の3コールバックで実装し、フィルタは各ソースの元のクエリ言語のまま渡される。現状は DuckDB 拡張としてのパッケージ化不可、リソースの自動解放なし、STRUCT/LIST 等の複合型は未対応という制限がある。
SQLite 3.31.0で追加されたgenerated columns機能を使い、JSONカラムからフィールドを抽出・インデックス化してドキュメントDBのように扱う方法を紹介。VIRTUAL/STOREDの違い、NOT NULL制約によるJSONバリデーション、ALTER TABLEでの後からのカラム追加とインデックス作成についても解説している。
軽量OLAP DBのDuckDBが今秋リリース予定の2.0で大型刷新を実施。別マシンのDuckDBに接続するクライアント/サーバ機能、PEGベースへのSQLパーサ全面刷新、JSON型を強化したスキーマレスのVARIANT型、トリガー機能、非同期I/Oによるリモートファイル読み取りの高速化などが追加される。
Google Cloud の Database Migration Service に Gemini を活用したAIコード変換機能が追加された。Oracle PL/SQLやSQL ServerのT-SQLで書かれたストアドプロシージャ・トリガー・カスタム関数をPostgreSQLのPL/pgSQLへ自動変換し、従来数ヶ月かかっていた手続き型ロジックの書き換えを数日に短縮する。スキーマ全体のコンテキストを踏まえた変換、決定論的コンパイラルールとGeminiのハイブリッド処理による精度確保、コンソール上での差分表示・検証・デプロイまでを一貫して行えることが特徴。
DuckDB Java ドライバー v1.5.3.0 で、従来の行単位 JDBC ResultSet に加えて、エンジン内部のカラムナ形式チャンクを直接読める DuckDBChunkedResult API が追加された。行→列の変換往復を省き、大規模結果セットを遅延・低オーバーヘッドで読めるが、複合型非対応など現時点では制限がある。
MySQLの空間関数ST_Length()を使い、LineStringの長さをメートル単位で計測する方法を解説。鉄道路線データを例に、路線ごとの総延長ランキングや駅の「長さ」比較を実演し、PolygonにはST_Perimeter()相当の関数がMySQLに存在しない点にも言及している。
メルカリDBREチームによるTiDB移行改善記事の最終回。共有インデックス構成では、複合主キーや非整数主キー（common handle）を持つテーブルで、主キーのORDER BYがインデックス順として認識されずTopNによる全件読み取りが発生するというMySQLとの非互換を実行計画付きで解説し、インデックス末尾に主キーカラムを追加する対処を紹介。あわせてTiDB移行で顕在化しやすいN+1問題の改善とオプティマイザヒントによる実行計画制御についても述べている。
DuckDBはv2.0でPostgreSQL派生のYACC/Bisonパーサーを、PEG(Parsing Expression Grammar)ベースの独自パーサーに全面刷新した。LALR文法の拡張性の限界を解消しつつ、Python同様PEGを採用。パックラット構文解析でバックトラックによる指数関数的な処理時間増大を防ぎ、既存のAST・SQL方言(DuckSQL)との互換性も維持。今後は拡張機能によるトークナイザ・文法ルールの拡張も可能になり、パイプ構文(`|>`)などの新構文追加も容易になる。