TimescaleDBとは？PostgreSQL拡張の仕組みと採用可否の判断基準

TimescaleDBは、PostgreSQLの拡張（EXTENSION）として時系列データを扱うOSSです。テーブルを時間軸で自動分割するハイパーテーブル、行指向と列指向を切り替えるhypercore、集計結果を差分更新する連続集計といった機能を、既存のSQLとドライバのまま使えます。この記事では2.29系（2026年7月28日リリース）時点の一次情報をもとに、内部構造、Apache-2版とTSL版の線引き、Amazon RDSが非対応という国内案件で最初に効く制約、採用してよい条件と見送るべき場面を実装者の目線で整理します。

まとめ：TimescaleDBの立ち位置と採用可否を分ける3条件

TimescaleDBは「時系列に強いPostgreSQL」であり、独立した新しいデータベース製品ではありません。既存のPostgreSQL資産（SQL、ドライバ、バックアップ運用、BI接続）を引き継げる点が最大の差分です。

採用可否は、次の3条件がそろうかどうかで決まります。第一に、時系列データと業務マスタをJOINして扱う要件があること。第二に、単一ノードで捌ける規模であること（マルチノードは2.14.0で削除済み）。第三に、圧縮と連続集計を使えるTSL版を動かせる環境を選べること。

逆に、インフラがAmazon RDSやAuroraに固定された案件では、そもそも拡張を導入できません。設計努力で埋まらない制約なので、要件定義の段階で確認してください。

TimescaleDBの定義と現行2.29系｜PostgreSQL拡張で時系列を扱う設計

PostgreSQL拡張として動く構造と、単体DBではない前提の理解

TimescaleDBの実体はCREATE EXTENSION timescaledb;で導入する拡張モジュールです。エンジンはPostgreSQLそのもので、SQL文法、型システム、インデックス、権限管理、WALによるレプリケーションを引き継ぎます。

ここから実務上の帰結が2つ出ます。1つは、アプリケーション側の変更がほぼ不要なこと。psycopg、JDBC、ORMはPostgreSQL接続のまま動きます。もう1つは、PostgreSQL側の制約も継承すること。書き込みは単一プライマリに集まり、垂直スケールの上限がそのまま基盤の上限になります。

2.29.0で外れたPostgreSQL 15対応と、マルチノード廃止の経緯

最新は2.29.0（2026年7月28日）で、対応するPostgreSQLは16・17・18の3系列です。2.28.0がPostgreSQL 15をサポートする最後のマイナー版と予告され、2.29.0で削除されました。PostgreSQL 15で運用中なら、拡張を上げる前にエンジン側の移行が先です。

もう一つ押さえておきたいのが分散構成の扱いです。複数ノードにチャンクを分散させるマルチノード機能は2.13で非推奨となり、2.14.0（2024年2月8日）でコードごと削除されました。開発元は「利用環境は全体の約1%で保守コストに見合わない」と説明しています。マルチノード前提の構成図を載せた解説記事が残っていますが、現行版では選べません。

ハイパーテーブルとチャンク｜自動分割の仕組みと分割幅の決め方

CREATE TABLE構文へ移ったハイパーテーブル定義の書き方

ハイパーテーブルは、時間列を基準に物理テーブル（チャンク）へ自動分割される親テーブルです。ユーザーからは1枚のテーブルに見え、内部では専用スキーマにチャンクが生成され、クエリ時は時間条件に合致するチャンクだけが読まれます。実体はパーティショニングですが、分割の作成と枝刈りが自動化されている点が違います。

定義の書き方は世代交代しました。現行版はCREATE TABLE metrics (ts timestamptz NOT NULL, device_id text, value double precision) WITH (tsdb.hypertable, tsdb.partition_column='ts', tsdb.chunk_interval='1 day');のように、CREATE TABLEのオプションで直接指定します。従来のcreate_hypertable()関数は後方互換のために残る扱いです。2.19.3以前を使う現場では従来手順が必要なので、参照する記事のバージョンを確認してください。

既定7日のチャンク間隔を搭載メモリと実データ量から決め直す基準

チャンク幅を指定しない場合、既定値は7日です。この値は放置してよいものではありません。公式ドキュメントは「取り込み中のチャンクのインデックスが、メインメモリの25%に収まる幅」を基準として示しています。インデックスがメモリに載らなくなると、行を挿入するたびにディスクへの書き戻しと読み込みが発生し、本来ヒープとWALの書き込みに使うべきI/Oを食い潰します。

具体例も明示されています。メモリ64GBのマシンで、インデックスの増加が1日あたり約2GBなら1週間幅が妥当。10GB増えるなら1日幅にする。設計時に搭載メモリと日次インデックス増加量の2つを見積もれば、チャンク幅は機械的に決まります。センサー1万台×10秒間隔の取り込み量なら、既定の7日では大きすぎます。

hypercoreの行列ハイブリッド｜columnstore変換と圧縮率の実像

2.18で入ったcolumnstoreと、2.22で撤去されたTAMの扱い

hypercoreは、1つのハイパーテーブルの中で行指向（rowstore）と列指向（columnstore）を同居させるストレージ機構です。直近の書き込みは行指向で受け、更新されなくなったチャンクは列指向へ変換して圧縮します。集計クエリは必要な列だけを走査すればよくなります。

ここで版差に注意が必要です。columnstoreを管理する現行の関数群は2.18.0（2025年1月23日）で整理されました。一方、同じ2.18で試験的に入った「hypercore TAM（テーブルアクセスメソッド）」は期待した性能改善が出ず、2.21.0で非推奨、2.22.0（2025年9月2日）で撤去されています。TAMを有効にしたまま2.22.0へ上げるとアップグレードがブロックされ、アクセスメソッドをheapへ戻す移行スクリプトの実行が必要になります。撤去されたのはTAMという実装方式であって、列指向ストア自体は現役です。

add_columnstore_policyで冷えたチャンクを列指向へ移す設定

運用では、チャンクの経過時間をトリガーにした自動変換ポリシーを1本入れておくのが基本形です。SELECT add_columnstore_policy('metrics', after => INTERVAL '7 days');と書けば、7日を過ぎたチャンクがバックグラウンドジョブで列指向へ移ります。個別に変換するconvert_to_columnstore()、行指向へ戻すconvert_to_rowstore()もあり、更新が入った過去データだけ書き戻せます。

圧縮率は公式ドキュメントで90〜98%と記載され、194MBのチャンクが24MBになる例が示されています。この数字は鵜呑みにせず、自社のカーディナリティで検証してください。効きが良いのはデバイスIDのような繰り返しの多い列で、値がほぼランダムな高カーディナリティ列ばかりのテーブルでは公称値に届きません。

連続集計と保持ポリシー｜ダッシュボード応答を一定に保つ運用設計

連続集計がマテビューと異なる差分更新の仕組みと更新間隔の指定

連続集計（continuous aggregate）は、1分値から1時間値・日次値をあらかじめ作っておく仕組みです。PostgreSQL標準のマテリアライズドビュー（マテビュー）との違いは更新の粒度にあります。マテビューはREFRESHのたびに定義全体を作り直しますが、連続集計は変更のあった時間範囲だけを差分で更新し、更新間隔をポリシーとして宣言できます。

効き方が大きいのはダッシュボードの応答時間です。1年分の生データをその都度集計すると走査量が線形に増えるのに対し、日次の連続集計を挟めば読む行数は一定に近づきます。2.22.0ではWALベースの無効化検出が技術プレビューとして入りました。

保持ポリシーとジョブスケジューラでデータ肥大を止める運用の型

時系列基盤が壊れる原因の多くは、消す設計を後回しにしたことです。TimescaleDBはadd_retention_policy()で「N日を過ぎたチャンクを削除する」宣言を書けます。削除はチャンク単位のDROPで、行単位のDELETEと違いVACUUM負荷もテーブル膨張も出ません。

圧縮ポリシーと保持ポリシーは同じジョブスケジューラで動き、実行履歴はtimescaledb_information.job_statsに残ります。設計の型は「7日でcolumnstore変換、400日で削除、日次連続集計は無期限保持」のように、生データと集計値で保持期間を分ける形。集計値だけ残せば、ストレージを抑えたまま長期の傾向分析が続けられます。

Apache-2版とTSL版の線引き｜使える機能とDBaaS提供を禁じる条項

Apache-2版で欠ける圧縮・連続集計と、TSL版で戻る機能範囲

TimescaleDBは単一のライセンスで配布されていません。コア部分はApache License 2.0ですが、連続集計、圧縮（columnstore）、時系列向けのクエリ高速化はTimescale License（TSL）配下のソースツリーに置かれています。「TimescaleDBはApache-2のOSS」という説明は、Apache-2版（timescaledb-apache）に限った話です。

この差は機能の欠落として現れます。Apache-2版で使えるのはハイパーテーブルとチャンク管理までで、圧縮も連続集計も保持ポリシーも動きません。選ぶ動機の大半がTSL側の機能にある以上、どちらの版が入るかは環境選定の前提条件になります。

受託開発とSaaSでTSLのDBaaS禁止条項に触れる境界線

TSLの制限は明確です。ライセンス本文は「TSL対象ソフトウェアをタイムシェアリングサービスまたはDatabase-as-a-Serviceとして提供すること」を禁じています。一方で、自社の内部業務目的での利用は無償で認められ、本番運用も含みます。

判断が割れるのは、顧客向けSaaSに組み込むケースです。TSLは付加価値のある自社製品への組み込みを認めていますが、条件が3つ付きます。ストレージ機能そのものを超える実質的な付加価値があること、TSL対象である旨を顧客に通知すること、顧客が標準的なデータベースインターフェース経由でスキーマを変更できないこと。「アプリケーションの裏側で時系列データを保持する」構成なら問題なく、「顧客にDB接続情報を渡してテーブルを自由に作らせる」構成はDBaaSに寄ります。受託案件で納品形態を決める前に、この線引きを顧客と共有しておくと後戻りを防げます。

動かす場所の選択肢｜RDS非対応とAzure・Tiger Cloudの実態

RDS・Auroraが非対応である事実と、AWS上での代替構成

国内案件で最初に突き当たるのがここです。Amazon RDS for PostgreSQLおよびAurora PostgreSQLがサポートする拡張の一覧に、timescaledbは含まれていません。RDSは許可された拡張しか入らないため、パラメータグループをどういじっても導入できません。同じ時系列向けでもpg_partmanとpg_cronは使えるので、「パーティション自動管理までで足りるか」が最初の分岐になります。

AWS上で動かすなら、選択肢はEC2やコンテナへの自前構築か、Tiger Cloudのようなマネージドサービスです。自前構築なら高可用性はPostgreSQLの一般的な手法で組むことになり、repmgrによる自動フェイルオーバー構成が現実的な候補になります。マネージドを捨てた分の運用（バックアップ、マイナーバージョン追従、フェイルオーバー検証）が自社に戻る点は、見積もりに織り込んでください。AWSのマネージドで完結させたい要件なら、Amazon Timestreamの仕組みと料金モデルと比較して判断する形になります。

Azureのapache-2版とTiger Cloud東京リージョンの選び分け

Azure Database for PostgreSQL フレキシブルサーバーはtimescaledbをサポートしますが、提供されるのはApache-2 editionで、前章のとおり圧縮と連続集計は含まれません。加えてメジャーバージョンアップグレード時に非コア拡張は自動更新されず、ALTER EXTENSION ... UPDATEまたは再作成が手動になります。手順書にこの1行を書き忘れると、アップグレード後に拡張が動かない事故になります。

TSL版の機能をマネージドで使いたい場合は、開発元のTiger Cloudが本命です。Timescale社は2025年6月17日にTiger Dataへ社名を変更し、クラウドサービスもTiger Cloudの名称に変わりました。リージョンはAWSのap-northeast-1（東京）を含みます。データを国外に出せない案件で海外SaaSが候補から外れがちな中、この点は効きます。

InfluxDB・Timestream・素のPostgreSQLとの使い分けの境界

InfluxDB・Timestreamとの設計思想の違いと移行コストの差

候補はクエリ言語とデータモデルの前提で分かれます。TimescaleDBはSQLとリレーショナルモデルをそのまま保ち、InfluxDBは時系列に寄せた専用設計を取ります。既存の業務データとJOINしたい要件があるかどうかが、実務上の分岐点です。

移行コストで見ると差は明確です。すでにPostgreSQLで業務システムを動かしている現場なら、TimescaleDBへの移行は拡張の追加とテーブル定義の変更で済みます。専用エンジンへ移すなら、書き込みクライアント、クエリ、BI接続、バックアップ運用をすべて組み直す前提で見積もってください。

素のPostgreSQLとpg_partmanで足りる規模の見極め方

TimescaleDBを入れない判断も現実的な選択肢です。PostgreSQL 15以降の宣言的パーティショニングとpg_partmanを組み合わせれば、時間軸での自動パーティション作成と古いパーティションの削除は実現できます。追加の拡張ライセンスを気にせず、RDSでも動きます。

境界の目安はデータ量と集計要件です。行数が数千万規模にとどまり集計対象が直近1か月程度なら、素のPostgreSQLにインデックスを張るだけで応答します。一方、数億行を超えて長期の集計を返す要件になると、圧縮によるI/O削減と連続集計による事前集計が効いてきます。「パーティションを切っただけでクエリが遅い」段階に来たときが、TimescaleDBを検討する合図です。時系列基盤の設計や既存DBからの移行方針で判断に迷う場合は、データ分析基盤構築・MLOps構築支援で要件整理から相談できます。

TimescaleDBを採用してよい3条件と、見送るべき2つの場面

採用してよい3条件｜SQL資産・単一ノード規模・列指向の効果

採用してよいのは次の3つがそろう場合です。重みが大きい順に並べます。

第一に、時系列データを業務マスタとJOINして返す要件があること。「センサー値に設備マスタと契約情報を結合してレポートを出す」類の要件は、TimescaleDBの独壇場です。専用エンジンではアプリケーション側で結合を書く羽目になります。

第二に、単一ノードで捌ける規模に収まること。マルチノードは削除済みで、書き込み量の上限は1台の性能とストレージで決まります。垂直スケールで見通せる範囲かを日次データ量から逆算してください。

第三に、圧縮と連続集計が効くデータ形状であること。デバイスIDのような繰り返し列を持ち、集計単位が決まっているワークロードなら、columnstore変換で保存容量と走査量の両方が下がります。この3つを満たすなら、比較検討に時間をかけるよりPoCに進んだほうが早く結論が出ます。

見送るべき2場面｜RDS固定の案件とDBaaS型の再販モデル

逆に、見送るべき場面もはっきりしています。1つ目は、インフラ標準がAmazon RDSまたはAuroraに固定されている案件。拡張が導入できない以上、検討自体が成立しません。pg_partmanでのパーティション管理か、Timestreamのようなマネージドサービスへ振るのが筋です。「EC2に立てれば動く」という提案は可能でも、RDSを標準化した組織に運用負担を戻す話になるため、押し通すべきではありません。

2つ目は、顧客にデータベースそのものを提供するビジネスモデル。TSLがDBaaS提供を禁じているため、顧客がスキーマを自由に変更できる形で提供するとライセンス違反に触れます。この用途ならApache-2版で機能を諦めるか、別の製品を選ぶことになります。ここは「グレーだが黙って進める」判断をしてはいけない領域です。

よくある質問

TimescaleDBの導入検討でよく挙がる質問を、一次情報にもとづいて整理しました。

TimescaleDBは無料で使えますか？

自社の内部業務目的での利用であれば、TSL版を含めて無償で使えます。本番運用も認められています。コア部分はApache License 2.0、圧縮や連続集計はTimescale License（TSL）配下という二層構造で、TSLが禁じるのはタイムシェアリングサービスやDatabase-as-a-Serviceとして第三者に提供する形態です。マネージドのTiger Cloudを使う場合は、そのサービス料金がかかります。

TimescaleDBとPostgreSQLの違いは何ですか？

TimescaleDBは独立したデータベースではなく、PostgreSQLに追加する拡張です。SQL、型、ドライバ、権限管理はPostgreSQLのままで、そこに時間軸での自動パーティショニング（ハイパーテーブル）、列指向への自動変換と圧縮、連続集計、保持ポリシーが加わります。接続方法は変わらないため、既存のPostgreSQL向けツールがそのまま使えます。

既存のPostgreSQLテーブルを後からハイパーテーブルにできますか？

できます。create_hypertable()関数に既存テーブルを渡せば変換され、既存データはチャンクへ移されます。現行版では新規作成時にCREATE TABLEのオプション（tsdb.hypertable）で指定する書き方が推奨で、この関数は後方互換のために残る位置づけです。変換時はテーブルロックとデータ移動が発生するため、大量データを持つテーブルではメンテナンス時間の確保が必要になります。

TimescaleDBの圧縮率はどのくらいですか？

公式ドキュメントはcolumnstoreでの圧縮率を90〜98%と記載し、194MBのチャンクが24MBになる例を示しています。実際の値はカーディナリティとsegmentby・orderbyの指定に左右され、値がランダムに近いテーブルでは公称値ほど縮みません。導入前に本番相当のデータでチャンク1つ分を変換し、実測してから容量設計に入るのが安全です。

Amazon RDSでTimescaleDBは使えますか？

使えません。RDS for PostgreSQLおよびAurora PostgreSQLがサポートする拡張の一覧にtimescaledbは含まれておらず、許可されていない拡張はインストールできない仕組みです。AWS上で動かすなら、EC2やコンテナでの自前構築、開発元のTiger Cloud（ap-northeast-1を含むリージョンで提供）、Amazon Timestreamへの置き換えが選択肢になります。

関連記事

• InfluxDBとは？時系列DBの仕組み・InfluxDB 3の設計から採用判断まで実装者向けに解説：専用エンジン側の代表格。TimescaleDBと比較検討する際の対になる記事です。
• Amazon Timestreamとは？仕組み・2つのエンジンと料金モデル・採用判断を実装者目線で解説：RDS非対応でAWSマネージドに寄せる場合の代替候補を整理しています。
• PostgreSQLとMySQLの違いを徹底比較｜性能・データ型・全文検索・移行と使い分け【2026年版】：土台となるPostgreSQL自体の選定に使えます。
• pgvectorの基本概要とPostgreSQLにおけるベクトル検索の重要性：拡張で機能を足す設計思想のもう一つの例です。
• Prometheusの誕生とCloud Native Computing Foundationとの関係：監視メトリクス側で時系列を扱う別系統の仕組みです。