データベース接続

スプレッドシートが最速の入り口ですが、実際のデータの多くはデータベースに住んでいます。Tablize はそれに直接接続します — レプリケーションも ETL パイプラインも中間ウェアハウスもなしで。

裏で行っているのは、Tablize に読み取り専用の認証情報を渡すこと。Agent は質問のたびに、あなたのデータベースに対してライブで SQL を発行します。データは自分の住処を離れません。

対応エンジン

エンジン	備考
PostgreSQL	バージョン 12 以降、すべて。すでに導入済みの TimescaleDB、PostGIS、pgvector 拡張で動作。
MySQL / MariaDB	MySQL 5.7+ または MariaDB 10.4+。全文検索インデックス対応。
Supabase	マネージド Postgres — Supabase ダッシュボードからプールされた接続文字列を取得。セルフホスト PG と同じように動作。
SQLite	.sqlite または .db ファイルをアップロード（ファイルをアップロードを参照）。Tablize がコピーをホスト。
Snowflake、BigQuery、Redshift	生の接続文字列ではなく統合経由 — ウェアハウスの癖は独自ページに値します。

推奨: 読み取り専用ロールを作成

Tablize は書き込みアクセスを必要としません。本番データベースには専用ロールを作成してください:

-- Postgres
CREATE ROLE tablize_reader WITH LOGIN PASSWORD '<strong-password>';
GRANT CONNECT ON DATABASE your_db TO tablize_reader;
GRANT USAGE ON SCHEMA public TO tablize_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO tablize_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO tablize_reader;

このロールの認証情報を接続文字列に使用してください。Agent は頼まれても DROP や UPDATE はできません — Tablize ではなくデータベースが強制します。

Agent に書き込みさせたい場合（CRUD が必要な生成 App など）は、特定のテーブルだけに INSERT / UPDATE / DELETE を付与してください。共有接続に広範な書き込みアクセスを与えないでください。

接続

ワークスペース → Integrations → Database → 接続文字列を貼り付け。Tablize が受け入れるフォーマット:

postgresql://user:pass@host:5432/dbname
postgres://user:pass@host:5432/dbname?sslmode=require
mysql://user:pass@host:3306/dbname

Test connection をクリック。Tablize が SELECT 1 を実行し、サーバーバージョンと見えるスキーマを返します。通れば Save をクリック。

保存時、Tablize はイントロスペクトします:

• ロールが見えるすべてのスキーマ。
• すべてのテーブル、ビュー、マテリアライズドビュー。
• すべてのカラムの型、デフォルト、NULL 許容性。
• プライマリキーと外部キー — 自動 JOIN に活用。

これで Agent はあなたのデータベースのマップを持ちました。最初の質問ができます。

ネットワーク要件

Tablize Cloud はブラウザではなく当社サーバーからあなたのデータベースに到達します。到達可能にする 3 つのオプション:

• TLS 付き公開エンドポイント。 最もシンプル。ほとんどのマネージド DB（Supabase、Neon、RDS）はデフォルトでこれを出荷。URL に sslmode=require を使用。
• IP 許可リスト。 静的な送信元 IP リストを公開しています — ファイアウォールやセキュリティグループに追加してください。サインアップ後にコンソール IP 許可リストページを参照。
• リバーストンネル（Max プラン）。 公開エンドポイントのないデータベース向けに、ネットワーク内で走らせて Tablize へのアウトバウンド接続を開く小さなエージェントを提供。インバウンドルール不要。

セルフホスト Tablize では、データベースは Tablize ホストから到達可能であれば十分。プライベートネットワーク、bind-mount、何でもどうぞ。

大規模データベース

Tablize はデータをコピーしませんが、速度のためにクエリ結果をキャッシュします。約 100 GB 超のデータベース向け:

• Agent にサンプルヒントを与える。 初接続時、どのテーブルが頻繁にクエリされ、どれがそうでないかを伝えてください。クエリパターンを絞ります。
• パーティション化されたテーブルを使う。 すでに日付パーティションがあれば、Agent はパーティションを尊重 — 「先週」のために全表スキャンしません。
• 読み取りレプリカを検討。 プライマリが負荷に敏感なら、Tablize をレプリカに向けてください。1 分未満のレプリケーション遅延はほぼすべての用途で問題なし。

複数データベース

好きなだけ接続できます — Postgres 本番 1 つ、MySQL レガシー 1 つ、サイドプロジェクト用の Supabase 1 つ。Agent はあなたが言及したテーブルやデータベース名から正しいものを選びます。

クロスデータベース JOIN は Postgres の Foreign Data Wrapper を使用 — アドホック JOIN には十分速く、重い JOIN ワークロードのための適切なウェアハウスの代替ではありません。毎日クロスデータベース JOIN をするなら、軽量ウェアハウスを検討してそれを接続してください。

Agent ができること、できないこと

できる:

• ロールが SELECT できる任意のテーブル / ビューを読み取り。
• スキーマの説明、探索的 SQL の作成、EXPLAIN プランの生成。
• データの上に Dashboard と App を構築（読み取り専用 App）。
• データベースをスケジュールでクエリする Script と Watch を実行。

できない:

• 読み取り専用テーブルへの書き戻し。Tablize ではなく、あなたのデータベースロールが強制します。
• マイグレーションや ALTER TABLE を実行。書き込み権限があってもスキーマ変更は設計上スコープ外 — マイグレーションツールを使用してください。
• 接続が消えた場合のデータ保持。キャッシュされていないクエリはデータベースの可用性を必要とします。キャッシュされたものは無効化されるまで残ります。

よくある落とし穴

• SSL 失敗。 最も一般的なエラーは SSL connection required — ?sslmode=require を追加。あるいはまれに、自己署名証明書なら sslmode=no-verify。
• 接続プール枯渇。 DB の max_connections が小さい場合、Tablize のプーリングがアプリと競合する可能性。pgbouncer を使うか Tablize をレプリカにルーティング。
• 特定テーブルで permission denied。 ロールはシステムカタログをイントロスペクトし、SELECT できないテーブルも含まれます。SELECT を付与するか、接続オプションの --exclude でテーブルを除外。
• タイムゾーン不整合。 Agent が「火曜」と言うのにあなたが「月曜」だと思うなら、ロールの timezone を確認。明示的に設定してください。

次のステップ

• Webhook と API — アプリが生成するがまだデータベースにないデータ向け。
• 統合 — 同期を自分で組みたくない SaaS データ向け。
• 質問する — データベースが繋がったので、何か聞いてみましょう。