Amazon Redshiftとは｜DWHの仕組み・Serverless料金と始め方

この記事で実際に動かしたもの：公式の単価からの料金計算（Python）、行指向と列指向の読み取り量・圧縮・ブロックの読み飛ばし・分散の偏りの計算（Python）、公式のサンプル SQL と Redshift 固有の構文（PostgreSQL 16.15）。Redshift 本体には接続していません。

Redshift は、業務のデータベースとは別に置く「集計専用の倉庫」です。データの流れは次のようになります。

flowchart TD
    A[業務DB<br>Aurora・RDS など] -->|ゼロETL・COPY| R
    S[S3 のファイル<br>CSV・Parquet] -->|COPY・Spectrum| R
    R[Amazon Redshift<br>列指向で保存・並列で集計] --> B[BI・ダッシュボード]
    R --> Q[SQL での分析]

よく調べられることの答えを先にまとめます。

確認環境：Redshift の仕様・料金・手順は、AWS の公式（aws.amazon.com の料金ページと製品の発表、docs.aws.amazon.com の管理ガイドとデベロッパーガイド、AWS の公式ブログ）で確かめました。料金ページの本文には東京リージョンの単価が載っていなかったため、ページに載っている米国東部（バージニア北部）の単価で計算しています（AWS の価格表ファイルの取得はこの環境の通信の制限で行えなかったので、使っていません）。計算は Ubuntu 24.04 の Python 3.13.18（numpy）、SQL の実行は 127.0.0.1 だけで待ち受ける PostgreSQL 16.15 で行いました。AWS のアカウント・鍵は使っておらず、Redshift 本体・コンソールには接続していません。画面の名前は公式の手順に出てくる語だけを「」で書いています。図は mermaid で描画を確かめました（確認日 2026年11月13日）。

Amazon Redshiftとは（1行の答えと全体像）

この節では、Amazon Redshift が何をするサービスで、どこから使い始めるのかが分かります。

AWS の公式ドキュメントは、Amazon Redshift を「クラウド上の、フルマネージドでペタバイト規模のデータウェアハウスのサービス」と説明しています。フルマネージドとは、サーバーの用意・パッチの適用・バックアップなどの運用を AWS が受け持つという意味です。利用者はテーブルを作り、データを入れ、SQL で集計します。

形は2種類あります。

2026年11月13日時点では、2026年5月12日に AWS Graviton を使った新しいノードの種類「RG」が発表され、管理ガイドのノードの表は RG と RA3 の2系統になっています。名前を聞く機会が多い DC2 は、この表には載っていません（後の節で扱います）。

次の節では、そもそも DWH がふつうのデータベースとどう違うのかを整理します。

データウェアハウス（DWH）とは｜データベースとの違い

この節では、DWH という言葉の意味と、業務のデータベース（OLTP）との使い分けが分かります。

データウェアハウス（DWH）は、分析のために複数の場所からデータを集めて、長い期間ためておくデータベースです。「ウェアハウス」は倉庫の意味で、注文・会員・アクセスログなど、別々のシステムにあるデータを1か所に集めて、まとめて集計できるようにします。

データベースの処理は、大きく2つに分かれます。

AWS のデベロッパーガイドも、Redshift は OLAP と BI（ビジネスインテリジェンス）のために設計されていて、OLTP 向けの PostgreSQL とは保存の形も実行の仕組みも「まったく異なる」と書いています。同じ SQL が書けても、得意な処理は逆です。

データベースそのものの基本は、関連記事「データベースとは｜種類・Excelとの違い・SQLの基本を実例で解説」で扱っています。次の節では、DWH の速さの中心にある「列指向」を、読み取る量の計算で確かめます。

列指向ストレージの仕組み｜行指向との読み取り量を計算

この節では、列指向がなぜ集計に強いのかを、読み取る量の計算と手元の PostgreSQL の実測で確かめられます。

列指向（カラムナ）は、同じ列の値をまとめてディスクのブロックに入れる保存のしかたです。行指向は1行分の値を並べて入れます。公式ドキュメントは、Redshift のブロックの大きさは 1MB で、「100列の表で5列だけを使うクエリは、表のデータの約5%を読むだけで済む」と説明しています。

計算：1億行・100列の表で読む量

1列を平均8バイトとして、1億行・100列の表から5列を読むクエリを考えます。行指向では、必要な列が各行に散らばっているので、表全体を読むことになります。

N = 100_000_000; cols = 100; w = 8; use = 5; BLK = 1024 * 1024
row_total = N * cols * w      # 行指向で読む量（表全体）
col_read  = N * use * w       # 列指向で読む量（5列だけ）
print(row_total / 1e9, col_read / 1e9, col_read / row_total)
print(-(-row_total // BLK), -(-col_read // BLK))   # 1MBブロックの数

表全体 80 GB / 行指向で読む量 80 GB / 列指向で読む量 4 GB (5%)
1MBブロック数 行指向 76,294 / 列指向 3,815
  使う列   1 本 -> 読む割合 1%
  使う列   5 本 -> 読む割合 5%
  使う列  30 本 -> 読む割合 30%
  使う列 100 本 -> 読む割合 100%

読む量は「使う列の数÷全部の列の数」に比例します。SELECT * で全部の列を取ると、列指向の利点は消えます。Redshift で列を絞って書くことが大事なのはこのためです。

実測：行指向の PostgreSQL では1列の合計でも表全体を読む

手元の PostgreSQL 16（行指向）に、20万行・21列の表を作り、1列だけを合計しました。EXPLAIN (ANALYZE, BUFFERS) で、読んだページ（8KB）の数を見ます。

SELECT pg_relation_size('wide') AS bytes, pg_relation_size('wide')/8192 AS pages;
SET max_parallel_workers_per_gather = 0;
EXPLAIN (ANALYZE, BUFFERS, COSTS OFF, TIMING OFF) SELECT sum(c01) FROM wide;
SELECT sum(pg_column_size(c01)) AS c01_bytes FROM wide;

  bytes   | pages
----------+-------
 82182144 | 10032

 Aggregate (actual rows=1 loops=1)
   Buffers: shared hit=1056 read=8976
   ->  Seq Scan on wide (actual rows=200000 loops=1)
         Buffers: shared hit=1056 read=8976

 c01_bytes
-----------
    800000

合計に使った列 c01 のデータは 800,000 バイト（約0.8MB）なのに、行指向では 1,056＋8,976＝10,032ページ（約82MB）をすべて読みました。約103倍です。列指向なら、c01 の列のブロック（1MB なら1つ）だけを読めば済む計算になります。実行計画の読み方は、関連記事「実行計画の見方｜EXPLAIN ANALYZEの読み方を実行結果で解説」で扱っています。

計算：列ごとに並べると圧縮も効く

同じ列には似た値が並ぶので、列指向は圧縮しやすくなります。売上に似た5列・20万行のデータを、行の順と列の順に並べて zlib で圧縮しました（Redshift の圧縮方式そのものではなく、傾向を見るための計算です）。

行の順: 元 3,600,000 B -> 圧縮後 1,747,671 B (48.5%)
列の順: 元 3,600,000 B -> 圧縮後 1,387,855 B (38.6%)
  列 buyerid: 800,000 -> 411,136 B (51.4%)
  列 qtysold: 400,000 -> 69,397 B (17.3%)
  列 saletime(日,並べ済み): 800,000 -> 1,585 B (0.2%)

種類の少ない列（数量）や、並べてある日付の列は大きく縮みました。Redshift ではテーブル作成時の既定が ENCODE AUTO で、列ごとの圧縮方式を Redshift が選びます。ファイル形式で同じ考え方をとる Parquet は、RJC の技術記事「Parquetとは｜CSVとの違い・読み書き・中身を100万行で実測」でも扱っています。

次の節では、読む量を減らしたうえで、さらに「複数のノードで分けて読む」しくみを見ます。

MPP（超並列処理）｜リーダーノードとコンピュートノード

この節では、Redshift がクエリを複数のノードに分けて処理する流れと、スライスという単位が分かります。

MPP（Massively Parallel Processing、超並列処理）は、データを複数のノードに分けて置き、それぞれが自分の分を同時に処理するしくみです。管理ガイドによると、クラスターは1つのリーダーノードと1つ以上のコンピュートノードからできています。

ノードの中は「スライス」に分かれていて、データはスライス単位で分けて置かれます。管理ガイドの表では、1ノードあたりの既定のスライス数は rg.xlarge が2、rg.4xlarge が8、ra3.4xlarge が4です。スライスの間でデータの量が偏ると、いちばん多いスライスの処理が終わるまで全体が待つことになります。

Serverless では、ノードやスライスを自分で選びません。それでも、データをどう分けて置くか（分散スタイル）と、どう並べるか（ソート）の指定は同じように効きます。次の節で、分け方の偏りを計算で見ます。

分散キー（DISTKEY）と分散スタイル｜偏りを計算

この節では、分散スタイル AUTO・EVEN・KEY・ALL の違いと、分散キーの選び方で偏りがどれだけ変わるかが分かります。

分散スタイルは、テーブルの行をどのスライスに置くかの決め方です。指定しない場合の既定は AUTO です。

計算：分散キーの選び方で偏りが変わる

4スライスに4万行を配ったときの行数を計算しました。Redshift の内部のハッシュ関数は公開されていないので、ここでは MD5 で代用しています（偏りの傾向を見るための計算です）。「最大/最小」は、公式のシステムビュー SVV_TABLE_INFO の skew_rows（いちばん多いスライスと少ないスライスの行数の比）と同じ考え方の数字です。

== (4) 分散キーとスライスの偏り（4スライス・MD5で代用）
KEY(buyerid 5000種類): [10267, 9510, 9944, 10279] 最大/平均 1.03 最大/最小 1.08
KEY(status 3種類): [0, 0, 40000, 0] 最大/平均 4.00 最大/最小 inf
KEY(1社が50%の顧客ID): [5069, 4841, 4994, 25096] 最大/平均 2.51 最大/最小 5.18
EVEN(ラウンドロビン): [10000, 10000, 10000, 10000] 最大/平均 1.00 最大/最小 1.00

• 種類が多く、偏りの無い列（購入者ID）は、ほぼ均等に分かれました（最大/最小 1.08）。
• 種類が3つしかない列（状態）は、この計算では3つの値がたまたま同じスライスに入り、残り3つのスライスが空になりました。そもそも値が3種類なら、使えるスライスは最大でも3つです。
• 1社が全体の半分を占める顧客IDは、その会社の行が入ったスライスだけが約5倍の量になりました。

Redshift で書くときの形は次のとおりです（デベロッパーガイドの CREATE TABLE の構文。この SQL は Redshift 用で、PostgreSQL では後の節のとおりエラーになります）。

CREATE TABLE sales (
  salesid   INTEGER,
  buyerid   INTEGER,
  eventid   INTEGER,
  qtysold   SMALLINT,
  pricepaid DECIMAL(8,2),
  saletime  TIMESTAMP
)
DISTSTYLE KEY
DISTKEY (buyerid)
SORTKEY (saletime);

-- 偏りと並び具合を確かめる（SVV_TABLE_INFO は既定ではスーパーユーザーだけが見られる）
SELECT "table", diststyle, sortkey1, skew_rows, unsorted, tbl_rows, size
FROM svv_table_info
ORDER BY size DESC;

次の節では、もう1つの指定であるソートキーが、読むブロックをどれだけ減らすかを計算します。

ソートキー（SORTKEY）とブロックの読み飛ばし

この節では、ソートキーで並べておくと、範囲で絞るクエリが読むブロックをどれだけ減らせるかが分かります。

Redshift は 1MB のブロックごとに、その中の最小値と最大値を記録しています。WHERE で範囲を指定すると、範囲に入らないブロックは中を読まずに飛ばせます。公式ドキュメントは「5年分のデータを日付で並べてあり、1か月分を指定するクエリなら、最大で98%のブロックをスキャンから外せる」と説明しています。

計算：5年分・1日2,000行を日付で並べた場合と並べない場合

5年分（1,825日）・1日2,000行のデータを、1ブロック 8,192 行として 446 ブロックに分け、直近30日を指定したときに「最小値〜最大値が範囲に重なるブロック」を数えました。

def blocks_read(arr, lo, hi):
    nb = math.ceil(len(arr) / blk); cnt = 0
    for i in range(nb):
        s = arr[i*blk:(i+1)*blk]
        if s.max() >= lo and s.min() <= hi:   # ブロックの最小・最大だけで判定
            cnt += 1
    return cnt, nb

日付で並べた場合: 8/446 ブロックを読む（98.2% を飛ばす）
並べていない場合: 446/446 ブロックを読む（0.0% を飛ばす）
  直近  1日:    1/446 読む = 飛ばす割合 99.8%
  直近  7日:    3/446 読む = 飛ばす割合 99.3%
  直近 30日:    8/446 読む = 飛ばす割合 98.2%
  直近 90日:   23/446 読む = 飛ばす割合 94.8%
  直近365日:   90/446 読む = 飛ばす割合 79.8%

日付で並べた場合は、公式の「最大で98%」とほぼ同じ 98.2% を飛ばせました。並べていないと、どのブロックにも全期間の日付が混ざるので、1つも飛ばせません。よく範囲で絞る列（日時など）をソートキーにするのはこのためです。

行指向のデータベースで似た効果を出す手段は索引やパーティションです。PostgreSQL での方法は、関連記事「PostgreSQLパーティション入門｜宣言的パーティショニングのDDLと運用」で扱っています。次の節では、Serverless とプロビジョンドの違いを仕様の表で比べます。

Redshift Serverlessとプロビジョンドの違い

この節では、Serverless とプロビジョンドクラスター（RG・RA3）の違いと、それぞれの上限が分かります。

Serverless は「RPU」という単位で計算の大きさを決め、プロビジョンドは「ノードの種類×台数」で決めます。1 RPU は 16GB のメモリにあたります。

Serverless の小さな構成の注意

管理ガイドは、4 RPU の構成について次の制限を挙げています。

• マネージドストレージは 32TB まで、1つのテーブルの列は100列まで、メモリは 64GB
• 一度 4 RPU を超えて大きくなると、4 RPU には戻らない
• 8・16 RPU はマネージドストレージ 128TB まで。128TB を超えるデータは最低 32 RPU

また、新しい Serverless のワークグループでは「価格と性能の目標（price-performance target）」が既定で有効になり、「Balanced」に設定されます。公式は、この AI による自動の拡大・最適化は基本容量 8〜512 RPU の範囲で使うことを勧めています。

プロビジョンドのノードの種類（RG・RA3）

管理ガイドの表から、よく使われる大きさを抜き出しました。

2026年5月12日の発表では、RG は AWS Graviton を使ったノードで、データウェアハウスとデータレイク（Apache Iceberg・Parquet）の処理が「前の世代の RA3 より最大2.4倍速く、vCPU あたりの価格は30%低い」とされています（AWS の公表値）。既存の RA3 クラスターは、スナップショットからの復元やリサイズで RG に移せると案内されています。管理ガイドは、性能・データの大きさ・増え方に応じて RG か RA3 を選ぶことを勧めています。

AWS には、同じ「サーバーレス」の名前を持つデータベースもあります。業務のデータベース向けの Aurora Serverless v2 の容量の決め方は、関連記事「Aurora Serverless v2の使い方｜ACUの決め方と0への自動停止」で扱っています。次の節では、Redshift の料金を公式の単価から試算します。

Amazon Redshiftの料金｜RPU時間・ストレージを試算

この節では、Redshift の料金の内訳と、Serverless・プロビジョンドの月額の目安が、公式の単価からの計算で分かります。

Serverless の料金は「計算（RPU 時間）＋ストレージ（GB 月）」です。料金ページの例で使われている米国東部（バージニア北部）の単価は、1 RPU 時間 0.375 ドル、マネージドストレージ 1GB 月 0.024 ドルです（2026年11月13日時点。東京リージョンの単価はページの本文に載っていなかったため、料金ページのリージョンの選択か AWS Pricing Calculator で確かめる）。

まず公式の計算例を再現する

料金ページには「128 RPU で1日 8,190 秒動いた場合、1日 109.20 ドル」という例があります。同じ計算をして一致を確かめました。

RPU = 0.375
print(f"{128 * 8190 / 3600 * RPU:.2f} USD/日")

== 公式の計算例の再現: 128 RPU x 8,190秒/日
109.20 USD/日

Serverless の月額の目安（30日・ストレージ別）

この表は基本容量のまま動いた場合の計算です。負荷が高いと Serverless は容量を自動で増やし、公式の説明では増えた分も同じ RPU 単価で請求されます。上限は「最大容量」と「最大 RPU 時間」で決められ、公式は思わぬ料金を防ぐために最大 RPU 時間の設定を勧めています。

プロビジョンドとの分かれ目

料金ページの例にある rg.4xlarge（米国東部 1時間 3.04267 ドル）を2台、730時間動かすと月 4,442.30 ドルです。Serverless が1日何時間動くと同じ金額になるかを計算しました。

== プロビジョンド rg.4xlarge x2 を730時間
4,442.30 USD/月
== 損益分岐（1日あたり何時間動けば同額か）
   8 RPU: 49.4 時間/日
  32 RPU: 12.3 時間/日
 128 RPU: 3.1 時間/日

8 RPU は24時間動いても届かない計算ですが、8 RPU と rg.4xlarge 2台は処理の力が同じではないので、金額だけで比べられるものではありません。「1日に動く時間が短く、空き時間が長いなら Serverless、ほぼ一日中クエリが流れるならプロビジョンドを候補にする」という分かれ目を、自分の基本容量で計算して確かめるのが確実です。

60秒の最低課金と、まとめて流す効果

公式によると、Serverless は秒単位で計測し、最低60秒分を請求します。1回15秒のクエリが1日200回、ばらばらに来て毎回60秒分の請求になると仮定した場合と、まとめて流した場合を比べました（8 RPU・仮定の計算）。

ばらばらに来る(毎回60秒): 12,000秒/日 -> 300.00 USD/月
まとめて流す: 3,000秒/日 -> 75.00 USD/月

定期の集計をまとめて実行する、BI ツールの自動更新の間隔を見直す、といった工夫で、請求される時間は変わります。

そのほかの料金

• ストレージ：100GB で月 2.40 ドル、1TB（1,000GB）で月 24.00 ドル（米国東部の例の単価で計算）。
• Redshift Spectrum：S3 のデータを読んだ量で、米国東部の例は 1TB あたり 5.00 ドル（1クエリ最低10MB）。1TB の CSV を毎日全部読むと月 150 ドル、Parquet で列を絞って1/20だけ読めば月 7.50 ドルの計算です。
• 同時実行スケーリング（プロビジョンド）：クラスターごとに1日最大1時間分の無料のクレジットがたまり、最大30時間まで。Serverless には別の料金はありません。
• Serverless の予約：1年で最大24%、3年で最大45%安くなると料金ページに書かれています。
• 無料トライアル：Serverless をはじめて使う人に 300 ドルのクレジット（90日で失効）。米国東部の単価なら 800 RPU 時間、8 RPU で100時間分の計算です。Serverless の無い地域では、プロビジョンドの2か月の無料トライアルがあります。

料金や条件は変わることがあります。この記事の数字は「2026年11月13日時点の公式の例の単価で計算したもの」として使い、使う前に料金ページで最新の値を確かめるのが確実です。次の節では、はじめて触るときの手順を公式のガイドに沿って並べます。

Redshiftの始め方｜Serverlessでサンプルデータを集計する

この節では、公式の「はじめての人向け」の手順に沿って、Serverless を作ってサンプルデータを集計するまでの流れが分かります。

前提として、3つのアベイラビリティーゾーンにまたがる3つのサブネットを持つ VPC が要ります（使える IP アドレスが3つ以上）。この記事の環境では AWS に接続していないため、以下は公式ガイドの記載をまとめたものです。

同じ SQL を手元の PostgreSQL で動かした結果

公式ガイドに載っているサンプルの SQL（購入数の上位10人、売上の上位0.1%のイベント）を、tickit に似た形の架空のデータ（会員5,000人・イベント2,000件・販売20万行）で PostgreSQL 16 に流しました。データは自作なので、結果の中身は Redshift のサンプルとは違います。

-- Find top 10 buyers by quantity.
SELECT firstname, lastname, total_quantity
FROM   (SELECT buyerid, sum(qtysold) total_quantity
        FROM  sales
        GROUP BY buyerid
        ORDER BY total_quantity desc limit 10) Q, users
WHERE Q.buyerid = userid
ORDER BY Q.total_quantity desc;

 firstname | lastname | total_quantity
-----------+----------+----------------
 First2176 | Last2176 |            162
 First3322 | Last3322 |            158
 First857  | Last857  |            157
 First1158 | Last1158 |            156
 First501  | Last501  |            156
 ...
(10 rows)

-- Find events in the 99.9 percentile in terms of all time gross sales.
SELECT eventname, total_price
FROM  (SELECT eventid, total_price, ntile(1000) over(order by total_price desc) as percentile
       FROM (SELECT eventid, sum(pricepaid) total_price
             FROM   sales
             GROUP BY eventid)) Q, event E
       WHERE Q.eventid = E.eventid
       AND percentile = 1
ORDER BY total_price desc;

 eventname  | total_price
------------+-------------
 Event 820  |    71734.27
 Event 1221 |    69811.04
(2 rows)

集計・結合・ウィンドウ関数（ntile）といった分析の SQL は、PostgreSQL でもそのまま動きました。ウィンドウ関数の書き方は、関連記事「SQLウィンドウ関数の使い方｜累計・前月比・上位N件を実行結果で解説」で扱っています。次の節では、自分のデータを Redshift に入れる方法を見ます。

データの入れ方｜COPY・ゼロETL・Spectrum

この節では、Redshift にデータを入れる主な3つの方法と、それぞれの向き不向きが分かります。

Redshift への読み込みは、1行ずつの INSERT ではなく、COPY でまとめて入れるのが基本です。デベロッパーガイドは、COPY を S3 と DynamoDB からの読み込みに特化した命令として説明しています。

COPY の基本の形は次のとおりです（公式の構文。IAM_ROLE default はクラスターやワークグループに既定の IAM ロールを付けている場合の書き方）。

COPY sales
FROM 's3://example-bucket/sales/2026/11/'
IAM_ROLE default
FORMAT AS PARQUET;

COPY users
FROM 's3://example-bucket/users.csv'
IAM_ROLE default
FORMAT AS CSV
IGNOREHEADER 1;

• 区切りを指定しない場合、COPY は UTF-8 の「|」区切りのテキストを想定します。CSV なら FORMAT AS CSV を付けます。
• 1行の大きさは、どの読み込み元でも最大 4MB です。
• COPY には、読み込み先の表への INSERT の権限が要ります。

S3 へのファイルの置き方は、関連記事「AWS S3コマンド一覧｜cp・sync・ls実行例とオプション早見表」で扱っています。次の節では、PostgreSQL に慣れた人がつまずきやすい方言の違いを、実際のエラーで確かめます。

PostgreSQLとの違い｜方言のエラーを手元で確かめる

この節では、Redshift と PostgreSQL の SQL の違いのうち、移すときに気づきにくいものが、公式の一覧と手元のエラー原文で分かります。

Redshift は PostgreSQL をもとにしていますが、OLTP 向けの機能の多くを外しています。デベロッパーガイドには「サポートされていない PostgreSQL の機能」「データ型」「関数」の一覧があります。

Redshift の構文を PostgreSQL で実行した結果

Redshift 用の CREATE TABLE を PostgreSQL 16 に流すと、Redshift 固有の語のところで構文エラーになります。Redshift から手元の PostgreSQL にテストを移すときに出る原文です。

psql:diff.sql:1: ERROR:  syntax error at or near "DISTSTYLE"
LINE 1: ...rs (salesid int, buyerid int, saletime timestamp) DISTSTYLE ...
                                                             ^
psql:diff.sql:2: ERROR:  syntax error at or near "DISTKEY"
LINE 1: CREATE TABLE sales_rs2 (salesid int, buyerid int DISTKEY, sa...
                                                         ^
psql:diff2.sql:5: ERROR:  syntax error at or near "IDENTITY"
LINE 1: CREATE TEMP TABLE idt (id int IDENTITY(1,1), name varchar(10...
                                      ^
psql:diff2.sql:7: ERROR:  syntax error at or near "ENCODE"
LINE 1: CREATE TEMP TABLE e (id int) ENCODE AUTO;
                                     ^

PostgreSQL での連番は GENERATED BY DEFAULT AS IDENTITY と書くと通りました。

VARCHAR の長さ：文字数とバイト数の違い

PostgreSQL の VARCHAR(5) には、日本語5文字（15バイト）が入りました。6文字以上はエラーです。

     s      | chars | bytes
------------+-------+-------
 データ分析 |     5 |    15

psql:diff2.sql:4: ERROR:  value too long for type character varying(5)

Redshift の VARCHAR はバイト数で数えるので、公式の例では VARCHAR(12) に入るのは「1バイト文字なら12文字、3バイト文字なら4文字」です。UTF-8 の日本語は多くが1文字3バイトなので、PostgreSQL と同じ長さの定義のまま移すと、Redshift では約3分の1の文字数しか入りません。日本語の列は、文字数×3 を目安に長さを決めます。

主キーの重複と末尾の空白

psql:diff.sql:4: ERROR:  duplicate key value violates unique constraint "users_pkey"
DETAIL:  Key (userid)=(1) already exists.

 trailing_space_equal
----------------------
 f

PostgreSQL は主キーの重複を止め、'abc ' と 'abc' を別の値として扱いました。公式の説明では、Redshift は主キーを強制せず、VARCHAR の比較で末尾の空白を無視します。重複を防ぐ処理は、読み込みの手順（一時テーブルに入れてから重複を除いて本表に入れる、など）の側で持つ必要があります。

次の節では、ここまでの違いから起きやすいつまずきを表にまとめます。

よくあるエラー／つまずき

この節では、Redshift を使い始めたときに起きやすいつまずきの、症状・原因・直し方が分かります。

Python UDF については、AWS の公式ブログが2025年6月30日に、2026年6月30日でサポートを終えると発表し、ライブラリを使わないものは SQL UDF への置き換えを、それ以外は Lambda UDF への移行を勧めています。次の節では、Redshift を選ぶかどうかの判断を表にまとめます。

判断表｜Redshiftを選ぶ場面・ほかを考える場面

この節では、手元の状況から Redshift・ほかの AWS のサービス・いまのデータベースのどれを考えるかが、判断表で分かります。

1. 1集計がいまのデータベースで間に合っている → そのまま使う数百万行までの集計は、索引やパーティションで足りることが多い
2. 2集計が業務の処理を遅くしている → 分析用に分けるリードレプリカか DWH を検討する段階
3. 3S3 のファイルをときどき SQL で読みたい → Athena や Spectrumデータを読み込まずに、読んだ量で払う
4. 4複数のデータを集めて、毎日決まった集計・BI に使う → Redshift利用が日中の数時間なら Serverless から
5. 5一日中クエリが流れ、量の見通しが立つ → プロビジョンド（RG・RA3）予約で単価を下げる選択肢もある

テーブルを作る前の確認

• 1よく絞る列はどれか日時で範囲を絞るならソートキーの候補。迷えば SORTKEY AUTO
• 2大きな表どうしを何で結合するか結合の列が分散キーの候補。種類が少ない列・偏る列は避ける
• 3日本語の列の長さはバイトで足りるか文字数×3 バイトを目安に VARCHAR の長さを決める
• 4重複をどこで防ぐか主キーは強制されないので、読み込みの手順で重複を除く
• 5料金の上限を決めたかServerless は最大容量と最大 RPU 時間を設定する

よくある質問

この節では、Amazon Redshift について検索されることの多い疑問に短く答えます。

Q. Redshift の読み方は？
「レッドシフト」です。天文学で、遠ざかる天体の光の波長が長い方（赤い方）へずれる現象「赤方偏移」を表す英語と同じ綴りです。

Q. Redshift は何に使うサービスですか？
売上・会員・アクセスログなど、複数のシステムのデータを集めて、SQL で大量に集計するために使います。業務のデータベースの代わりではなく、分析専用の置き場です。

Q. Redshift Serverless に無料枠はありますか？
Serverless をはじめて使う人には、90日で失効する 300 ドルのクレジットがあると料金ページに書かれています（2026年11月13日時点）。米国東部の単価なら 800 RPU 時間分です。

Q. Serverless の最小の大きさはいくつですか？
4 RPU です。ただし 4 RPU は保存 32TB・1表100列までなどの制限があり、一度4 RPU を超えると4 RPU には戻りません。公式の課金の説明には、使える地域では低い基本容量として 8 RPU を使う、という趣旨の記載もあります。

Q. Redshift と PostgreSQL は同じ SQL で動きますか？
集計・結合・ウィンドウ関数などの分析の SQL は多くがそのまま動きます（この記事でも公式のサンプル SQL が PostgreSQL 16 で動きました）。一方、DDL の DISTKEY・SORTKEY・IDENTITY(1,1) は PostgreSQL では構文エラーになり、PostgreSQL の索引・トリガー・シーケンスは Redshift にはありません。

Q. Redshift にインデックスは無いのですか？
ありません。公式の「サポートされていない PostgreSQL の機能」に索引が入っています。代わりに、ソートキー（ブロックの最小値・最大値で読み飛ばす）と分散キー（行の置き場所）で速くします。

Q. DC2 ノードはまだ選べますか？
2026年11月13日時点の管理ガイドのノードの表は RG と RA3 だけで、公式は性能やデータの大きさに応じて RG か RA3 を選ぶことを勧めています。DC2 のクラスターを使っている場合は、管理ガイドの移行の案内を確かめるのが確実です。

Q. Redshift と Athena の違いは？
Redshift はデータを自分の保存領域に入れて、列指向・分散・ソートで速く集計するデータウェアハウスです。Athena は S3 のファイルを読み込まずにクエリし、読んだ量で払います。毎日決まった集計を速く回すなら Redshift、ときどき S3 を調べるなら Athena や Spectrum、という分け方が基本です。

Q. 東京リージョンの料金はいくらですか？
2026年11月13日に確かめた料金ページの本文には、東京リージョンの単価が載っていませんでした。東京の単価は、料金ページでリージョンを選ぶか AWS Pricing Calculator で確かめるのが確実です。この記事の試算は米国東部の例の単価です。

Q. Redshift のデータを使わないときに料金を止められますか？
Serverless はクエリが動いていない間、計算の料金が増えません（ストレージの料金は続きます）。ただし、開いたままのトランザクションや接続プールの死活確認は RPU を使うと公式に書かれています。

Q. ソートキーと分散キーは後から変えられますか？
公式ドキュメントでは、ALTER TABLE で分散スタイルを変えられる場合があり、変えられない場合はディープコピー（新しい表を作って入れ直す）で作り直す、と案内されています。AUTO にしておけば、Redshift がデータの大きさに応じて変えます。

まとめ

この節では、Amazon Redshift の要点を5つにまとめます。

• Amazon Redshift は AWS のフルマネージドなデータウェアハウスで、業務のデータベース（OLTP）とは別に置く集計専用の場所です。
• 速さの中心は列指向と MPP。1億行・100列から5列を読む計算では、読む量は 80GB から 4GB（5%）に減り、PostgreSQL（行指向）では1列の合計でも表全体の 10,032 ページを読みました。
• 分散キーとソートキーで速さが変わる。偏った分散キーは1つのスライスに約5倍の行を集め、日付で並べると直近30日のクエリで 98.2% のブロックを飛ばせました。
• 料金は Serverless なら RPU 時間＋ストレージ。米国東部の例で 1 RPU 時間 0.375 ドル、8 RPU で1日1時間なら月 90 ドル。一日中動くならプロビジョンド（RG・RA3）との比較を計算で確かめます。
• PostgreSQL がもとでも別物。索引・トリガー・シーケンスは無く、主キーは強制されず、VARCHAR はバイト数です。移すときは DDL と重複の防ぎ方を作り直します。

参考・出典

この節では、この記事で確かめた公式の資料を一覧で示します（確認日 2026年11月13日）。

• AWS「What is Amazon Redshift?」：https://docs.aws.amazon.com/redshift/latest/mgmt/welcome.html
• AWS「Amazon Redshift pricing」：https://aws.amazon.com/redshift/pricing/
• AWS「Billing for Amazon Redshift Serverless」：https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-billing.html
• AWS「Understanding Amazon Redshift Serverless capacity」：https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-capacity.html
• AWS「Amazon Redshift provisioned clusters（ノードの種類）」：https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html
• AWS「Amazon Redshift launches RG instances powered by AWS Graviton」（2026年5月12日）：https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-redshift-rg-instances-powered-by-graviton/
• AWS「Columnar storage」：https://docs.aws.amazon.com/redshift/latest/dg/c_columnar_storage_disk_mem_mgmnt.html
• AWS「Distribution styles」：https://docs.aws.amazon.com/redshift/latest/dg/c_choosing_dist_sort.html
• AWS「Sort keys」：https://docs.aws.amazon.com/redshift/latest/dg/t_Sorting_data.html
• AWS「CREATE TABLE」：https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_TABLE_NEW.html
• AWS「SVV_TABLE_INFO」：https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_TABLE_INFO.html
• AWS「Amazon Redshift and PostgreSQL」：https://docs.aws.amazon.com/redshift/latest/dg/c_redshift-and-postgres-sql.html
• AWS「Unsupported PostgreSQL features」：https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-features.html
• AWS「Unsupported PostgreSQL data types」：https://docs.aws.amazon.com/redshift/latest/dg/c_unsupported-postgresql-datatypes.html
• AWS「Features that are implemented differently」：https://docs.aws.amazon.com/redshift/latest/dg/c_redshift-sql-implementated-differently.html
• AWS「Character types」：https://docs.aws.amazon.com/redshift/latest/dg/r_Character_types.html
• AWS「COPY」：https://docs.aws.amazon.com/redshift/latest/dg/r_COPY.html
• AWS「Zero-ETL integrations」：https://docs.aws.amazon.com/redshift/latest/mgmt/zero-etl-using.html
• AWS「Amazon Redshift Spectrum」：https://docs.aws.amazon.com/redshift/latest/dg/c-using-spectrum.html
• AWS「Get started with Amazon Redshift Serverless data warehouses」：https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html
• AWS Big Data Blog「Amazon Redshift Python user-defined functions will reach end of support after June 30, 2026」：https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。