Supabase CLI のコマンド (v1.93.0)

履歴

Supabase CLI のコマンド (v1.93.0) - Qiita
Supabase CLI のコマンド (v1.28.3) - Qiita
Supabase CLI のコマンド (v1.8.7) - Qiita

CLIドキュメント

Supabase CLI のコマンド (v1.93.0)

Supabase cliの更新

scoop update supabase

用語

• バニティサブドメイン
  Supabase プロジェクトの URL に含まれるサブドメインのことです。
  既存のドメインに文字列を追加することで、新しいアドレスを作成する機能の一種です。

例えば、既存のドメイン「example.com」に対して、「blog.example.com」のようなサブドメインを作成することができます。
サブドメインは、本ドメインとは別個のサイトを新たに構築できますが、本ドメインのブランド価値やSEO評価を引き継ぐことが可能です。

https://my-project.supabase.co の my-project 部分がバニティサブドメインになります。バニティサブドメインを設定することで、プロジェクトの URL をカスタマイズすることができます。

• カスタムドメイン
  SupabaseプロジェクトのURLをカスタマイズすることができる機能のことで、プロジェクトのURLを独自のドメインに変更することができます。

バニティサブドメインとカスタムドメインは、互いに排他的な機能であり、バニティサブドメインを使用する場合はカスタムドメインを使用することはできません。

バニティサブドメインの長所は、プロジェクトのURLを簡単にカスタマイズできることであり、プロジェクトのURLが短くなるため、入力しやすくなります。

バニティサブドメインを使用する場合は、プロジェクトのURLがSupabaseのドメインを含むことになるため、ブランディングに影響を与える可能性があります。

• シングルサインオン (SSO) 認証

複数のアプリケーションやサービスに対して、1つの認証情報を使用してログインすることができる認証方式のことです。

Supabase では、SSO 認証を使用して、Google や GitHub などのアカウントを使用してログインすることができます。

主な項目

• プロジェクトと組織の管理

• データベース管理

• データベースのマイグレーションとデータベースの分岐

• データベースデバッグツール

• エッジ機能の管理

• 認証管理

• 型ジェネレーター

• テスト

---

CLI 基本的なコマンド

Global flags

Supabase CLIは各コマンドのグローバルフラグをサポートしています。

• Flags
  デバッグログを標準エラー出力します。

--dns-resolver <[ native | https ]>
指定したリゾルバを使ってドメイン名を検索します。

--experimental
実験的機能を有効にします。

-h, --help
supabaseのヘルプです。

--workdir
Supabaseプロジェクトのディレクトリへのパスを指定します。

$ supabase init

Supabase ローカル開発のための設定を初期化します。

supabase/config.toml ファイルが現在の作業ディレクトリに作成されます。この設定は各ローカルプロジェクトに固有です。

環境変数 SUPABASE_WORKDIR または --workdir フラグを指定することで、ディレクトリパスを上書きすることができます。

ディレクトリ supabase には config.toml の他に、migrations, functions, tests などの Supabase オブジェクトを置くことができます。

• Flags

--with-vscode-workspace
VSCodeのワークスペースを生成します。

$ supabase login

個人アクセストークンを使ってログインし、Supabase CLIをあなたのSupabaseアカウントに接続します。

アクセストークンはnative credentials storageに安全に保存されます。ネイティブアクセストークンが利用できない場合は、プレーンテキストファイル ~/.supabase/access-token に書き込まれます。

CI 環境などでこの動作を望まない場合は、他のコマンドで環境変数 SUPABASE_ACCESS_TOKEN を指定することでログインをスキップすることができます。

Supabase CLI は保存されたトークンを使って、プロジェクト、関数、シークレットなどの管理APIにアクセスします。

$ supabase link

ローカルの開発プロジェクトを、ホストされているSupabaseプロジェクトにリンクします。

PostgRESTの設定がSupabaseプラットフォームから取得され、ローカルの設定ファイルと照合されます。

オプションで、パスワードを指定するとデータベースの設定を検証できます。データベースのパスワードは、利用可能であればネイティブの認証情報ストレージに保存されます。

CI 環境などでデータベースパスワードの入力を要求されたくない場合は、環境変数 SUPABASE_DB_PASSWORD で明示的に指定することができます。

db dump、db push、db remote commit などのコマンドは、プロジェクトを最初にリンクする必要があります。

• Flags

-p, --password

--project-ref

$ supabase start

Supabaseのローカル開発スタックを起動します。

supabase init を実行して supabase/config.toml をカレントディレクトリに作成しておく必要があります。

デフォルトでは全てのサービスコンテナが起動されます。フラグ -x を渡すことで、不要なコンテナを除外することができます。複数のコンテナを除外するには、-x gotrue,imgproxy のようにカンマ区切りの文字列を渡すか、-x フラグを複数回指定します。

すべてのサービスを起動するには、少なくとも 7GB の RAM が必要です。

起動したコンテナを確認するために、ヘルスチェックが自動的に追加されます。これらのエラーを無視するには --ignore-health-check フラグを使用します。

• Flags

-x, --exclude

--ignore-health-check
異常なサービスを無視して 0 を終了します

$ supabase stop

Supabaseのローカル開発スタックを停止します。

supabase initを実行してsupabase/config.toml` がカレントディレクトリに作成されている必要があります。

すべての Docker リソースは再起動後も維持されます。再起動時にローカル開発データをリセットするには --no-backup フラグを使用します。

• Flags

--no-backup

$ supabase status

Supabase のローカル開発スタックの状態を表示します。

ローカル開発スタックが supabase start または supabase db start を実行して起動している必要があります。

-o env フラグを指定することで、supabase-js の初期化 用の接続パラメータをローカルにエクスポートすることができます。サポートされているパラメータは JWT_SECRET、ANON_KEY、SERVICE_ROLE_KEY です。

• Flags

-o, --output <\[ env | pretty | json | toml | yaml \]>

--override-name

$ supabase test

ローカルの Supabase コンテナでテストを実行します。

• Available Commands
  • $ supabase test db
  • $ supabase test new

$ supabase test db

ローカルデータベースに対して pgTAP テストを実行します。
supabase start を実行してローカルの開発スタックを起動する必要があります。

コンテナ内で pg_prove を実行し、ユニットテストファイルを supabase/tests ディレクトリからマウントします。テストファイルの拡張子の末尾には .sql または .pg を付けます。

各テストは独自のトランザクションでラップされますので、成功したか失敗したかにかかわらず、個別にロールバックされます。

$ supabase test new

新しいテストファイルを作成します。

• Flags

-t, --template <\[ pgtap \]>

$ supabase gen

コード生成ツールを実行します。

• Available Commands
  • $ supabase gen keys
  • $ supabase gen types

$ supabase gen keys

プレビューブランチ用のキーを生成します。

• Flags

-o, --output <\[ env | json | toml | yaml \]>

--override-name
特定の変数名を上書きします。

--project-ref

$ supabase gen types

Postgres スキーマから型を生成します。

• Available Commands

• $ supabase gen types typescript

• supabase gen types typescript

TypeScript用の型を生成します。local、-linked、-project-id、-db-urlのいずれかを指定する必要があります。

• Flags

--db-url
データベースの URL から型を生成します。

--linked
リンクされたプロジェクトから型を生成します。

--local
ローカルのdevデータベースから型を生成します。

--project-id
プロジェクトIDから型を生成します。

--schema
型を生成するスキーマ。

Postgresデータベースの管理

$ supabase db

Postgresデータベースの管理をします。

• Available Commands
  • $ supabase db pull
  • $ supabase db push
  • $ supabase db reset
  • $ supabase db dump
  • $ supabase db diff
  • $ supabase db lint
  • $ supabase db start

$ supabase db pull

スキーマの変更をリモートデータベースから取得します。

ローカルプロジェクトが supabase link を実行してリモートデータベースにリンクされている必要があります。

セルフホストデータベースの場合は、--db-url フラグを使用して接続パラメータを渡すことができます。

オプションで、マイグレーション履歴テーブルに新しい行を挿入して、リモートデータベースの現在の状態を反映させることができます。

マイグレーション履歴テーブルにエントリが存在しない場合、作成したリモートスキーマのすべての内容を取得するために pg_dump を使用します。そうでない場合、このコマンドは db diff --linked を実行するのと同じように、リモートデータベースに対するスキーマの変更の差分のみを取得します。

• Flags

-p, --password
リモートPostgresデータベースのパスワード。

-s, --schema
含めるスキーマのリスト。

--db-url
指定されたデータベースURLを用いて接続します。

$ supabase db push

すべてのローカルマイグレーションをリモートデータベースにプッシュします。

ローカルプロジェクトが supabase link を実行してリモートデータベースにリンクされている必要があります。セルフホストデータベースの場合は、--db-url` フラグを使用して接続パラメータを渡すことができます。

このコマンドを初めて実行すると、 supabase_migrations.schema_migrations の下にマイグレーション履歴テーブルが作成されます。

マイグレーションの適用に成功すると、タイムスタンプを一意なIDとしてマイグレーション履歴テーブルに新しい行が挿入されます。それ以降のプッシュでは、すでに適用されたマイグレーションはスキップされます。

マイグレーションを実際に実行することなく、既存のエントリを削除したり、新しいエントリを挿入したりするなど、マイグレーション履歴テーブルを変更する必要がある場合は、 migration repair コマンドを使用してください。

適用する前に変更点のリストを見るには --dry-run フラグを使います。

• Flags

--dry-run
適用されるマイグレーションを表示しますが、実際には適用しません。

--include-all
リモートの履歴テーブルにないすべてのマイグレーションを含めます。

--include-roles
supabase/roles.sqlからカスタムロールを含めます。

--include-seed
supabase/seed.sqlからシードデータを含める。

-p, --password
リモートPostgresデータベースのパスワード。

--db-url
指定したデータベースの URL で接続します。

$ supabase db reset

ローカルデータベースをクリーンな状態にリセットします。

ローカルの開発スタックが supabase start を実行して起動されている必要があります。

ローカルの Postgres コンテナを再作成し、supabase/migrations ディレクトリにあるすべてのローカルマイグレーションを適用します。

テストデータが supabase/seed.sql で定義されている場合、マイグレーション実行後にシードされます。ローカル開発中に行われたその他のデータやスキーマの変更は破棄されます。

Postgresのロールはクラスタレベルのエンティティであるため、これらの変更はリセット後も持続することに注意してください。

カスタムロールをリセットするには、ローカル開発スタックを再起動する必要があります。

• Flags

デフォルト値ではローカルをリセットします。

--linked
リンクされたプロジェクトを現在のマイグレーションにリセットします。

--version
指定したバージョンまでリセットします。

--db-url
指定されたデータベースURLを用いて接続します。

supabase db reset --linked

$ supabase db dump

ローカルプロジェクトが supabase link を実行してリモートデータベースにリンクされている必要があります。
セルフホストデータベースの場合は、--db-url フラグを使用して接続パラメータを渡すことができます。

Supabase が管理しているスキーマを除外するフラグを追加して、コンテナ内で pg_dump を実行します。

無視されるスキーマは、認証スキーマ、ストレージスキーマ、拡張機能で作成されたスキーマが含まれます。

デフォルトのダンプにはデータやカスタムロールは含まれません。これらの内容を明示的にダンプするには、--data-onlyフラグと--role-onlyフラグのどちらかを指定します。

• Flags

--data-only
データレコードのみをダンプします。

--dry-run
実行されますpg_dumpスクリプトを表示します。

-f, --file
ダンプされた内容を保存するファイルパス。

--keep-comments
pg_dump出力からコメント行を保持します。

-p, --password
リモートPostgresデータベースのパスワード。

--role-only
クラスタ・ロールのみをダンプします。

-s, --schema
含めるスキーマのリスト。

--use-copy
挿入の代わりにコピー文を使用します。

--db-url
指定したデータベースの URL で接続します。

使用例
supabase db dump --data-only -f データバックアップ

$ supabase db diff

ローカルあるいはリモートのデータベースに対するスキーマの変更の差分を取得します。

ローカルデータベースに対して diff を実行する場合は、ローカルの開発スタックが動作している必要があります。

リモートデータベースまたはセルフホストデータベースに対して diff を実行するには、それぞれ --linked フラグまたは --db-url フラグを指定します。

コンテナ内で djrobstep/migra を実行し、ターゲットデータベースとシャドウデータベースのスキーマの違いを比較します。

シャドウデータベースは、別コンテナ内のローカル supabase/migrations ディレクトリにあるマイグレーションを適用して作成されます。

出力はデフォルトで標準出力に書き出されます。便宜上、-f フラグを渡すことで、スキーマの差分を新しいマイグレーションファイルとして保存することもできます。

デフォルトでは、ターゲットデータベース内のすべてのスキーマが差分されます。スキーマのサブセットに差分を制限するには --schema public,extensions フラグを使用します。

diffコマンドはほとんどのスキーマの変更を取り込むことができますが、失敗するケースもあります。
現在のところ、スキーマに以下の内容が含まれている場合に発生する可能性があります：

• パブリケーションに対する変更
• ストレージバケットへの変更
• security_invoker`属性を持つビュー

• Flags
  接続文字列で指定されたデータベースに対してローカルのマイグレーションファイルを差分します (パーセントエンコードされている必要があります)。

-f, --file
スキーマ差分を新しいマイグレーションファイルに保存します。

--linked
リンクされたプロジェクトに対してローカルのマイグレーションファイルを差分します。

--local
ローカルデータベースに対してローカルのマイグレーションファイルを差分します。

-s, --schema
含めるスキーマのリスト。

--use-migra
スキーマ差分を生成するためにmigraを使用します。

--use-pgadmin
pgAdminを使用してスキーマの差分を生成します。

$ supabase db lint

スキーマエラーのためにローカルデータベースをリントします。

ローカルデータベースに対してlintを行う場合、ローカルの開発スタックが動作している必要があります。
リモートデータベースやセルフホストデータベースに対してリントを行うには、それぞれ --linked フラグまたは --db-url フラグを指定します。

ローカルの Postgres コンテナで plpgsql_check 拡張を実行して、すべてのスキーマのエラーをチェックします。デフォルトの lint レベルは warning で、--level フラグでエラーにすることができます。

特定のスキーマに対してのみ lint を行うには、 --schema フラグを指定します。

• Flags

--level <\[ warning | error \]>
出力するエラー・レベル。

--linked
スキーマエラーのためにリンクされたプロジェクトをリントします。

-s, --schema
インクルードするスキーマのリスト。

--db-url
指定したデータベースの URL で接続します。

• lintとは
  ソースコードの静的解析を行い、潜在的なエラーやバグを検出するためのツールです。
  lint は、コードの品質を向上させるために使用され、コードの可読性や保守性を高めることができます。データベースのスキーマに潜在的なエラーやバグがないかを検出するために使用されます。

$ supabase db start

ローカルの Postgres データベースを起動します。

• Flags

--db-url
型なし 指定したデータベースの URL で接続します。

$ supabase migration

データベースマイグレーションスクリプトを管理します。

• Available Commands
  • $ supabase migration new
  • $ supabase migration list
  • $ supabase migration repair
  • $ supabase migration squash
  • $ supabase migration up

$ supabase migration new

ローカルに新しいマイグレーションファイルを作成します。

現在の workdir に supabase/migrations ディレクトリが存在しない場合は、そのディレクトリが作成されます。

すべてのスキーママイグレーションファイルはこのディレクトリに <timestamp>_<name>.sql というパターンで作成する必要があります。

db diffのような他のコマンドからの出力は標準入力を使ってmigration new ` に渡すことができます。

$ supabase migration list

ローカルとリモートのデータベースのマイグレーション履歴を一覧表示します。

ローカルプロジェクトが supabase link を実行してリモートデータベースにリンクされている必要があります。
セルフホストデータベースの場合は、--db-url フラグを使用して接続パラメータを渡すことができます。

URL 文字列は RFC 3986 に従ってエスケープする必要があることに注意してください。

ローカルのマイグレーションは supabase/migrations ディレクトリに格納され、リモートのマイグレーションは supabase_migrations.schema_migrations テーブルに格納されます。

タイムスタンプだけを比較して、差異を特定します。
ローカルとリモートのマイグレーション履歴に相違がある場合は、migration repair コマンドを使って解決することができます。

• Flags

--db-url
指定したデータベースURLを用いて接続します。

-p, --password
リモートPostgresデータベースへのパスワード。

$ supabase migration repair

リモートのマイグレーション履歴テーブルを修復します。
ローカルプロジェクトが supabase link を実行してリモートデータベースにリンクされている必要があります。

ローカルとリモートのマイグレーション履歴が同期しなくなった場合、特定のマイグレーションを --status applied または --status reverted としてマークすることで、リモートのマイグレーション履歴を修復することができます。

reverted とマークするとマイグレーション履歴テーブルから既存のレコードが削除され、applied とマークすると新しいレコードが挿入されます。

例えば、初めて db remote commit を実行した後のマイグレーション履歴テーブルは以下のようになります。

$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
    20230103054303 │ 20230103054303 │ 2023-01-03 05:43:03

マイグレーション履歴をクリーンな状態にリセットするには、まずローカルのマイグレーションファイルを削除します。

$ rm supabase/migrations/20230103054303_remote_commit.sql
$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────
                   │ 20230103054303 │ 2023-01-03 05:43:03

マイグレーション履歴をクリーンな状態にリセットするには、まずローカルのマイグレーションファイルを削除します。

$ supabase migration repair 20230103054303 --status reverted
Repaired migration history: 20230103054303 => reverted
$ supabase migration list
        LOCAL      │     REMOTE     │     TIME (UTC)
  ─────────────────┼────────────────┼──────────────────────

これで db remote commit を再度実行して、リモートスキーマをローカルのマイグレーションファイルとしてダンプできます。

• Flags

--db-url
指定したデータベースURLを用いて接続します。

-p, --password
リモートPostgresデータベースへのパスワード。

--status <\[ applied | reverted \]>

$ supabase migration squash

マイグレーションを単一のファイルにまとめます。

• Flags

--db-url
指定されたデータベースURLを使用して接続します。

--linked
リンクされたプロジェクトのマイグレーション履歴を更新します。

-p, --password

リモートPostgresデータベースのパスワード。

--version
指定したバージョンまでスカッシュします。

※スカッシュ
マイグレーションファイルをまとめる事、圧縮するという意味があります。

$ supabase migration up

保留中のマイグレーションをローカルデータベースに適用します。

ローカルにまだマイグレーションファイルが無い場合でも普通に成功します。

• Flags

--include-all
リモートの履歴テーブルにないすべてのマイグレーションを含めます。

$ supabase inspect db

Supabase データベースを検査するツールです。

• Available Commands

• $ supabase inspect db calls
• $ supabase inspect db long running queries
• $ supabase inspect db outliers
• $ supabase inspect db blocking
• $ supabase inspect db locks
• $ supabase inspect db total index size
• $ supabase inspect db index sizes
• $ supabase inspect db index usage
• $ supabase inspect db unused indexes
• $ supabase inspect db total table sizes
• $ supabase inspect db table sizes
• $ supabase inspect db table index sizes
• $ supabase inspect db cache hit
• $ supabase inspect db table record counts
• $ supabase inspect db seq scans
• $ supabase inspect db replication slots
• $ supabase inspect db role connections
• $ supabase inspect db bloat
• $ supabase inspect db vacuum stats

$ supabase inspect db calls

このコマンドは supabase inspect db outliers コマンドとよく似ていますが、ステートメントが呼び出された回数順に並びます。

この情報を使って、どのクエリが最も頻繁に呼び出されているのかを確認することができます。

                        QUERY                      │ TOTAL EXECUTION TIME │ PROPORTION OF TOTAL EXEC TIME │ NUMBER CALLS │  SYNC IO TIME
  ─────────────────────────────────────────────────┼──────────────────────┼───────────────────────────────┼──────────────┼──────────────────
    SELECT * FROM users WHERE id = $1              │ 14:50:11.828939      │ 89.8%                         │  183,389,757 │ 00:00:00.002018
    SELECT * FROM user_events                      │ 01:20:23.466633      │ 1.4%                          │       78,325 │ 00:00:00
    INSERT INTO users (email, name) VALUES ($1, $2)│ 00:40:11.616882      │ 0.8%                          │       54,003 │ 00:00:00.000322

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db long-running-queries

このコマンドは現在実行中のクエリのうち、5分以上実行されているものを実行時間の長い順に表示します。
非常に長い時間実行されているクエリは、DDL文が完了しなかったり、バキュームが relfrozenxid を更新できなかったりといった複数の問題の原因となる可能性があります。

  PID  │     DURATION    │                                         QUERY
───────┼─────────────────┼───────────────────────────────────────────────────────────────────────────────────────
 19578 | 02:29:11.200129 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1450645 LIMIT 1
 19465 | 02:26:05.542653 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1889881 LIMIT 1
 19632 | 02:24:46.962818 | EXPLAIN SELECT  "students".* FROM "students"  WHERE "students"."id" = 1581884 LIMIT 1

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db outliers

このコマンドは pg_stat_statements から取得したステートメントを実行時間順に表示します。
これには、ステートメント自体、そのステートメントの総実行時間、そのステートメントが全ステートメントの総実行時間に占める割合、そのステートメントが呼び出された回数、そのステートメントが同期I/O（ファイルシステムからの読み書き）に費やした時間が含まれます。

通常、効率的なクエリは、総実行時間に対する呼び出しの割合が適切で、I/Oに費やされます時間はできるだけ少なくなります。

総実行時間は長いが、呼び出し回数が少ないクエリは、パフォーマンスを向上させるために調査する必要があります。
また、同期I/Oに費やされます実行時間の割合が高いクエリも調査する必要があります。

                 QUERY                   │ EXECUTION TIME   │ PROPORTION OF EXEC TIME │ NUMBER CALLS │ SYNC IO TIME
─────────────────────────────────────────┼──────────────────┼─────────────────────────┼──────────────┼───────────────
 SELECT * FROM archivable_usage_events.. │ 154:39:26.431466 │ 72.2%                   │ 34,211,877   │ 00:00:00
 COPY public.archivable_usage_events (.. │ 50:38:33.198418  │ 23.6%                   │ 13           │ 13:34:21.00108
 COPY public.usage_events (id, reporte.. │ 02:32:16.335233  │ 1.2%                    │ 13           │ 00:34:19.784318
 INSERT INTO usage_events (id, retaine.. │ 01:42:59.436532  │ 0.8%                    │ 12,328,187   │ 00:00:00
 SELECT * FROM usage_events WHERE (alp.. │ 01:18:10.754354  │ 0.6%                    │ 102,114,301  │ 00:00:00

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db blocking

このコマンドは現在ロックを保持し、ブロックしているステートメントとブロックされているステートメントを表示します。
これは inspect db locks と併用することで、ロックの競合を解決するためにどのステートメントを終了させる必要があるかを判断することができます。

    BLOCKED PID │ BLOCKING STATEMENT           │ BLOCKING DURATION │ BLOCKING PID │ BLOCKED STATEMENT                                                                      │ BLOCKED DURATION
  ──────────────┼──────────────────────────────┼───────────────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────────────┼───────────────────
    253         │ select count(*) from mytable │ 00:00:03.838314   │        13495 │ UPDATE "mytable" SET "updated_at" = '2023─08─03 14:07:04.746688' WHERE "id" = 83719341 │ 00:00:03.821826

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db locks

このコマンドは、あるリレーションに対して排他ロックをかけたクエリを表示します。
排他ロックは通常、そのリレーションに対する他の操作の実行を妨げ、ロックが許可されますのを待っている "ハング "クエリの原因となります。

非常に長い時間ハングしていたり、ブロッキングの問題を引き起こしている問い合わせがある場合、データベースに接続して SELECT pg_cancel_backend(PID); を実行して問い合わせをキャンセルし、問い合わせを停止させることを検討してください。

それでも問い合わせが停止しない場合は、SELECT pg_terminate_backend(PID);を実行して強制的に停止させることができます。

     PID   │ RELNAME │ TRANSACTION ID │ GRANTED │                  QUERY                  │   AGE
  ─────────┼─────────┼────────────────┼─────────┼─────────────────────────────────────────┼───────────
    328112 │ null    │              0 │ t       │ SELECT * FROM logs;                     │ 00:04:20

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db total-index-size

このコマンドはデータベース上の全てのインデックスの合計サイズを表示します。
ページ数 (relpages で報告されます) にページサイズ (8192 バイト) を掛けて計算されます。

    SIZE
  ─────────
    12 MB

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db index-sizes

このコマンドはデータベースの各インデックスのサイズを表示します。
これはページ数 (relpages で報告されます) にページサイズ (8192 バイト) を掛けて計算されます。

              NAME              │    SIZE
  ──────────────────────────────┼─────────────
    user_events_index           │ 2082 MB
    job_run_details_pkey        │ 3856 kB
    schema_migrations_pkey      │ 16 kB
    refresh_tokens_token_unique │ 8192 bytes
    users_instance_id_idx       │ 0 bytes
    buckets_pkey                │ 0 bytes

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db index-usage

このコマンドはインデックスの効率に関する情報を提供し、総スキャン数の何パーセントがインデックススキャンであったかを示します。
この割合が低い場合は、インデックスの作成が不十分であるか、誤ったデータがインデックス化されている可能性があります。

       TABLE NAME     │ PERCENTAGE OF TIMES INDEX USED │ ROWS IN TABLE
  ────────────────────┼────────────────────────────────┼────────────────
    user_events       │                             99 │       4225318
    user_feed         │                             99 │       3581573
    unindexed_table   │                              0 │        322911
    job               │                            100 │         33242
    schema_migrations │                             97 │             0
    migrations        │ Insufficient data              │             0

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db unused-indexes

このコマンドは、スキャン回数が50回未満で、サイズが5ページ以上のインデックスを表示します。
このコマンドは一般的に未使用のインデックスを発見するのに便利です。

インデックスがメモリ上のスペースを占有していると、書き込みパフォーマンスだけでなく、読み取りパフォーマンスにも影響を与える可能性があるため、不要または使用されていないインデックスを削除することをお勧めします。

        TABLE        │                   INDEX                    │ INDEX SIZE │ INDEX SCANS
─────────────────────┼────────────────────────────────────────────┼────────────┼──────────────
 public.users        │ user_id_created_at_idx                     │ 97 MB      │           0

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db total-table-sizes

このコマンドはデータベース内の各テーブルの合計サイズを表示します。
これは、各テーブルの pg_table_size() と pg_indexes_size() が返す値の合計です。

pg_catalog と information_schema 内のシステムテーブルは含まれません。

                NAME               │    SIZE
───────────────────────────────────┼─────────────
  job_run_details                  │ 395 MB
  slack_msgs                       │ 648 kB
  emails                           │ 640 kB

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db table-sizes

このコマンドはデータベースの各テーブルのサイズを表示します。これはシステム管理関数 pg_table_size() を使用して計算され、メインデータフォーク、空き領域マップ、可視性マップ、TOASTデータのサイズを含みます。
テーブルのインデックスのサイズは含まれません。

                  NAME               │    SIZE
  ───────────────────────────────────┼─────────────
    job_run_details                  │ 385 MB
    emails                           │ 584 kB
    job                              │ 40 kB
    sessions                         │ 0 bytes
    prod_resource_notifications_meta │ 0 bytes

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db table-index-sizes

このコマンドは各テーブルのインデックスの合計サイズを表示します。
システム管理関数 pg_indexes_size() を使用して計算されます。

                 TABLE               │ INDEX SIZE
  ───────────────────────────────────┼─────────────
    job_run_details                  │ 10104 kB
    users                            │ 128 kB
    job                              │ 32 kB
    instances                        │ 8192 bytes
    http_request_queue               │ 0 bytes

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db cache-hit

このコマンドはバッファキャッシュの効率と、クエリがメモリから読み込むのではなくディスクにヒットする頻度に関する情報を提供します。
インデックス読み取り (index hit rate) とテーブル読み取り (table hit rate) の両方の情報が表示されます。

一般に、キャッシュヒット率が低いデータベースは、メモリからデータを読み出すよりもディスクにアクセスする方が遅いため、パフォーマンスが低下します。
テーブルヒット率が低い場合、RAMが不足している可能性があり、より多くのメモリを搭載した大型のコンピュートアドオンにアップグレードするとよいでしょう。

インデックスのヒット率が低い場合は、より適切なインデックスを追加する余地があることを示しています。

ヒット率は、キャッシュされたブロックとディスクから読み込まれたキャッシュされていないブロックの合計に対する、postgresバッファキャッシュから取得されたテーブルまたはインデックスブロックの数の比率として計算されます。

小規模な計算計画（free、small、medium）では、99%を下回ると問題がある可能性があります。
大規模な計画では、ヒット率は低くなりますが、データはPostgresバッファキャッシュではなくOSキャッシュを使用するため、性能は一定に保たれます。

         NAME      │  RATIO
  ─────────────────┼───────────
    index hit rate │ 0.996621
    table hit rate │ 0.999341

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db table-record-counts

このコマンドはテーブルごとの推定行数を推定行数の降順で表示します。
この推定カウントは n_live_tup から取得したもので、バキューム操作によって更新されます。
n_live_tup の取得方法により、疎なページと密なページでは、実際の行数から大きくずれた推定値が表示されますことがあります。

       NAME    │ ESTIMATED COUNT
  ─────────────┼──────────────────
    logs       │          322943
    emails     │            1103
    job        │               1
    migrations │               0

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db seq-scans

このコマンドは、全てのテーブルに対して記録されたシーケンシャルスキャンの回数を、シーケンシャルスキャンの回数が多い順に表示します。

シーケンシャルスキャンの回数が非常に多いテーブルはインデックスが不足している可能性があり、これらのテーブルから読み込むクエリを調査する価値があるかもしれません。

                  NAME               │ COUNT
  ───────────────────────────────────┼─────────
    emails                           │ 182435
    users                            │  25063
    job_run_details                  │     60
    schema_migrations                │      0
    migrations                       │      0

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db replication-slots

このコマンドはデータベース上で設定されている論理レプリケーションスロットに関する情報を表示します。

スロットがアクティブかどうか、WAL送信プロセスの状態（'startup'、'catchup'、'streaming'、'backup'、'stopping'）、レプリケーションクライアントのアドレス、レプリケーションラグ（GB単位）を表示します。

このコマンドは、レプリケーションの遅延が可能な限り少ないことを確認するのに便利です。

レプリケーションの遅延は、ネットワークの待ち時間の問題、遅いディスクI/O、長いトランザクションの実行、サブスクライバーがWALを十分に速く消費する能力の不足などによって発生します。

                       NAME                    │ ACTIVE │ STATE   │ REPLICATION CLIENT ADDRESS │ REPLICATION LAG GB
  ─────────────────────────────────────────────┼────────┼─────────┼────────────────────────────┼─────────────────────
    supabase_realtime_replication_slot         │ t      │ N/A     │ N/A                        │                  0
    datastream                                 │ t      │ catchup │ 24.201.24.106              │                 45

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db role-connections

このコマンドは各データベースロールのアクティブな接続数を表示し、どのロールが予想以上に接続を消費しているかを調べます。

これはSupabase固有のコマンドです。この内訳はダッシュボードでも見ることができます: https://app.supabase.com/project/_/database/roles

最大アクティブ接続数はインスタンスサイズに依存します(https://supabase.com/docs/guides/platform/compute-add-ons)。手動で許容接続数を[上書き](https://supabase.com/docs/guides/platform/performance#allowing-higher-number-of-connections)することもできますが、お勧めしません。

            ROLE NAME         │ ACTIVE CONNCTION
  ────────────────────────────┼───────────────────
    authenticator             │                5
    postgres                  │                5
    supabase_admin            │                1
    pgbouncer                 │                1
    anon                      │                0
    authenticated             │                0
    service_role              │                0
    dashboard_user            │                0
    supabase_auth_admin       │                0
    supabase_storage_admin    │                0
    supabase_functions_admin  │                0
    pgsodium_keyholder        │                0
    pg_read_all_data          │                0
    pg_write_all_data         │                0
    pg_monitor                │                0

Active connections 12/90

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db bloat

PostgresのMVCCにより、データが更新または削除されますと新しい行が作成され、古い行は見えなくなり、"dead tuples "としてマークされます。

通常、autovaccumプロセスはデッドタプルを非同期に削除します。

時々、autovaccumはテーブルの肥大化を抑えたり防いだりするのに十分な速さで動作できないことがあります。
高い肥大化はクエリを遅くし、過剰なIOPSを引き起こし、データベースのスペースを浪費します。

肥大化率が高いテーブルについては、バキューム処理が十分に速くないか、または他の問題があるかどうかを調査する必要があります。

    TYPE  │ SCHEMA NAME │        OBJECT NAME         │ BLOAT │ WASTE
  ────────┼─────────────┼────────────────────────────┼───────┼─────────────
    table │ public      │ very_bloated_table         │  41.0 │ 700 MB
    table │ public      │ my_table                   │   4.0 │ 76 MB
    table │ public      │ happy_table                │   1.0 │ 1472 kB
    index │ public      │ happy_table::my_nice_index │   0.7 │ 880 kB

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase inspect db vacuum-stats

各テーブルのバキューム動作に関する統計情報を表示します。
PostgresのMVCCにより、データが更新または削除されますと、新しい行が作成され、古い行は見えなくなり、"dead tuples "としてマークされます。

通常、autovaccumプロセスはデッドタプルを非同期的に掃除します。

このコマンドは、最後のバキュームと最後の自動バキュームがいつ行われたか、テーブルの行数、デッド行の数、autovacuumが実行されますかどうかをリストします。

デッド行の数が行数よりもはるかに多い場合、または自動バキュームが期待されているにもかかわらず、しばらく実行されていない場合、これは自動バキュームが追いつかず、バキューム設定を調整する必要があるか、または自動バキュームを完了させるために、より多くの計算またはディスクIOPSが必要であることを示しています。

        SCHEMA        │              TABLE               │ LAST VACUUM │ LAST AUTO VACUUM │      ROW COUNT       │ DEAD ROW COUNT │ EXPECT AUTOVACUUM?
──────────────────────┼──────────────────────────────────┼─────────────┼──────────────────┼──────────────────────┼────────────────┼─────────────────────
 auth                 │ users                            │             │ 2023-06-26 12:34 │               18,030 │              0 │ no
 public               │ profiles                         │             │ 2023-06-26 23:45 │               13,420 │             28 │ no
 public               │ logs                             │             │ 2023-06-26 01:23 │            1,313,033 │      3,318,228 │ yes
 storage              │ objects                          │             │                  │             No stats │              0 │ no
 storage              │ buckets                          │             │                  │             No stats │              0 │ no
 supabase_migrations  │ schema_migrations                │             │                  │             No stats │              0 │ no

• Flags

--db-url
指定したデータベースの URL で接続します。

$ supabase projects

Supabaseプロジェクトの管理をします。

• Available Commands
  • $ supabase projects create
  • $ supabase projects list
  • $ supabase projects api keys

$ supabase projects create

Supabase にプロジェクトを作成します。

• Flags

--db-password
プロジェクトのデータベースパスワード。

-i, --interactive
対話型モードを有効にします。

--org-id
プロジェクトを作成する組織ID。

--plan <\[ free | pro \]>
ニーズに合ったプランを選択します。

--region
最良のパフォーマンスを得るために、あなたの近くの地域を選択します。

$ supabase projects list

ログインユーザがアクセス可能な Supabase プロジェクトの一覧を表示します。

$ supabase projects api-keys

Supabaseプロジェクトの全てのAPIキーをリストアップします。

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase branches

Supabase プレビューブランチを管理します。

• Available Commands
  • $ supabase branches create
  • $ supabase branches list
  • $ supabase branches get
  • $ supabase branches update
  • $ supabase branches delete
  • $ supabase branches disable

$ supabase branches create

リンクされたプロジェクトのプレビューブランチを作成します。

• Flags

--region
ブランチデータベースを配置する地域を選択します。

$ supabase branches list

リンクされたプロジェクトのすべてのプレビューブランチをリストアップします。

• Flags

$ supabase branches get

指定したプレビューブランチの詳細を取得します。

• Flags

$ supabase branches update

プレビューブランチをIDで更新します。

• Flags

--git-branch
関連する git ブランチを変更します。

--name
プレビューブランチの名前を変更します。

$ supabase branches delete

プレビューブランチをIDで削除します。

• Flags

$ supabase branches disable

リンクされたプロジェクトのプレビューブランチを無効にします。

• Flags

$ supabase orgs

Supabase 組織を管理します。

• Available Commands
  • $ supabase orgs create
  • $ supabase orgs list

$ supabase orgs create

ログインユーザの組織を作成します。

$ supabase orgs list

ログインユーザが所属する組織を一覧表示します。

$ supabase functions

Supabase Edgeの関数を管理します。

• Available Commands
  • $ supabase functions new
  • $ supabase functions list
  • $ supabase functions download
  • $ supabase functions serve
  • $ supabase functions deploy
  • $ supabase functions delete

$ supabase functions new

ローカルに新しい関数を作成します。

$ supabase functions list

リンクされているSupabaseプロジェクト内の全ての関数をリストアップします。

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase functions download

リンクされているSupabaseプロジェクトから関数のソースコードを ダウンロードします。

• Flags

--project-ref

Supabaseプロジェクトのプロジェクト参照。

$ supabase functions serve

すべての関数をローカルに実行します。

• Flags

--env-file
Functionの環境に設定するenvファイルへのパス。

--import-map
インポートマップファイルへのパス。

--no-verify-jwt
関数のJWT検証を無効にします。

$ supabase functions deploy

リンクしているSupabaseプロジェクトに関数をデプロイします。

• Flags

--import-map
インポートマップファイルへのパスを指定します。

--no-verify-jwt
関数のJWT検証を無効にします。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase functions delete

リンクされているSupabaseプロジェクトから関数を削除します。これはローカルに関数を削除するものではありません。

• Flags

--project-ref

Supabaseプロジェクトのプロジェクト参照してください。

$ supabase secrets

スーパーベースの secrets を管理します。

• Available Commands
  • $ supabase secrets set
  • $ supabase secrets list
  • $ supabase secrets unset

$ supabase secrets set

リンクしているSupabaseプロジェクトに秘密を設定します。

• Flags

--env-file
.envファイルから秘密を読み込む。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase secrets list

リンクされたプロジェクトの全ての秘密をリストアップします。

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase secrets unset

リンクされているSupabaseプロジェクトの秘密を解除します。

• Flags

--project-ref
Supabase prのプロジェクト参照

$ supabase sso

プロジェクトの シングルサインオン (SSO) 認証を管理します。

• Available Commands
  • $ supabase sso add
  • $ supabase sso list
  • $ supabase sso show
  • $ supabase sso info
  • $ supabase sso update
  • $ supabase sso remove

$ supabase sso add

SupabaseプロジェクトにSSO IDプロバイダへの新しい接続を追加し、設定します。

• Flags

--attribute-mapping-file
SAML 属性とカスタム JWT クレーム間の JSON マッピングを含むファイル。

--domains
追加した ID プロバイダに関連付ける電子メールドメインのカンマ区切りリスト。

--metadata-file

ID プロバイダを記述する SAML 2.0 メタデータ XML 文書を含むファイル。

--metadata-url
ID プロバイダについて記述した SAML 2.0 メタデータ XML 文書を指す URL。

--skip-url-validation
SAML 2.0 メタデータ URL のローカル検証を実行しないかどうか。

-t, --type <\[ saml \]>
ID プロバイダのタイプ（サポートされているプロトコルに従う）。

-o, --output <\[ pretty | json | toml | yaml \]>

--project-ref

Supabase プロジェクトのプロジェクト参照。

$ supabase sso list

SupabaseプロジェクトのSSO IDプロバイダへの接続をすべてリストアップします。

• Flags

-o, --output <\[ pretty | json | toml | yaml \]>

--project-ref
Supabase プロジェクトのプロジェクト参照。

$ supabase sso show

ID プロバイダへの確立された接続に関する情報を提供します。--metadata を使用すると、プロジェクトの設定に保存されている生の SAML 2.0 メタデータ XML ドキュメントを取得できます。

• Flags

--metadata
SAML 2.0 XML メタデータのみを表示します。

-o, --output <\[ pretty | json | toml | yaml \]>

--project-ref
Supabase プロジェクトのプロジェクト参照。

$ supabase sso info

プロジェクトを SAML 2.0 互換の ID プロバイダに登録するために必要な、重要な SSO 情報をすべて返します。

• Flags

-o, --output <\[ pretty | json | toml | yaml \]>

--project-ref
Supabase プロジェクトのプロジェクト参照。

$ supabase sso update

既に追加されているSSO IDプロバイダの設定を更新します。

• Flags

--add-domains
電子メールドメインのコンマ区切りリストをIDプロバイダに追加します。

--attribute-mapping-file

Optional

no type

SAML 属性とカスタム JWT 要求の間の JSON マッピングを含むファイル。

--domains

ドメインを電子メールドメインのコンマ区切りリストで置き換えます。

--metadata-file
ID プロバイダを記述する SAML 2.0 メタデータ XML 文書を含むファイル。

--metadata-url
ID プロバイダについて記述した SAML 2.0 メタデータ XML 文書を指す URLです。

--remove-domains
電子メールドメインのコンマ区切りリストを ID プロバイダから削除します。

--skip-url-validation
SAML 2.0 メタデータ URL のローカル検証を実行しないかどうかを指定します。

-o, --output <\[ pretty | json | toml | yaml \]>

--project-ref
Supabase プロジェクトのプロジェクト参照。

$ supabase sso remove

既に追加されているSSO IDプロバイダへの接続を削除します。
プロバイダを削除すると、既存のユーザはログインできなくなります。このコマンドは慎重に扱ってください。

• Flags

-o, --output <\[ pretty | json | toml | yaml \]>

--project-ref
Supabase プロジェクトのプロジェクト参照。

$ supabase domains

Supabaseプロジェクトのカスタムドメイン名を管理します。
カスタムドメイン と バニティサブドメイン は互いに排他的です。

• Available Commands
  • $ supabase domains activate
  • $ supabase domains create
  • $ supabase domains get
  • $ supabase domains reverify
  • $ supabase domains delete

$ supabase domains activate

プロジェクトのカスタムホスト名の設定を有効にします。

これにより、Supabaseプロジェクトはカスタムホスト名でリクエストに応答するように 再設定されます。
カスタムホスト名が有効化されますと、プロジェクトの認証サービスは Supabaseが提供するサブドメインでは動作しなくなります。

• Flags

--include-raw-output

生の出力を含める(デバッグに便利)。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase domains create

Supabase プロジェクトのカスタムホスト名を作成します。

カスタムホスト名には、Supabaseプロジェクトのサブドメインへの CNAMEレコードが設定されていることを期待します。

• Flags

--custom-hostname
Supabaseプロジェクトで使用するカスタムホスト名。

--include-raw-output
生の出力を含める (デバッグに便利)。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase domains get

Supabaseプラットフォームに保存されている、プロジェクトのカスタムホスト名設定を取得します。

• Flags

--include-raw-output
生の出力を含める (デバッグに便利)。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase domains reverify

プロジェクトのカスタムホスト名設定を再検証します。

• Flags

--include-raw-output
生の出力を含める（デバッグに便利）。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase domains delete

プロジェクトのカスタムホスト名設定を削除します。

• Flags

--include-raw-output

生の出力を含める（デバッグに便利）。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase vanity-subdomains

Supabaseプロジェクトのバニティサブドメインを管理します。
カスタムドメイン と バニティサブドメイン は互いに排他的です。

• Available Commands
  • $ supabase vanity subdomains activate
  • $ supabase vanity subdomains get
  • $ supabase vanity subdomains check availability
  • $ supabase vanity subdomains delete

$ supabase vanity-subdomains activate

Supabaseプロジェクトのバニティサブドメインを有効にします。

これにより、 バニティサブドメイン へのリクエストに応答するように Supabaseプロジェクトを再設定します。
バニティサブドメイン を有効にすると、プロジェクトの認証サービスは {project-ref}.{supabase-domain} ホスト名では機能しなくなります。

• Flags

--desired-subdomain
Supabaseプロジェクトに使用する バニティサブドメイン を指定します。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase vanity-subdomains get

現在のバニティサブドメインを取得します。

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase vanity-subdomains check-availability

希望するサブドメインが使用可能かどうかをチェックします。

• Flags

--desired-subdomain
Supabaseプロジェクトで使用するバニティサブドメインを指定します。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase vanity-subdomains delete

プロジェクトのバニティサブドメインを削除し、ルーティングにプロジェクトリファレンスを使用するように戻す。

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase network-bans

ネットワーク禁止とは、トラフィックパターンが不正な場合(例えば認証に何度も失敗した場合など)に一時的にブロックされる IP のことです。

サブコマンドを使うと、現在の 禁止IP を表示したり、必要に応じてブロックを解除したりできます。

• Available Commands
  • $ supabase network bans get
  • $ supabase network bans remove

$ supabase network-bans get

現在のネットワーク禁止を取得

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase network-bans remove

ネットワーク禁止を削除します。

• Flags

--db-unban-ip

DB接続を許可するIP

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase network-restrictions

ネットワークの制限を管理します。

• Available Commands
  • $ supabase network restrictions get
  • $ supabase network restrictions update

$ supabase network-restrictions get

現在のネットワーク制限を取得

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase network-restrictions update

ネットワーク制限を更新します。

• Flags

--bypass-cidr-checks
CIDR検証チェックの一部をバイパスします。

--db-allow-cidr
DB接続を許可するCIDRを指定します。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase ssl-enforcement

SSL強制設定を管理します。

• Available Commands
  • $ supabase ssl enforcement get
  • $ supabase ssl enforcement update

$ supabase ssl-enforcement get

現在の SSL 実施設定を取得します

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase ssl-enforcement update

SSLエンフォースメントの設定を更新します。

• Flags

--disable-db-ssl-enforcement

DBがすべての外部接続に対してSSL強制を無効にするかどうか。

--enable-db-ssl-enforcement
DBがすべての外部接続に対してSSL施行を有効にするかどうかを指定します。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase postgres-config

Postgres データベースの設定を管理します。

• Available Commands
  • $ supabase postgres config get
  • $ supabase postgres config update

$ supabase postgres-config get

現在の Postgres データベース設定を取得します。

supabase postgres-config get --experimental
supabase postgres-config get --experimental --project-ref gzctqdrrnnkaxwwtzbsw

• Flags

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase postgres-config update

デフォルトのPostgres設定を上書きすると、データベースの動作が不安定になる可能性があります。
カスタム設定は、使用中の計算アドオンに基づいて生成されます最適化も上書きします。

• Flags

--config
key=value'ペアとして指定された設定の上書き

--replace-existing-overrides
trueを指定すると、既存のオーバーライドをすべて指定されたオーバーライドに置き換えます。false (デフォルト) の場合、既存のオーバーライドを指定されたオーバーライドにマージします。

--project-ref
Supabaseプロジェクトのプロジェクト参照。

$ supabase completion

指定されたシェルの supabase のオートコンプリートスクリプトを生成します。
生成されたスクリプトの使い方は各サブコマンドのヘルプを参照してください。

• Available Commands
  • $ supabase completion zsh
  • $ supabase completion powershell
  • $ supabase completion fish
  • $ supabase completion bash

$ supabase completion zsh

zsh シェル用の自動補完スクリプトを生成します。

シェル補完がまだ有効になっていない環境では、有効にする必要があります。
以下を一度実行してみてください：

echo "autoload -U compinit; compinit" >> ~/.zshrc

現在のシェルセッションで補完ファイルをロードするには、次のようにします：

source <(supabase completion zsh)

新しいセッションごとに補完を読み込むには、一度だけ実行します：

• Linux:

supabase completion zsh > "${fpath[1]}/_supabase"

• macOS:

supabase completion zsh > $(brew --prefix)/share/zsh/site-functions/_supabase

この設定を有効にするには、新しいシェルを起動する必要があります。

• Flags

--no-descriptions
補完記述を無効にします。

$ supabase completion powershell

powershell 用の自動補完スクリプトを生成します。

現在のシェルセッションで補完を読み込むには

supabase completion powershell | Out-String | Invoke-Expression

新しいセッションごとに補完を読み込むには、上記のコマンドの出力を powershell プロファイルに追加します。

• Flags

--no-descriptions
補完説明を無効にします。

$ supabase completion fish

魚シェルの自動補完スクリプトを生成します。

現在のシェルセッションで補完を読み込むには

supabase completion fish | source

新しいセッションごとに補完スクリプトをロードするには、一度だけ実行します：

supabase completion fish > ~/.config/fish/completions/supabase.fish

この設定を有効にするには、新しいシェルを起動する必要があります。

• Flags

--no-descriptions
補完記述を無効にします。

$ supabase completion bash

bashシェル用の自動補完スクリプトを生成します。

このスクリプトは 'bash-completion' パッケージに依存します。
まだインストールされていない場合は、OSのパッケージマネージャからインストールしてください。

現在のシェルセッションで補完を読み込むには

source <(supabase completion bash)

新しいセッションごとに補完結果を読み込むには、以下のように一度だけ実行します：

• Linux:

supabase completion bash > /etc/bash_completion.d/supabase

• macOS:

supabase completion bash > $(brew --prefix)/etc/bash_completion.d/supabase

この設定を有効にするには、新しいシェルを起動する必要があります。

• Flags

--no-descriptions
補完記述を無効にします。

Need some help?

[Contact support](https://supabase.com/dashboard/support/new)

• Lastest product updates?

  See Changelog

• Something's not right?

  Check system status

非推奨になったコマンド

↓非推奨になったコマンド
supabase db remote commit

↓かわりにこちらを使用してください
supabase db pull