ShipStackLabShipStackLabStart a stack
TOOL / Backend platform

Supabase

Supabase is a Postgres development platform that provides projects with database, authentication, storage, and related backend capabilities for web and mobile applications; this sourced profile is workflow context, not a ShipStackLab hands-on recommendation.

PROFILE PARTIALNOT YET TESTEDChecked 2026-10-12
Official website Add to stack

What Supabase does

Check the database version, review affected features, plan recovery, then obtain approval before making changes.
AI-generated editorial illustration by ShipStackLab, not an official Supabase screenshot. Review first; this is not a command sequence or confirmation that your database is affected.

TLS compatibility, reviewed October 12: Supabase plans to remove four CBC-mode TLS 1.2 cipher suites from managed project HTTP APIs no earlier than November 10, 2026. Auth, Data API, Storage, Realtime and Edge Functions share that boundary. Other supported TLS 1.2 ciphers and TLS 1.3 remain; direct Postgres, pooler and Management API connections, and self-hosted deployments, are excluded. This is a future compatibility change, not a current outage.

Supabase is a Postgres development platform that combines database, generated data APIs, authentication, file storage, and related backend services.

Status notification maintenance, reviewed October 10: Supabase's October 8 announcement moves status.supabase.com to incident.io without changing the URL. Email subscriptions were transferred automatically; existing Slack and RSS subscriptions need a fresh subscription. SMS and webhook subscriptions did not transfer and those notification channels are no longer offered. The replacement supports Email, RSS and Slack, with product and region choices for email. The announcement states that self-hosted deployments are unaffected; this is a status-notification change, not a database migration or outage announcement.

Framework adapter deadline: the October 5, 2026 announcement deprecates @supabase/server/adapters/hono, /h3, /elysia and /nestjs; they still work but are scheduled for removal on December 1, 2026. withSupabase(config, handler) is not deprecated, nor are withSupabase(config) and @supabase/server/middleware/* entries. This is not the retirement of Supabase Auth or the database service.

Authentication migration red line: an adapter using auth: 'user' must retain a required gate such as withRequiredClaims(), not optional withClaims(), which accepts anonymous requests with jwtClaims: null. For auth: 'publishable' and auth: 'secret', the announcement directs endpoints to stay on withSupabase because no bridge entry replaces those modes. auth: 'none' needs no gate; inventory each registration rather than applying one blanket replacement.

October 7 review: Supabase's October 6 announcement makes scoped personal access tokens (PATs) generally available for Management API, MCP and CLI integrations. Tokens can target selected projects in one organization or all projects in selected organizations, with capability-level permissions and expiry up to one year. Access cannot be edited after creation, and the user's current role still limits it. Existing tokens are not automatically revoked; the browser flow for supabase login still creates an account-level token. Scoped CLI authentication instead uses login --token or SUPABASE_ACCESS_TOKEN; supabase whoami does not support project- or organization-scoped tokens.

MCP permission examples from the PAT documentation: get_logs and query_logs need Logs Read; execute_sql needs Database Read and stays read-only without Database Read/Write; apply_migration needs Migrations Read/Write. A tool's confirmation prompt is separate from the token permission. Read-only access can still disclose sensitive results, so least privilege includes the selected project and the permitted data, not only the absence of writes.

Do not confuse management PATs with application API keys. A publishable key is intended for client-side use with application authorization and RLS; secret keys and legacy service_role keys bypass RLS and belong only in controlled server environments. A scoped PAT is not a replacement for application authentication or row-level policies, and no management token belongs in browser bundles.

October 1, 2026: OrioleDB enters Public Beta, including Pro, Team and Enterprise projects, with standard Postgres project billing. Supabase describes it as testing-only, not recommended for production, and without an SLA. Paid availability is not a production-readiness guarantee.

OrioleDB is selected when creating a project; it cannot be added to an existing project or removed later. Scheduled backups are supported, but Point-in-Time Recovery (PITR) and restoring a backup to a new project are unavailable. Existing alpha projects are not automatically moved to Public Beta. OrioleDB is not yet part of the self-hosted Supabase stack; the separately documented standalone Postgres image is a different scope.

Postgres upgrade checkpoint: Supabase's September 25, 2026 notice covers 15.19 / 17.11. From September 28, new projects use these versions and existing projects can upgrade in the dashboard. Self-hosted deployments can also be affected; this is separate from the logs API migration below.

Affected cases: older ltree indexes with multibyte/non-libc collation, or very deep paths; btree_gist float indexes containing possible NaN values; pgcrypto PGP data using bf/blowfish/cast5; and custom operators with non-built-in selectivity estimators. Indexes may return incomplete results. Legacy-cipher data was effectively unencrypted and stops decrypting by default after upgrade; default AES is not affected. Existing custom operators still work, but recreating them requires superuser. Extension-installed operators are excluded.

Supabase's July 23, 2026 announcement schedules removal of the Management API logs.all analytics endpoint for September 23, 2026. Its replacement, logs, accepts ClickHouse SQL and queries a unified logs table, with source_name selecting a log source and log_attributes replacing nested metadata traversal. This concerns managed log querying, not removal of Postgres or the application data APIs; the announcement marks self-hosted deployments as unaffected.

The migration notice also covers AI agents calling the Supabase MCP server's get_logs tool, which previously used logs.all internally. Supabase identifies mcp-server-supabase v0.10.0 as using the replacement endpoint. Dashboard Logs Explorer users are not affected by this endpoint removal. This is additional scope from the existing announcement, not a newly announced outage.

Supabase MCP server v0.13.0 adds a separate upgrade consideration: createSupabaseMcpServer renames its costConfirmation option to confirmation, a breaking change for integrations using that option. Confirmation now also covers destructive SQL in execute_sql and apply_migration; the local HTTP entry point opts in both tools. This does not replace the earlier get_logs migration.

SQL confirmation requires the relevant tools to be enabled in the confirmation configuration and a client supporting form elicitation. Supabase's implementation notes describe the regex detector as best-effort, not a security barrier: some destructive statements can be missed, and clients without elicitation support can execute SQL without a prompt. Hosted-platform SQL opt-in is separately feature-flagged; the package release alone does not establish your hosted project's behavior.

It covers a major backend stage in an AI-built application, but schema design, authorization policies, migrations, backups, observability, and data ownership remain operator decisions.

Workflow role

  • backend

Inputs and outputs

Inputs

  • Database schema, SQL, or migrations
  • Application authentication and storage requirements

Outputs

  • Postgres database and generated data APIs
  • Authentication and file-storage backend services

Compatible tools

UNKNOWN

Ownership and deployment

Code ownershipUNKNOWNUNKNOWN · Official code-ownership evidence has not been recorded. · Checked 2026-08-19
Data ownershipUNKNOWNUNKNOWN · Official data-ownership evidence has not been recorded. · Checked 2026-08-19
Deployment modelUNKNOWNUNKNOWN · Official deployment-model evidence has not been recorded. · Checked 2026-08-19
Pricing statusUNKNOWNUNKNOWN · Current pricing evidence has not been recorded. · Checked 2026-08-19

Suitable and unsuitable tasks

Suitable

  • Adding Postgres data, authentication, and storage to an application stack

Not established

  • Replacing the user-interface design process or a code-generation workflow

Known limitations and unknowns

  • No hands-on limitations have been verified by ShipStackLab.UNKNOWN · Checked 2026-08-19

Adoption checks

  • Design and test row-level security and service-role boundaries before exposing application data.
  • TLS checklist: identify old browsers, end-of-life operating systems and embedded HTTPS clients. Ask the project owner to review any October 14 impact email and plan supported OS/TLS-library updates where needed. Do not weaken encryption to preserve an obsolete client. ShipStackLab has not tested client compatibility; project impact remains UNKNOWN.
  • Notification checklist: if your operations relied on an old status subscription, have its owner check the channel and choose a supported replacement at status.supabase.com. Email subscribers can review product and region coverage; Slack and RSS subscribers need to resubscribe. ShipStackLab has not verified your subscriptions or notification delivery, and has not changed them. Delivery remains UNVERIFIED until independently checked.
  • Adapter review: record affected imports, each auth mode and resolved dependencies. The documented bridges require @supabase/server >=1.6.0, Node >=22 and a direct @supabase/middleware dependency. Review nested supabaseContext reads and the userClaims.id to jwtClaims.sub change. In an authorized isolated preview, typecheck, confirm previously protected endpoints still return 401 without a token, and check valid users still receive intended access. ShipStackLab has not independently tested this adapter migration; your project's impact remains UNKNOWN. This is review guidance, not authorization to install packages or change production authentication.
  • Scoped PAT checklist: have the integration owner choose only the approved project, required capabilities, expiry and replacement/revocation owner. Check the exact permission mapping before responding to a denial; do not grant broad write access merely to test MCP. Keep token values out of client code, repositories and shared logs. ShipStackLab has not independently tested scoped PAT behavior or created, replaced or revoked your tokens; your integration's effective access remains UNKNOWN.
  • OrioleDB decision gate: keep production on a supported production-ready path. If evaluating the beta, use a separate disposable project and record required extensions, index types, recovery objectives and an exit plan before choosing the engine. Do not equate scheduled backups with PITR or cross-project restore. ShipStackLab has not benchmarked OrioleDB or tested recovery; performance and migration outcomes remain UNKNOWN.
  • Before a Postgres upgrade, ask the database owner to review the detection queries in the linked 15.19 / 17.11 announcement. Remediation depends on the findings: reindex affected indexes after upgrading, re-encrypt affected data, or revise custom operators with support. Do not treat every project as affected.
  • ShipStackLab editorial safeguard: record the database version, affected objects, backup/restore plan and validation results before approving changes. The official diagnostic examples include a temporary helper function, so they are not all read-only statements. This profile is not an executable runbook or permission to run SQL. ShipStackLab has not inspected your database or tested this upgrade; project impact remains UNKNOWN. Do not paste credentials or production records into a coding agent to resolve it.
  • Inventory monitoring scripts and integrations that call logs.all against the announced September 23, 2026 cutoff. Preserve their queries, convert the SQL and field mapping, then compare time windows, filters and returned records against the replacement before switching consumers. Merely renaming the endpoint is not a migration test. ShipStackLab has not performed or independently tested this migration; whether your project uses the affected endpoint remains UNKNOWN until inspected.
  • For MCP integrations, identify the configured server, its version, and whether the agent uses get_logs before deciding an update is needed. For a version you manage, review the v0.10.0 release notes, including the query_logs breaking-change entry, before upgrading. Verify a permitted log query against the intended project and time window after the change. ShipStackLab has not independently tested the MCP update; a version number alone does not prove your integration works, and you should not grant broader permissions just to test it.
  • Confirmation boundary: review the v0.13.0 option rename only where your integration configures the server, then check the actual client's capabilities and enabled confirmations. Keep least-privilege access, read-only access where sufficient, and backups; a prompt is not a database permission or recovery mechanism. Any separately authorized confirmation test belongs in an isolated project with disposable data, including verification that declining or cancelling leaves it unchanged. Do not grant write access merely to test this feature. ShipStackLab has not independently tested SQL confirmation behavior.
  • Document migrations, backups, regional requirements, and the path to move data before production launch.

Source register