n8nでクローリング管理するなら？Googleスプレッドシート vs SQLite vs Supabase 徹底比較

Webスクレイピングやデータクローリングの自動化にn8nを使用している皆さん、クローリング済みURLの履歴をどこに保存するかで悩んでいませんか？データベース選択は、プロジェクトの規模・予算・技術レベルによって大きく異なります。このガイドでは、Googleスプレッドシート、n8n Data Tables、SQLite、Supabase、NocoDBという5つの選択肢を、実装の容易さ・コスト・パフォーマンスで徹底比較し、あなたに最適なソリューションを見つけるお手伝いをします。

1. なぜデータベース選択が重要か

データベースとは、何か：特定の情報を整理・保存・検索するための仕組みのこと。Excelのような表計算ソフトも簡易的なデータベースですが、本格的なデータベースはそれより高速で、大量のデータに対応しています。

n8nを使ったクローリングでは、毎日のように新しい URL や取得内容を記録していきます。この履歴が増え続けると、保存先のパフォーマンスが低下し、ワークフローの実行が遅くなります。正しいデータベースを選択することで、3～6ヶ月後も快適に運用できる基盤が整うのです。

選択ポイントは、大きく3つです。

1. パフォーマンス：データが増えても処理速度が落ちないか
2. コスト：毎月いくらかかるか、無料で使えるか
3. 操作性：セットアップが簡単か、後で手動確認が必要なときに使いやすいか

この3つのバランスを考えて、最適な選択肢を探していきましょう。

選択肢1：Googleスプレッドシート

メリット：圧倒的な構築の簡単さと無料性

Googleスプレッドシートは、多くの人にとって最も身近なツールです。ここからスタートすることをおすすめします。

セットアップの簡単さ：Googleアカウントを持っていれば、すぐに新しいスプレッドシートを作成できます。n8nとの連携も「Google Sheets」ノードを追加するだけで、複雑な認証設定なしに動作を開始できます。

無料：ストレージ容量は15GB。クローリング履歴の保存であれば、数年使用しても容量を超えることはまずありません。

手動確認が容易：URLが本当にクローリングされたか、内容は正しいか、などの確認を手動で行いやすい。スプレッドシートUIで直接編集・検索が可能です。

自動バックアップ：Googleのサーバーに自動保存されるため、データ消失のリスクが非常に低い。

デメリット：データが増えると失速する

ここが重要です。Googleスプレッドシートのパフォーマンスには限界があります。

実際のベンチマーク結果：500行のデータをn8nで処理する場合、n8n Data Tablesなら15秒で完了しますが、Googleスプレッドシートでは600秒（10分以上）かかります。これは約40倍の遅さです。

さらに、行数が増えるほど悪化します：

1,000行：まだ耐えられる
5,000行以上：明らかな遅延を感じ始める
25,000行：ほぼ使用不可能なレベル

毎日クローリングを実行する場合、1年で365件のレコードが追加されます。3年運用すれば1,000行を超えます。特にn8nでの自動処理の際、API速度の遅さやレート制限に引っかかる可能性があります。

実装例

Googleスプレッドシートをn8nで使う基本的な方法：

ステップ1：Googleスプレッドシートを作成し、「URL」「取得日時」「ステータス」といった列ヘッダーを設定。

ステップ2：n8nで「Google Sheets」ノードを追加。Googleアカウントで認証。

ステップ3：「Append」オプションで新しい行を追加するよう設定。

{
  "range": "Sheet1!A:D",
  "values": [
    ["https://example.com", "2025-11-17", "success"]
  ]
}

ステップ4：ワークフローを実行して、スプレッドシートにデータが追加されることを確認。

推奨される使用期間・規模

テスト運用フェーズ：最初の3～6ヶ月間
データ規模：1,000～3,000行程度
クローリング対象：小～中規模サイト（1日50～100URL程度）
ユーザーが多く確認・修正する場合：Sheets UIが使いやすいため、複数人で結果を確認するプロジェクト

コスト目安

\$0/月（無料、Googleアカウント保有者）

選択肢2：n8n Data Tables

新機能：n8n内蔵のデータベース

n8n Data Tablesは、n8nに組み込まれたシンプルなデータベース機能です。最近充実した機能で、小規模プロジェクトに非常に適しています。

メリット：高速で操作が簡単

Google Sheetsより約40倍高速：前述の通り、500行のデータ処理が15秒で完了します。毎日のクローリングが高速に実行されます。

認証不要：外部サービスとの連携がなく、n8n内で完結。Google APIの遅延やレート制限の影響を受けません。

セットアップが極めて簡単：n8nのウォークフローエディタで「Create Data Table」を選択するだけ。テーブル名を入力して、カラムを定義。最短1分で開始できます。

APIレート制限なし：Google Sheetsと異なり、大量リクエストによる制限を心配する必要がありません。

デメリット：容量制限と探索性の低さ

50MBの容量上限：1テーブルあたり最大50MB。1年間毎日クローリング×300ページ分の履歴（約100,000行）を保存すると、容量超過の可能性があります。

データ探索機能が弱い：スプレッドシートのような検索・フィルター機能がUIに備わっていません。1ページ50項目表示という制限もあり、過去のデータを手動で探し出すのが手間です。

手動編集が困難：n8n UIでの直接編集が制限的。データの修正や削除に手間がかかります。

バックアップが手動：Data Tableを別ファイルにエクスポートするワークフローを自分で構築する必要があります。

コスト（クラウド利用時）：n8n Cloudを使用する場合、最小プランで\$20/月から。自ホストなら無料ですが、VPS代別。

実装例

n8nでData Tableを作成・使用する手順：

ステップ1：n8nのワークフローエディタで、ノードを追加。

ステップ2：「Create Data Table」を選択。テーブル名を「Crawl_History」に設定。

ステップ3：カラムを定義。

url (Text)
crawled_date (DateTime)
status (Text: success/failed)
content_length (Number)

ステップ4：クローリング後、「Insert Rows」ノードでデータを追加。

{
  "table": "Crawl_History",
  "data": {
    "url": "https://example.com/page",
    "crawled_date": "2025-11-17T09:00:00Z",
    "status": "success",
    "content_length": 15342
  }
}

推奨される使用期間・規模

一時的なデータ管理：参照テーブルや中間データの一時保存
データサイズ：10MB未満
速度を最優先：処理速度が非常に重要なプロジェクト
n8n完全管理希望：外部サービスに依存せず、n8n内で完結させたい

コスト目安

n8n Cloud：\$20/月～
自ホスト（VPS）：\$10～30/月（VPS代別）

選択肢3：SQLite

本格的だが軽量：自ホスト環境での無料データベース

SQLiteは、軽量で無料のデータベース。n8nを自分のサーバーにインストールする場合に、デフォルトで利用できます。

メリット：完全無料、プライバシー確保

無料：SQLiteはオープンソース。n8nを自ホストすれば、SQLiteも使用料0円です。

データ所有権：クローリングデータを自分のサーバー内に保存。GoogleやSupabaseなど外部サービスに依存しません。完全な所有権とプライバシーが得られます。

パフォーマンス：PostgreSQLより劣りますが、単一ワークフローでの利用なら十分実用的。Googleスプレッドシートとは比較にならないレベルで高速です。

セットアップ：n8nをDocker Composeなどでデプロイすれば、SQLiteは自動設定。追加の管理は不要です。

デメリット：技術的難易度と並行処理の限界

VPSホスティングコスト：n8nを動かすためのサーバーが必要。Digital Ocean、Linode、AWS等で最小構成を\$5～8/月程度で借りられますが、これが毎月発生します。

技術的な管理が必要：Linuxコマンドの基本知識、Docker、ネットワーク設定などが必須。初心者には高いハードルです。

並行処理に弱い：複数のn8nワークフローが同時実行される場合、SQLiteはロック競合が発生する可能性。大規模運用には向きません。

バックアップの手動化：定期的にSQLiteデータベースファイルをバックアップするスクリプトを自分で構築・管理する必要があります。

実装例

SQLiteをn8nで使う基本的な手順：

ステップ1：n8nをDocker Composeで自ホスト。

version: '3'
services:
  n8n:
    image: n8nio/n8n
    environment:
      - DB_TYPE=sqlite
      - DB_SQLITE_PATH=/root/.n8n/database.sqlite
    ports:
      - "5678:5678"
    volumes:
      - n8n_data:/root/.n8n

ステップ2：n8nワークフロー内で「SQLite」ノードを追加。

ステップ3：テーブル作成クエリを実行：

CREATE TABLE IF NOT EXISTS crawl_history (
  id INTEGER PRIMARY KEY,
  url TEXT,
  crawled_date DATETIME,
  status TEXT,
  content_length INTEGER
);

ステップ4：クローリング後、データ挿入：

INSERT INTO crawl_history (url, crawled_date, status, content_length)
VALUES ($1, $2, $3, $4);

推奨される使用期間・規模

初期～中期プロジェクト：3～24ヶ月の運用
規模：小～中規模のスクレイピング業務
対象者：Linux/Dockerの基本知識がある技術者
データプライバシー重視：外部サービスを使いたくない場合

コスト目安

VPS代：\$5～8/月
初期構築：技術コスト（1～2時間程度の作業）

選択肢4：Supabase

本格運用向け：PostgreSQL SaaSの決定版

Supabaseは、PostgreSQLをクラウドで簡単に利用できるサービス。中～大規模プロジェクトや本格的な運用に最適です。

メリット：スケーラビリティと豊富な機能

無料ティア：500MBのデータベース、1GB のストレージが無料。1～2年分のクローリング履歴なら余裕で収容できます。

PostgreSQL ベース：本格的なRelational Database。複雑なクエリ、複数テーブルの結合、集約関数など、高度なデータ分析に対応。

並行処理能力：SQLiteと異なり、複数ワークフローが同時実行されても安定動作。大規模運用向き。

n8n連携：n8nで直接サポートされたノードが存在。HTTP API経由での接続も可能。

セキュリティ：Row-Level Security (RLS) で、ユーザーごとにアクセス権限を細粒度制御可能。

自ホストも可能：Dockerコンテナで自分のサーバーにデプロイ可能。SaaSに依存したくない場合のオプションあり。

デメリット：セットアップ難易度と長期コスト

無料ティアの制限：リソース制限がある。非常に大規模な継続的なクローリングには向かない可能性。

有料プラン移行：無料ティアから有料へ移行する際、最小プランで\$25/月から。SQLiteと異なり、長期運用でコストが発生します。

技術知識が前提：SQL知識がない場合、テーブル設計やクエリ作成が難しい。Googleスプレッドシートやn8n Data Tablesより習得コストが高い。

実装例

Supabaseをn8nで使う手順：

ステップ1：Supabase公式サイトでアカウント作成。無料プロジェクト作成。

ステップ2：SQL Editorでテーブル作成：

CREATE TABLE crawl_history (
  id BIGINT PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,
  url TEXT NOT NULL,
  crawled_date TIMESTAMPTZ DEFAULT NOW(),
  status TEXT CHECK (status IN ('success', 'failed')),
  content_length INTEGER,
  created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_url ON crawl_history(url);
CREATE INDEX idx_date ON crawl_history(crawled_date);

ステップ3：n8nで「Supabase」ノードを追加。API Keyを入力して認証。

ステップ4：データ挿入設定：

Operation: Insert Rows
Table: crawl_history
Data: {
  "url": "https://example.com",
  "status": "success",
  "content_length": 15342
}

推奨される使用期間・規模

中～大規模プロジェクト：複数サイト、継続的クローリング
長期運用：1年以上の継続を前提
分析機能が必要：クローリング結果の分析やレポーティング
対象者：SQLの基本知識がある、またはそれを学びたい人

コスト目安

初期：\$0/月（無料ティア）
成長段階：\$25/月（有料ティア移行時）

選択肢5：NocoDB / Baserow

新選択肢：Google Sheetsの進化版？

NocoDB・Baserowは、ノーコードなデータベース UI を提供。Google Sheetsのような使いやすさを維持しつつ、PostgreSQL/SQLite/MySQLなどの本格的なデータベースを背後に持ちます。

メリット：使いやすさと拡張性

UI体験：Google Sheetsライク。スプレッドシート感覚で操作可能。初心者にも親しみやすい。

オープンソース：NocoDBは完全オープンソース。自ホスト可能で、費用を最小化できます。

n8n統合：直接ノード存在。連携が簡単。

複雑なビュー：Kanbanボード、ギャラリー、カレンダービューなど、複数の表示方法をサポート。単なる表示だけでなく、複雑なフォームやビューを構築可能。

デメリット：セットアップ複雑、パフォーマンス不確定

自ホスト時の複雑さ：セットアップに Docker と技術知識が必要。

有料SaaS：SaaSホスティングを選ぶ場合、\$5～/月の費用。

パフォーマンス不確定：他のSaaS製品より安定性・パフォーマンスが不確定な場合あり。

実装例

NocoDBを使う基本的な手順：

ステップ1：NocoDB SaaS にサインアップ、またはDocker Composeで自ホスト。

ステップ2：新しいベースを作成。PostgreSQL接続情報を入力。

ステップ3：テーブル「crawl_history」を作成。カラムはGUIで設定。

ステップ4：n8nで「NocoDB」ノード追加。認証後、行挿入設定。

推奨される使用期間・規模

ノーコード重視：SQLやコマンドラインを避けたい
複雑なUIが必要：単なるテーブルでなく、Kanbanボードやギャラリービューが欲しい
小～中規模：初期段階のプロジェクト

コスト目安

自ホスト：\$5～10/月（VPS代）
SaaS：無料～\$5/月

あなたに最適な選択肢を見つける

どの選択肢を選ぶべきか、プロジェクトの特性ごとにまとめました。

パターン①：「とりあえず試したい」→ Googleスプレッドシート

最初の3～6ヶ月のテスト運用なら、Googleスプレッドシートで十分です。セットアップ時間は5分。費用0円。コストをかけずに、クローリング自動化の全体像を理解しましょう。

数ヶ月運用して「これから長期で続ける」と判断してから、他の選択肢への移行を検討します。

パターン②：「速度優先、n8nだけで完結したい」→ n8n Data Tables

n8nを自ホストしている、かつ小～中規模のデータ（<50MB）の場合。高速処理が必須なら Data Tables が活躍。ただし容量超過のリスク注意。

パターン③：「技術に強い、プライバシー重視」→ SQLite

VPS借りて、n8n自ホスト環境が整っている技術者向け。完全な所有権とプライバシーが得られます。毎月\$5～8の VPS 代のみ。

パターン④：「本格的に長期運用、分析も視野」→ Supabase

複数サイトの継続的クローリングを1年以上続ける予定なら、Supabase がおすすめ。無料ティアで始まり、成長に応じてスケーリング。データ分析機能も充実。

パターン⑤：「UI操作性を重視、複雑なビューが欲しい」→ NocoDB

Google Sheetsのような使いやすさが必須だが、もっと高性能なデータベースをバックエンドに使いたい。こんな要望に応えます。

実装時の比較表

各選択肢を一覧で比較：

特性	Googleスプレッドシート	n8n Data Tables	SQLite	Supabase	NocoDB
セットアップ時間	5分	5分	30分～1時間	15分	20～30分
月額コスト	\$0	\$20～	\$5～8	\$0～25	\$0～5
処理速度	遅（600秒/500行）	高速（15秒/500行）	高速	高速	中速
容量上限	15GB	50MB	無制限	無料：1GB	制限あり（自ホスト時：無制限）
UI操作性	優秀	シンプル	SQLコマンド必要	SQLコマンド必要	優秀
データ探索性	優秀	弱い	コマンド必要	SQL必要	優秀
並行処理	弱い	中程度	弱い	優秀	中程度
自ホスト可能	✗	✓（有料）	✓（無料）	✓	✓
推奨運用期間	3～6ヶ月	1～12ヶ月	3ヶ月～数年	1年～	1～12ヶ月

トラブルシューティング：よくある失敗と対処法

「Googleスプレッドシートが遅くなった」

原因：行数が5,000～10,000を超えている可能性が高い。

対処法：

短期的：古いデータを別シートにアーカイブ
中期的：SQLiteやSupabaseへ移行を検討

「n8n Data Tablesが容量超過エラー」

原因：50MBの容量限界に達成。

対処法：

古いデータを削除またはエクスポート
より大容量のオプション（SQLite/Supabase）への移行

「SQLiteのセットアップがわからない」

原因：Docker、Linux知識が必要。

対処法：

公式ドキュメント参照：n8n Self-hosted
技術者に相談、またはSupabaseなどのSaaS選択を検討

まとめ：今から始めるべき第一歩

クローリング履歴の管理は、プロジェクト規模と技術レベル、予算に応じて最適な選択肢が異なります。重要なのは、まず始めることです。

次に試すべきこと

1. 決定プロセス：上記の「パターン①～⑤」から自分に最も近いパターンを選択。

2. 試験運用：選んだツールで実際に1～2週間試してみる。実際に動かして初めて、その選択肢の良さと課題が見えます。

3. 監視と評価：処理速度、操作の手間、コストを記録。3ヶ月後に「次のステップへ移行するべきか」判断。

4. 移行計画：もし途中で別の選択肢に乗り換える必要があれば、データ移行スクリプトを用意。複数データベース間でのマイグレーション方法は、公式ドキュメントやコミュニティで情報が豊富です。

初心者なら Googleスプレッドシート→n8n Data Tables→Supabase という段階的なステップアップをおすすめします。この流れなら、技術知識を段階的に深めながら、スムーズにスケーリングできます。

目次

1. なぜデータベース選択が重要か

選択肢1：Googleスプレッドシート

メリット：圧倒的な構築の簡単さと無料性

デメリット：データが増えると失速する

実装例

推奨される使用期間・規模

コスト目安

選択肢2：n8n Data Tables

新機能：n8n内蔵のデータベース

メリット：高速で操作が簡単

デメリット：容量制限と探索性の低さ

実装例

推奨される使用期間・規模

コスト目安

選択肢3：SQLite

本格的だが軽量：自ホスト環境での無料データベース

メリット：完全無料、プライバシー確保

デメリット：技術的難易度と並行処理の限界

実装例

推奨される使用期間・規模

コスト目安

選択肢4：Supabase

本格運用向け：PostgreSQL SaaSの決定版

メリット：スケーラビリティと豊富な機能

デメリット：セットアップ難易度と長期コスト

実装例

推奨される使用期間・規模

コスト目安

選択肢5：NocoDB / Baserow

新選択肢：Google Sheetsの進化版？

メリット：使いやすさと拡張性

デメリット：セットアップ複雑、パフォーマンス不確定

実装例

推奨される使用期間・規模

コスト目安

あなたに最適な選択肢を見つける

パターン①：「とりあえず試したい」→ Googleスプレッドシート

パターン②：「速度優先、n8nだけで完結したい」→ n8n Data Tables

パターン③：「技術に強い、プライバシー重視」→ SQLite

パターン④：「本格的に長期運用、分析も視野」→ Supabase

パターン⑤：「UI操作性を重視、複雑なビューが欲しい」→ NocoDB

実装時の比較表

トラブルシューティング：よくある失敗と対処法

「Googleスプレッドシートが遅くなった」

「n8n Data Tablesが容量超過エラー」

「SQLiteのセットアップがわからない」

まとめ：今から始めるべき第一歩

次に試すべきこと

コメントする 返信をキャンセル

コメントする返信をキャンセル