> ## Documentation Index
> Fetch the complete documentation index at: https://docs.argalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Supabase

> Supabase Scenario seeding parameters, nested fields, and examples

Use `supabase` in `twins` and put this configuration under `seed_config.supabase`.

API-only Supabase project on real PostgreSQL with hosted-compatible MCP and Management API.

## Example seed

This is the complete Scenario request body for [creating a Scenario](https://docs.argalabs.com/api-reference/post-create-a-scenario.md). You can also import it with `arga test-runner scenarios import --file scenario.json`.

```json theme={null}
{
  "name": "Supabase eval fixture",
  "twins": [
    "supabase"
  ],
  "seed_config": {
    "supabase": {
      "projects": [
        {
          "id": "argatwinprojectaaaaa",
          "name": "Support workspace",
          "migrations": [
            {
              "name": "create_tickets",
              "query": "CREATE TABLE public.tickets (id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY, title text NOT NULL, owner_id uuid REFERENCES auth.users(id)); ALTER TABLE public.tickets ENABLE ROW LEVEL SECURITY; CREATE POLICY own_tickets ON public.tickets TO authenticated USING (owner_id = auth.uid()) WITH CHECK (owner_id = auth.uid());"
            }
          ],
          "sql": [
            "INSERT INTO auth.users(id, email) VALUES ('00000000-0000-4000-8000-000000000001', 'ada@example.test');",
            "INSERT INTO public.tickets(title, owner_id) VALUES ('Investigate refund', '00000000-0000-4000-8000-000000000001');"
          ]
        }
      ]
    }
  }
}
```

## Parameters

The following fields belong directly inside `seed_config.supabase`. Required nested fields are marked in their tables. Provider-native objects can contain service-specific fields beyond the representative record shapes below.

| Parameter | Type | Description |
| - | - | - |
| `projects` | `ProjectSeed[]` | Projects fixtures in provider-native format. |
| `sql` | `string[]` | SQL statements applied in order to the twin data plane. |
| `base_time` | `string or null` | Reference clock for repeatable fixtures. Omit to use the current clock. |

## Seeding behavior

SQL runs against the twin PostgreSQL data plane. Put per-project statements in `projects[].sql`; project migrations accept named SQL records. This is separate from the `postgres` twin.

## Resource fields

These tables describe the record shapes used by the example. Keep native field names and casing. Map keys such as property names, IDs, and metadata keys are supplied by your fixture.

### `projects[]`

| Parameter | Type | Description |
| - | - | - |
| `id` | `string` | Explicit resource identifier, when supported. |
| `name` | `string` | Human-readable name. |
| `migrations` | `object[]` | Migrations fixtures in provider-native format. |
| `sql` | `string[]` | SQL statements applied in order to the twin data plane. |

### `projects[].migrations[]`

| Parameter | Type | Description |
| - | - | - |
| `name` | `string` | Human-readable name. |
| `query` | `string` | Query. |

## Typed configuration objects

Named object types in the parameter table use these fields.

### ProjectSeed

| Parameter | Type | Description |
| - | - | - |
| `id` | `string` | Explicit resource identifier, when supported. |
| `name` | `string` | Human-readable name. |
| `organization_id` | `string` | Organization id. |
| `region` | `string` | Region. |
| `sql` | `string[]` | SQL statements applied in order to the twin data plane. |
| `migrations` | `map<string, string>[]` | Migrations fixtures in provider-native format. |

## API coverage and limitations

**Twin name:** `supabase` — API-only.

**Supports**

* Supabase Management API and a provider-native remote MCP endpoint, backed by PostgreSQL 17.11 with isolated project and branch state.
* SQL, table metadata, migrations, constraints, transactions, roles, JWT claims, RLS, and PostgreSQL SQLSTATE diagnostics.
* Executable Edge Functions, activity-log SQL, database advisors, TypeScript generation, and migration-based branches.
* Project scoping, read-only mode, legacy Streamable HTTP clients, current-protocol SSE, and form confirmations for destructive SQL and cost actions.

**Provision**

```bash theme={null}
arga twin-runs create --twins supabase --ttl 60 --wait
```

Connect your agent to the returned `SUPABASE_MCP_URL` with `SUPABASE_ACCESS_TOKEN`. The [Supabase MCP guide](https://docs.argalabs.com/features/supabase-mcp.md) covers connection settings, exact Scenario seeds, SQL/error behavior, and the dated hosted comparison results.

**Known limitations**

* No dashboard, OAuth login, Auth HTTP API, PostgREST, hosted pooler, or Storage object/S3 HTTP service. The returned project URL and publishable keys do not add those surfaces.
* Dashboard-based secret collection is not advertised as an MCP tool; use the Management API to set secrets. Hosted rate limits, scaling, billing, and infrastructure traffic are not simulated.
* Hosted comparisons cover the documented probes, not every provider operation or future release.

**MCP tools:** Use Arga's `create_twin_run` and `get_twin_run` for provisioning. The twin endpoint exposes Supabase tools including `execute_sql`, `apply_migration`, `list_tables`, and `query_logs`.

See [Scenario seeding](https://docs.argalabs.com/twins/seeding.md) for saving, provisioning, and resetting fixtures.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.