PostgresML が『DB内ML』の本命に
従来の機械学習パイプラインでは、データをPostgreSQLから取り出し→ML サービスで推論→結果を戻すの工程が必要でした。PostgresMLはPostgreSQL拡張で、SQLから直接モデル訓練・推論・ベクトル検索を実行できるOSSプロジェクト。データ移動を最小化し、開発・本番運用を圧倒的にシンプル化します。2025年安定化、2026年に本番採用例が拡大しています。
採用すべき5つのシグナル
- PostgreSQLが中心のスタック
- MLパイプラインのデータ移動コストが課題
- 推論レイテンシ最小化が必要
- シンプルなML運用を求める
- RAG・ベクトル検索を統合したい
主要機能
- SQL Functions: 機械学習をSQL関数として呼び出し
- Embedding Generation: テキスト→ベクトル変換
- LLM Inference: PostgreSQL内でLLM推論
- Model Training: SQLからモデル訓練
- Vector Search: ベクトル類似検索
- Time Series: 時系列予測
従来MLパイプライン/PostgresML比較
従来: DB→ETL→ML Service→DBで複雑運用。
PostgresML: DB内完結・SQL呼び出し・運用シンプル。
Vector DB: 専用ベクトルDB（Pinecone等）と比較してPostgreSQL統合が強み。
使い分け: PostgreSQL中心・運用シンプル化はPostgresML・大規模専用ML処理は従来パイプライン。
実装パターン
(1) 拡張インストール: CREATE EXTENSION pgml
(2) 埋め込み生成: SELECT pgml.embed('intfloat/e5-small', 'text')
(3) LLM推論: SELECT pgml.transform('text-generation', '...')
(4) ベクトル検索: SELECT * FROM items ORDER BY embedding <-> '[...]' LIMIT 10
(5) モデル訓練: SELECT pgml.train('Forecast', 'linear_regression', ...)
本番採用の判断基準
- 本番実績: 2025年安定化・スタートアップ採用増
- PostgreSQL運用ノウハウ活用
- パフォーマンス: GPU対応で本格ML処理
- ベンダーロックイン: OSS・標準PostgreSQLで動作
- 移行コスト: 既存PostgreSQLに拡張追加
採用しない方が良いケース
- PostgreSQLでない（MySQLなど）
- 超大規模ML処理（GPU専用サーバ向き）
- 専用ベクトルDBで運用慣れている
- MLチームと運用チームが完全分離
実装で詰まる3つの落とし穴
- GPU要件: 本格LLM推論はGPU必須
- モデルキャッシュ: 起動時のモデルロード時間
- バージョン管理: モデル更新時の互換性
30日学習プラン
- 1週目: PostgresML拡張インストール・基本SQL関数
- 2週目: 埋め込み生成・ベクトル検索
- 3週目: LLM推論・モデル選定
- 4週目: GPU環境・本番運用
関連リンク
pgvectorは pgvector深掘り、PostgreSQLは PostgreSQL深掘り、RAG構築は RAG構築ガイド を参照してください。