Supabase vs Appwrite

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Supabase✓fullprobed9/10

   A hands-on probe confirms Supabase serves a valid llms.txt at the root domain (HTTP 200) pointing to full documentation, and Supabase's own docs also document agent-oriented integration paths like MCP and CLI that an agent could follow. Missing for 10: independent/community corroboration of agents actually consuming llms.txt in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://supabase.com/llms.txt # Supabase Docs For the complete documentation in a single file, see [Full Docume…”
   • [claimed-docs] “Start with a quickstart guide to connect your project in minutes.”
   • [probe] “official MCP server documented at https://supabase.com/docs/guides/ai-tools/mcp”

   proof ↗⚑ flag

   Appwrite✓fullprobed9/10

   Appwrite explicitly hosts an llms.txt (confirmed via live probe returning HTTP 200) and docs.md, plus supports appending .md to any doc page for raw Markdown, and provides Skills files for agent context — directly matching the story. missing for 10: no independent/community corroboration of agents actually consuming these files.

   • [probe] “PROBE llms.txt: HTTP 200 at https://appwrite.io/llms.txt # Appwrite > Appwrite is an open-source backend platform with authentication, data…”
   • [probe] “PROBE docs-md: HTTP 200 at https://appwrite.io/docs.md # Appwrite Docs > Top-level documentation sections. For the full nested page index, …”
   • [claimed-docs] “You can access any documentation page as raw Markdown by appending `.md` to the URL.”
   • [claimed-docs] “Skills are open-source Markdown files that give AI agents deep knowledge of Appwrite SDKs and services.”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Supabase
   Supabase✓fullprobed9/10

   Supabase's official CLI explicitly documents running the entire stack locally or in CI (supabase-docs-21), and hands-on probes confirm the CLI installs and runs headlessly via npx and can scaffold a project with no login/keys (supabase-probe-6, supabase-probe-8), which is exactly the CI/automation use case. Missing for 10: no explicit first-party CI pipeline example (e.g., GitHub Actions workflow) or independent third-party CI report beyond the probe evidence.

   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [claimed-docs] “With two commands, you can set up and start a new local project: 1. `supabase init` to create a new local project 2. `supabase start` to lau…”

   proof ↗⚑ flag

   Appwrite✓fullprobed8/10

   Appwrite explicitly documents a non-interactive/headless CLI mode designed for CI automation (appwrite-docs-42), backed by a full CLI for managing projects, resources, and Functions (appwrite-docs-12, appwrite-docs-18), self-hosting via Docker for full infra control (appwrite-docs-14/19/33), and API-driven triggers for functions via HTTP/SDK/webhooks/schedules (appwrite-docs-9). missing for 10: independent/hands-on CI pipeline examples or third-party confirmation of headless CLI use in production.

   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “Add the --endpoint flag if you're using a self-hosted instance of Appwrite.”
   • [probe] “official CLI documented at https://appwrite.io/docs/tooling/command-line/installation”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Supabase
   Supabase✓fullprobed9/10

   Supabase documents and ships an official MCP server (mcp.supabase.com) that lets AI assistants query/interact with Supabase projects, and a live hands-on probe confirms the remote MCP endpoint is reachable and auth-gated as expected. Community discussion also confirms real-world usage (e.g., Cursor assistant connecting via MCP) alongside security mitigations for prompt injection risks. Missing for 10: independent end-to-end hands-on demonstration of a successful authenticated agent session beyond the 401 handshake check.

   • [claimed-docs] “Once connected, your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [probe] “official MCP server documented at https://supabase.com/docs/guides/ai-tools/mcp”
   • [probe] “PROBE mcp-handshake: POST JSON-RPC initialize to https://mcp.supabase.com/mcp → HTTP 401 {"message":"Unauthorized"} — live remote MCP server…”
   • [community] “Supabase engineer: 'A few weeks ago we added mitigations to help with prompt injections - encourage read-only by default, wrap SQL responses…”
   • [community] “The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) p…”

   proof ↗⚑ flag

   Appwrite✓fullprobed8/10

   Appwrite documents an official MCP server that lets LLMs/agents (Claude Code, Cursor, Claude Desktop, etc.) directly interact with Appwrite's API and docs, covering project/resource management and function deployment. This is first-party documented and probe-confirmed, though there's no independent hands-on verification of the MCP server's reliability. Missing for 10: independent/community corroboration of the MCP server working in practice, and more detail on setup/auth flow.

   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”
   • [probe] “official MCP server documented at https://appwrite.io/docs/tooling/ai/mcp-servers”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Supabase
   Supabase✓fullprobed9/10

   Supabase ships an official CLI with clear docs and hands-on verification: `npx supabase --version` runs headlessly and `supabase init` scaffolds a project without login or keys, making it directly usable by AI agents/scripts. Missing for 10: no explicit agent-oriented CLI subcommands or independent third-party report of an AI agent driving the CLI end-to-end.

   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [probe] “official CLI documented at https://supabase.com/docs/guides/local-development/cli/getting-started”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [claimed-docs] “With two commands, you can set up and start a new local project: 1. supabase init to create a new local project 2. supabase start to launch …”

   proof ↗⚑ flag

   Appwrite✓fullprobed8/10

   Appwrite documents an official CLI covering project/resource management, function deployment, non-interactive/headless CI use, SDK generation, and self-hosted endpoint targeting, which is well suited to AI-native/agentic automation workflows. missing for 10: independent hands-on community corroboration of the CLI itself (evidence is entirely first-party docs) and no explicit example of an AI agent scripting the CLI end-to-end.

   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “you can split top-level resource arrays into separate JSON files with the `includes` field.”
   • [claimed-docs] “Add the --endpoint flag if you're using a self-hosted instance of Appwrite.”
   • [claimed-docs] “The generate command creates a type-safe SDK tailored to your project. It detects your project's language and generates typed helpers based …”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [probe] “official CLI documented at https://appwrite.io/docs/tooling/command-line/installation”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round drawn
   Supabase✓fullprobed8/10

   Supabase auto-generates REST and GraphQL APIs from the database schema and a live probe confirms a real spec-compliant OpenAPI document at supabase.com/openapi.json, giving AI agents a documented machine-readable API surface. This is reinforced by CLI and MCP tooling that lets an agent programmatically provision and query projects headlessly. Missing for 10: independent third-party validation of API completeness/stability, and explicit versioning/rate-limit docs for programmatic API consumers.

   • [claimed-docs] “Instant ready-to-use REST APIs.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”
   • [probe] “PROBE openapi: HTTP 200 at https://supabase.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Supabase APIs are generated from your database, which means that we can use database introspection to generate type-safe API definitions.”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [claimed-docs] “your AI assistants can interact with and query your Supabase projects on your behalf.”

   proof ↗⚑ flag

   Appwrite✓fullprobed8/10

   Appwrite exposes a full public API surface (auth, databases, storage, functions) with SDKs, a documented CLI for automation/CI, docs-as-markdown and llms.txt for machine consumption, and an official MCP server letting agents call the API accurately. This is strong first-party documentation of programmatic/agentic access, though an OpenAPI spec probe returned 404s. Missing for 10: a publicly discoverable OpenAPI/swagger spec and independent (non-vendor) hands-on confirmation of agentic API usage.

   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”
   • [claimed-docs] “Skills are open-source Markdown files that give AI agents deep knowledge of Appwrite SDKs and services.”
   • [claimed-docs] “You can access any documentation page as raw Markdown by appending `.md` to the URL.”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://appwrite.io/llms.txt # Appwrite > Appwrite is an open-source backend platform with authentication, data…”
   • [probe] “PROBE docs-md: HTTP 200 at https://appwrite.io/docs.md # Appwrite Docs > Top-level documentation sections. For the full nested page index, …”
   • [probe] “PROBE openapi: all candidate paths 404 (https://appwrite.io/openapi.json, https://appwrite.io/swagger.json, https://appwrite.io/api/openapi.…”
   • [probe] “official MCP server documented at https://appwrite.io/docs/tooling/ai/mcp-servers”
   • [probe] “official CLI documented at https://appwrite.io/docs/tooling/command-line/installation”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Appwrite
   Supabase!disputedcontradicted4/10

   Supabase offers RLS-based fine-grained authorization and says it encourages read-only access by default for its MCP integration (mitigating agent access scope), but a concrete hands-on community report shows the Cursor/Supabase MCP integration actually running with elevated service_role access that bypasses RLS entirely — the opposite of least-privilege scoping. This is a direct, concrete contradiction rather than general skepticism. Missing for 10: documented ability to mint scoped/least-privilege API keys or tokens specifically for agent use, and confirmation that MCP connections default to restricted roles rather than service_role.

   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”
   • [claimed-docs] “create policy "Individuals can view their own todos." on todos for select to authenticated using ( (select auth.uid()) = user_id );”
   • [community] “Supabase engineer: 'A few weeks ago we added mitigations to help with prompt injections - encourage read-only by default, wrap SQL responses…”
   • [community] “The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) p…”
   • [probe] “PROBE mcp-handshake: POST JSON-RPC initialize to https://mcp.supabase.com/mcp → HTTP 401 {"message":"Unauthorized"} — live remote MCP server…”

   proof ↗⚑ flag

   Appwrite~partialclaimed3/10

   Appwrite documents JWT-based delegated access for users (appwrite-docs-35) and a permissions-based database/resource model (appwrite-docs-6, appwrite-docs-23), which could underpin least-privilege credentialing, but there is no explicit documentation of issuing scoped API keys/tokens specifically for AI agents. missing for 10: explicit docs on creating agent-specific scoped API keys, examples of least-privilege key scoping for MCP/agent use, and independent confirmation this works in practice for agent credentials.

   • [claimed-docs] “Deligate access for a user through passing JWT tokens.”
   • [claimed-docs] “Structured, relational data with typed columns, rows, relationships, and indexes.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”
   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Appwrite
   Supabase~partialprobed6/10

   Supabase provides auto-generated REST/GraphQL APIs, TypeScript type generation, and quickstart docs for connecting projects, which support building against official client libraries, and its CLI/MCP tooling make it usable by AI agents. However, the evidence pack never explicitly documents a suite of official SDKs (e.g., JS, Python, Flutter) or their API surfaces beyond generated types. Missing for 10: explicit official SDK/client-library documentation across languages, code samples showing SDK usage, and independent confirmation that AI agents build reliably against these SDKs.

   • [claimed-docs] “Generate types for your project to produce the `database.types.ts` file”
   • [claimed-docs] “Supabase APIs are generated from your database, which means that we can use database introspection to generate type-safe API definitions.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”
   • [claimed-docs] “Start with a quickstart guide to connect your project in minutes.”
   • [claimed-docs] “Instant ready-to-use REST APIs.”
   • [probe] “official CLI documented at https://supabase.com/docs/guides/local-development/cli/getting-started”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”

   proof ↗⚑ flag

   Appwrite✓fullprobed7/10

   Appwrite explicitly supports SDK-based development with 'SDK methods' triggering Functions, a CLI 'generate' command that creates type-safe SDKs from project schema, and dedicated AI-native tooling (MCP server for 'SDK-accurate calls', Skills markdown files, docs-as-markdown, llms.txt) that teaches agents to use its SDKs correctly. This shows first-party investment in making SDKs agent-buildable, though the pack lacks an explicit enumerated list of supported SDK languages or independent hands-on validation of SDK quality. Missing for 10: explicit list/count of official SDK languages, independent developer corroboration of SDK reliability.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “The generate command creates a type-safe SDK tailored to your project. It detects your project's language and generates typed helpers based …”
   • [claimed-docs] “Teach agents your backend so they make SDK-accurate calls.”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”
   • [claimed-docs] “Skills are open-source Markdown files that give AI agents deep knowledge of Appwrite SDKs and services.”
   • [claimed-docs] “You can access any documentation page as raw Markdown by appending `.md` to the URL.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://appwrite.io/llms.txt # Appwrite > Appwrite is an open-source backend platform with authentication, data…”
   • [probe] “PROBE docs-md: HTTP 200 at https://appwrite.io/docs.md # Appwrite Docs > Top-level documentation sections. For the full nested page index, …”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round to Appwrite
   Supabase—none0/10

   The evidence describes Supabase Realtime (Broadcast, Presence, Postgres Changes via websockets) but never mentions a webhooks feature for subscribing to events over HTTP callbacks, which is what the story asks for; missing for 10: any documentation of Database Webhooks or HTTP callback subscription mechanism.

   ⚑ flag

   Appwrite~partialclaimed5/10

   Appwrite Functions can be triggered by webhooks, and Appwrite supports responding to server events in realtime, indicating webhook-based event subscription exists, but there's no dedicated documentation detailing webhook subscription setup, payload format, or management specifically for AI-native agent use. missing for 10: dedicated webhook subscription docs/API reference, examples of AI agents configuring webhook subscriptions, independent hands-on verification of webhook delivery.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “Respond to server events in realtime.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Supabase
   Supabase~partialprobed5/10

   Supabase enables AI assistants (via MCP) to query and interact with a user's Supabase data, and provides a pgvector-based AI toolkit for building AI features into apps, but there is no evidence of a first-party in-dashboard 'insights and suggestions' feature that surfaces AI-generated analysis directly inside Supabase Studio. The MCP-based approach requires connecting an external AI assistant rather than the product itself generating insights natively. missing for 10: evidence of a built-in Studio AI insights/suggestions feature, evidence of automatic proactive suggestions (vs. user-initiated querying via external assistant), independent hands-on validation of insight quality.

   • [claimed-docs] “Once connected, your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [claimed-docs] “Supabase provides an open source toolkit for developing AI applications using Postgres and pgvector.”
   • [probe] “official MCP server documented at https://supabase.com/docs/guides/ai-tools/mcp”
   • [probe] “PROBE mcp-handshake: POST JSON-RPC initialize to https://mcp.supabase.com/mcp → HTTP 401 {"message":"Unauthorized"} — live remote MCP server…”

   proof ↗⚑ flag

   Appwrite—none0/10

   Appwrite's AI-related docs describe building blocks for developers to add AI features to their own apps (embeddings storage, image labeling, functions) and tooling for external AI agents (MCP server, CLI, skills) — not Appwrite itself surfacing AI-generated insights or suggestions about the user's own data inside the product (e.g., an analytics/insights dashboard). No evidence of such a first-party insights feature was found.

   • [claimed-docs] “Store embeddings and run similarity search to power AI features.”
   • [claimed-docs] “Label and understand the contents of images”
   • [claimed-docs] “Understand and label the contents of images”
   • [claimed-docs] “Appwrite allows you to build powerful AI powered applications with ease. Leverage Appwrite's powerful functions architecture and start build…”

   proof ↗⚑ flag

2. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Appwrite
   Supabase—none0/10

   The evidence pack covers Edge Functions, Realtime, RLS, and MCP/CLI tooling, but contains no mention of scheduled jobs, cron triggers, database webhooks, or any mechanism for autonomous background automations that an AI-native user could set up and let run unattended. As a backend platform, this axis is plausible for Supabase, but no supporting evidence exists in the pack.

   ⚑ flag

   Appwrite~partialclaimed6/10

   Appwrite Functions can be triggered by scheduled executions, server events, and webhooks (appwrite-docs-9), which enables autonomous background automations, and the CLI supports non-interactive/headless automation for CI use (appwrite-docs-42). However, there's no dedicated 'agent automation' or workflow-orchestration framework documented specifically for AI-native autonomous agents beyond scheduled Functions — missing for 10: no evidence of long-running agent orchestration, multi-step autonomous agent workflows, or independent hands-on validation of scheduled/background automation reliability.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round drawn
   Supabase—none0/10

   All evidence describes Supabase's MCP server, which lets *external* AI assistants (Cursor, Claude, etc.) connect to and query a Supabase project — this is the client-connectivity story, not a built-in assistant living inside Supabase's own product/dashboard. No evidence pack item describes a first-party in-product AI assistant that users delegate tasks to within Supabase itself.

   ⚑ flag

   Appwrite—none0/10

   Appwrite's evidence shows it exposes AI-related APIs (image labeling, embeddings), an MCP server for external AI agents/tools to control Appwrite, and CLI/skills for agentic tooling — but nothing describes a built-in assistant inside the Appwrite product/console that a user can delegate tasks to. The MCP and CLI integrations are about external AI agents driving Appwrite, not Appwrite hosting its own assistant.

   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “Appwrite allows you to build powerful AI powered applications with ease. Leverage Appwrite's powerful functions architecture and start build…”
   • [claimed-docs] “Label and understand the contents of images”
   • [claimed-docs] “Understand and label the contents of images”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round drawn
   Supabase✓fullprobed8/10

   Supabase ships an official, documented MCP server enabling AI assistants to query and operate projects via natural language, corroborated by a live hands-on handshake against the production MCP endpoint and documented prompt-injection mitigations from a Supabase engineer. Missing for 10: independent quality benchmarking of the NL interface itself and full resolution of security concerns (e.g., service_role bypassing RLS in some client configs).

   • [claimed-docs] “Once connected, your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [claimed-docs] “your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [probe] “official MCP server documented at https://supabase.com/docs/guides/ai-tools/mcp”
   • [probe] “PROBE mcp-handshake: POST JSON-RPC initialize to https://mcp.supabase.com/mcp → HTTP 401 {"message":"Unauthorized"} — live remote MCP server…”
   • [community] “Supabase engineer: 'A few weeks ago we added mitigations to help with prompt injections - encourage read-only by default, wrap SQL responses…”
   • [community] “The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) p…”

   proof ↗⚑ flag

   Appwrite✓fullprobed8/10

   Appwrite ships an official MCP server plus open-source "Skills" markdown files that let AI agents/LLMs (via Claude Desktop, Cursor, Codex, etc.) directly operate on an Appwrite project—creating/managing projects, resources, and functions—using natural-language driven tool calls rather than manual API/CLI work, and docs are also served as raw markdown for agent consumption. Missing for 10: independent/hands-on user reports confirming the MCP server works reliably in practice, and no evidence of a broader natural-language chat/command interface beyond the MCP/agent-tooling layer.

   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”
   • [claimed-docs] “Skills are open-source Markdown files that give AI agents deep knowledge of Appwrite SDKs and services.”
   • [claimed-docs] “Teach agents your backend so they make SDK-accurate calls.”
   • [claimed-docs] “You can access any documentation page as raw Markdown by appending `.md` to the URL.”
   • [probe] “official MCP server documented at https://appwrite.io/docs/tooling/ai/mcp-servers”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Supabase
   Supabase~partialprobed4/10

   Evidence shows Supabase auto-generates REST/GraphQL APIs and exposes a public OpenAPI spec (openapi.json), implying some form of API reference exists, but there is no direct evidence of an interactive reference page with runnable/executable code examples for AI-native exploration. Missing for 10: explicit documentation or screenshot of an interactive API docs page, evidence of runnable/testable examples in the browser, and any AI-specific tooling around that reference beyond the generic OpenAPI file.

   • [probe] “PROBE openapi: HTTP 200 at https://supabase.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Instant ready-to-use REST APIs.”
   • [claimed-docs] “Instant ready-to-use **REST APIs**.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”

   proof ↗⚑ flag

   Appwrite—none0/10

   The evidence pack shows Appwrite documentation, CLI, and MCP tooling for AI agents, but nothing describes an interactive API reference or console where users can run live code examples. A probe for OpenAPI/Swagger endpoints returned 404s, further suggesting no exposed interactive reference is confirmed.

   • [probe] “PROBE openapi: all candidate paths 404 (https://appwrite.io/openapi.json, https://appwrite.io/swagger.json, https://appwrite.io/api/openapi.…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Supabase
   Supabase✓fullprobed9/10

   Probe evidence confirms a live, machine-readable OpenAPI spec at supabase.com/openapi.json returning a valid 'openapi' key, plus a documented REST API auto-generated from the database and generated TypeScript types. Missing for 10: no independent third-party confirmation of spec completeness or versioning stability.

   • [probe] “PROBE openapi: HTTP 200 at https://supabase.com/openapi.json — contains "openapi" key”
   • [claimed-docs] “Instant ready-to-use REST APIs.”
   • [claimed-docs] “Supabase APIs are generated from your database, which means that we can use database introspection to generate type-safe API definitions.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”

   proof ↗⚑ flag

   Appwrite—none0/10

   Appwrite is an API-driven backend platform, so publishing a machine-readable API spec (OpenAPI/Swagger) is a fair and applicable ask. A direct probe for standard OpenAPI/Swagger endpoints (openapi.json, swagger.json, etc.) returned 404 on all candidates, and no docs evidence points to a downloadable spec file, only CLI/MCP/markdown docs tooling.

   • [probe] “PROBE openapi: all candidate paths 404 (https://appwrite.io/openapi.json, https://appwrite.io/swagger.json, https://appwrite.io/api/openapi.…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://appwrite.io/llms.txt # Appwrite > Appwrite is an open-source backend platform with authentication, data…”
   • [probe] “PROBE docs-md: HTTP 200 at https://appwrite.io/docs.md # Appwrite Docs > Top-level documentation sections. For the full nested page index, …”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Supabase
   Supabase✓fullprobed8/10

   Supabase offers both local development (via CLI 'supabase init/start', hands-on verified) and branching environments explicitly designed to test schema/config/feature changes without affecting production, directly matching the sandbox-without-touching-production story. Community evidence corroborates real usage of local dev/migrations, though some report local dev as a weak point (comm-7, comm-8). Missing for 10: independent hands-on confirmation of branching workflow specifically, and no direct evidence addressing data-seeding/isolation guarantees in the sandbox beyond docs claims.

   • [claimed-docs] “You can use these branching environments to create and test changes like new configurations, database schemas, or features without affecting…”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project. You can use these branching environments to create and …”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project.”
   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [community] “The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dash…”

   proof ↗⚑ flag

   Appwrite~partialclaimed4/10

   Appwrite's self-hosting capability (docs-14/19/33/34) lets a user spin up an isolated instance separate from production, and CLI non-interactive mode (docs-42) supports automated CI testing, which together imply a way to test without touching production data. However, there is no explicit 'sandbox' or staging-environment feature, no seed/reset-data tooling, and no documentation calling out this exact workflow. missing for 10: explicit sandbox/staging environment feature, data-seeding/reset tooling, first-party guidance on isolating test vs prod data.

   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI.”
   • [claimed-docs] “You want to manage your own infrastructure”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Supabase—none0/10

   The evidence pack has no mention of API versioning schemes or a documented deprecation policy for Supabase's REST/GraphQL/Auth/Storage APIs; there's an OpenAPI spec probe but nothing about version lifecycle or deprecation commitments. This is a fair axis for a backend platform with public APIs, so absence of evidence yields 'none'.

   ⚑ flag

   Appwrite—none0/10

   No evidence pack item references API versioning scheme or a documented deprecation policy; the openapi.json probe even returned 404s, suggesting no discoverable versioned API spec. No mention of version numbers, deprecation timelines, or migration guides for breaking changes.

   • [probe] “PROBE openapi: all candidate paths 404 (https://appwrite.io/openapi.json, https://appwrite.io/swagger.json, https://appwrite.io/api/openapi.…”

   proof ↗⚑ flag

Ai assist

1. ai-native userAsk an AI assistant in the dashboard to write queries, debug errors, and explain my backend

   weight 2 · round to Supabase
   Supabase~partialprobed5/10

   Evidence shows Supabase's MCP integration lets external AI assistants (e.g., Cursor) query and operate on Supabase projects, and community reports confirm real-world use of an AI assistant against the database (with RLS-bypass caveats). However, none of the evidence specifically documents a native AI assistant embedded inside the Supabase dashboard UI itself, nor its ability to explicitly debug errors or explain the backend within that context — the evidence centers on MCP-based external tool connections, not an in-dashboard chat assistant. Missing for 10: dedicated dashboard-embedded assistant UI documentation, explicit debug/explain feature descriptions, and independent hands-on confirmation of dashboard-based query writing.

   • [claimed-docs] “Once connected, your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [claimed-docs] “your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [probe] “official MCP server documented at https://supabase.com/docs/guides/ai-tools/mcp”
   • [probe] “PROBE mcp-handshake: POST JSON-RPC initialize to https://mcp.supabase.com/mcp → HTTP 401 {"message":"Unauthorized"} — live remote MCP server…”
   • [community] “The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) p…”
   • [community] “Supabase engineer: 'A few weeks ago we added mitigations to help with prompt injections - encourage read-only by default, wrap SQL responses…”

   proof ↗⚑ flag

   Appwrite—none0/10

   Evidence shows Appwrite ships an MCP server and CLI/skills so external AI coding agents (Claude Code, Cursor, etc.) can operate on an Appwrite project, but there is no evidence of an in-dashboard/console AI chat assistant that users can converse with to write queries, debug errors, or get explanations directly inside the Appwrite UI.

   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”
   • [claimed-docs] “Skills are open-source Markdown files that give AI agents deep knowledge of Appwrite SDKs and services.”
   • [claimed-docs] “Appwrite allows you to build powerful AI powered applications with ease. Leverage Appwrite's powerful functions architecture and start build…”

   proof ↗⚑ flag

Vector

1. developerStore embeddings and run vector similarity search for AI features

   weight 3 · round to Supabase
   Supabase✓fullclaimed8/10

   Supabase explicitly ships pgvector-based AI toolkit and lists 'Vector embeddings' as a core product feature alongside its Postgres stack, directly enabling embedding storage and similarity search. missing for 10: no hands-on probe demonstrating actual vector search query execution, and no independent/community corroboration of vector search performance or usage.

   • [claimed-docs] “Supabase provides an open source toolkit for developing AI applications using Postgres and pgvector.”
   • [claimed-docs] “Add Authentication, Data APIs, Edge Functions, Realtime Data, Storage, and Vector embeddings.”
   • [claimed-docs] “Start your project with a Postgres database. Add Authentication, Data APIs, Edge Functions, Realtime Data, Storage, and Vector embeddings.”

   proof ↗⚑ flag

   Appwrite~partialclaimed5/10

   Appwrite's docs explicitly claim to "Store embeddings and run similarity search to power AI features" as part of its database product, but there is no detail on implementation (index types, distance metrics, API specifics) or any independent/hands-on corroboration that this works in practice. missing for 10: technical details on vector search API/config, independent or hands-on validation, performance/scale characteristics.

   • [claimed-docs] “Store embeddings and run similarity search to power AI features.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”
   • [claimed-docs] “Appwrite allows you to build powerful AI powered applications with ease. Leverage Appwrite's powerful functions architecture and start build…”

   proof ↗⚑ flag

Authentication

1. developerAdd email/password and social OAuth sign-in with the platform SDK in minutes

   weight 3 · round to Appwrite
   Supabase✓fullcommunity8/10

   Supabase Auth docs explicitly list password, magic link, OTP, social login, and SSO as supported methods, and community evidence confirms real developers implementing RLS + OAuth providers in production apps, indicating SDK-based setup works in practice. Missing for 10: no direct evidence of the specific SDK code snippets/quickstart timing claim ('minutes') or independent hands-on verification of OAuth setup speed.

   • [claimed-docs] “Your users can use many popular Auth methods, including password, magic link, one-time password (OTP), social login, and single sign-on (SSO…”
   • [community] “I built backend for my typing app using supabase with row level security(RLS) and OAuth providers to track... Supabase + SvelteKit + Cloudfl…”
   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”

   proof ↗⚑ flag

   Appwrite✓fullclaimed9/10

   Docs explicitly cover email/password login with Argon2 hashing in a few lines of code, plus OAuth sign-in with GitHub, Google, Facebook and 30+ providers via SDK, matching the story closely. Missing for 10: independent/hands-on developer confirmation of the 'minutes' setup time, as evidence is entirely vendor docs.

   • [claimed-docs] “Authenticate users with existing accounts from GitHub, Google, Facebook, and 30+ other providers.”
   • [claimed-docs] “Sign in users with multiple OAuth providers.”
   • [claimed-docs] “Email and password login with just a few lines of code secured with state of the art Argon2 hashing.”

   proof ↗⚑ flag

2. platform-engineerRequire MFA and enterprise SSO (SAML/OIDC) for my application users

   weight 2 · round to Appwrite
   Supabase~partialclaimed3/10

   Docs mention SSO as one of many supported auth methods, implying enterprise SSO (SAML/OIDC) support, but there is no evidence of MFA enforcement mechanisms or platform-level policy to require MFA/SSO for application users. missing for 10: explicit MFA requirement/enforcement docs, OIDC/SAML configuration details, admin controls to mandate SSO for all users, independent corroboration.

   • [claimed-docs] “Your users can use many popular Auth methods, including password, magic link, one-time password (OTP), social login, and single sign-on (SSO…”

   proof ↗⚑ flag

   Appwrite~partialclaimed4/10

   Appwrite's docs explicitly cover implementing MFA (appwrite-docs-4) and OAuth-based logins with 30+ providers (appwrite-docs-1, appwrite-docs-26), satisfying the MFA half of the story. However, there is no evidence of enterprise SSO protocols like SAML or OIDC being supported — only generic OAuth (Google, GitHub, Facebook, etc.) is documented, which is not the same as enterprise-grade SAML/OIDC federation. Missing for 10: explicit SAML/OIDC enterprise SSO support, admin-enforced MFA/SSO policy controls, and any enterprise identity-provider integration docs.

   • [claimed-docs] “Implementing MFA to add extra layers of security to your app.”
   • [claimed-docs] “Authenticate users with existing accounts from GitHub, Google, Facebook, and 30+ other providers.”
   • [claimed-docs] “Sign in users with multiple OAuth providers.”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round drawn
   Supabase—none0/10

   The evidence pack documents Supabase's REST API generation, RLS, realtime, storage, and CLI/MCP tooling, but nothing explicitly addresses bulk/batch operations (e.g., batch insert/update/delete across many rows or items) via the API, CLI, or MCP server. Postgres and PostgREST can technically support bulk SQL operations, but this capability is never documented or demonstrated in the evidence provided.

   ⚑ flag

   Appwrite—none0/10

   Evidence shows Appwrite's CLI can push/pull configuration and manage resources, and its MCP server lets LLMs call SDK methods, but there is no documentation of a bulk/batch API (e.g., batch create, update, or delete across many rows/files/users) that would let an AI-native user perform true bulk operations. Missing for 10: explicit bulk create/update/delete endpoints or CLI commands operating on many items in one call, and any hands-on confirmation of such batch semantics.

   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “you can split top-level resource arrays into separate JSON files with the `includes` field.”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to Appwrite
   Supabase~partialclaimed4/10

   Supabase's Realtime feature lets clients listen to Postgres changes and Edge Functions can act as serverless handlers, which together could be combined to react to database events, but the evidence pack contains no explicit rule-engine, database triggers/webhooks, or automation configuration UI for defining 'if event X then action Y' rules as an AI-native user would expect. missing for 10: explicit database triggers/webhooks documentation, a rules/automation configuration interface, and evidence of AI-native automatic action execution tied to events.

   • [claimed-docs] “Broadcast: Send low-latency messages between clients... Presence: Track and synchronize user state across clients... Postgres Changes: Liste…”
   • [claimed-docs] “Edge Functions are server-side TypeScript functions, distributed globally at the edge—close to your users.”
   • [claimed-docs] “Broadcast: Send low-latency messages between clients. Perfect for real-time messaging, database changes, cursor tracking, game events, and c…”
   • [claimed-docs] “Presence: Track and synchronize user state across clients. Ideal for showing who's online, or active participants.”

   proof ↗⚑ flag

   Appwrite~partialclaimed6/10

   Appwrite Functions can be triggered automatically by server events, webhooks, HTTP requests, SDK calls, and scheduled executions, and the docs mention responding to server events in realtime — this supports rule-like automation on events. However, there's no evidence of a dedicated declarative 'rules engine' (e.g., conditional trigger definitions, if-this-then-that style automation) beyond function triggers. Missing for 10: a first-class rules/automation builder distinct from writing custom Function code, and independent/hands-on validation of event-triggered automation reliability.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “Respond to server events in realtime.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Appwrite
   Supabase—none0/10

   The evidence pack covers Supabase's database, auth, storage, realtime, edge functions, CLI, and MCP integration, but contains no mention of a scheduling feature (e.g., pg_cron, scheduled Edge Functions, or workflow orchestration) for recurring jobs. No documentation, community report, or probe references any cron-like or recurring-job capability.

   ⚑ flag

   Appwrite✓fullclaimed6/10

   Appwrite Functions explicitly support 'scheduled executions' as a trigger type alongside HTTP, SDK, and webhook triggers, enabling recurring job/workflow automation directly in the platform (appwrite-docs-9). This is corroborated by the general functions/automation docs and CLI's ability to deploy functions programmatically (appwrite-docs-12, appwrite-docs-42), fitting an AI-native automation workflow. missing for 10: no docs detailing cron syntax or scheduling UI specifics, no mention of multi-step workflow orchestration beyond single-function triggers, and no independent/hands-on confirmation that scheduled executions work reliably in practice.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”

   proof ↗⚑ flag

4. ai-native userVersion, review, and roll back my automations

   weight 1 · round to Supabase
   Supabase~partialclaimed3/10

   Supabase's branching feature lets users create separate environments to test schema/config/feature changes without affecting production, which is a git-like versioning mechanism, but this applies to database schema/config rather than 'automations' specifically, and there is no explicit rollback or review (PR-style) workflow documented for Edge Functions, triggers, or other automation-like constructs. Missing for 10: explicit automation objects (workflows/triggers/functions) with versioning, diff/review, and one-click rollback; independent/hands-on confirmation of rollback working.

   • [claimed-docs] “You can use these branching environments to create and test changes like new configurations, database schemas, or features without affecting…”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project. You can use these branching environments to create and …”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project.”

   proof ↗⚑ flag

   Appwrite—none0/10

   No evidence of any version history, review workflow, or rollback mechanism for automations/functions in Appwrite. The CLI supports deploying/managing functions and configs, but there's no documented versioning, diffing, review process, or rollback capability for automations. missing for 10: version history for functions/automations, review/approval workflow, rollback/revert mechanism, audit trail of automation changes.

   ⚑ flag

Database

1. developerConnect to the underlying database with standard clients and ORMs via a connection string

   weight 2 · round to Supabase
   Supabase~partialcommunity5/10

   Supabase is built on Postgres and its docs confirm full self-hosting/local Postgres access and RLS-based auth (implying a standard Postgres connection string is available), but no evidence pack item explicitly documents the connection string format, ORM compatibility (e.g., Prisma, Drizzle), or connection pooling (pgbouncer/Supavisor) setup that developers typically need for direct client/ORM access. missing for 10: explicit docs on connection string/pooling, ORM-specific integration guides (Prisma/Drizzle/TypeORM), and independent hands-on confirmation of connecting via standard Postgres clients.

   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed service…”
   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements...”
   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”
   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [community] “The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dash…”
   • [community] “I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info... PostgREST's limita…”

   proof ↗⚑ flag

   Appwrite~partialclaimed4/10

   Appwrite documents a 'dedicated, native PostgreSQL database you connect to directly' as an option distinct from its managed API-based database, implying some direct-connection capability, but there is no explicit documentation of a connection string, standard driver, or ORM (e.g., Prisma, TypeORM) compatibility — the primary interface described elsewhere is via SDKs/REST APIs. Missing for 10: explicit connection-string format, confirmation of standard Postgres client/ORM compatibility, and independent corroboration of this direct-connect feature.

   • [claimed-docs] “A dedicated, native PostgreSQL database you connect to directly.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”
   • [claimed-docs] “An Appwrite database runs either on a shared pool that Appwrite manages for you, or on compute provisioned for your project alone.”

   proof ↗⚑ flag

2. developerProvision a managed database and read/write it from client and server SDKs

   weight 3 · round to Supabase
   Supabase✓fullprobed9/10

   Supabase provisions a managed Postgres database with instant REST/GraphQL APIs, auto-generated type-safe client SDKs, and server-side access via CLI/self-hosting, backed by docs, GitHub feature list, and hands-on probes confirming CLI/local provisioning works. Community evidence corroborates real-world usage building backends with RLS-secured reads/writes from clients (SvelteKit) and servers. Missing for 10: independent benchmark of production-scale read/write reliability and a fully hands-on client-SDK read/write test beyond CLI provisioning.

   • [claimed-docs] “Instant ready-to-use REST APIs.”
   • [claimed-docs] “Supabase APIs are generated from your database, which means that we can use database introspection to generate type-safe API definitions.”
   • [claimed-docs] “Instant ready-to-use **REST APIs**.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”
   • [claimed-docs] “Start with a quickstart guide to connect your project in minutes.”
   • [probe] “official CLI documented at https://supabase.com/docs/guides/local-development/cli/getting-started”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [community] “I built backend for my typing app using supabase with row level security(RLS) and OAuth providers to track... Supabase + SvelteKit + Cloudfl…”
   • [community] “Supabase is great and I've used it for a number of projects over the years... they are by far the cheapest hosted SQL offering I can find so…”

   proof ↗⚑ flag

   Appwrite✓fullclaimed8/10

   Appwrite's Databases docs describe managed (shared-pool or dedicated) databases with permissions and realtime access (appwrite-docs-23, appwrite-docs-36), structured relational data with typed columns and indexes (appwrite-docs-6), and even a dedicated native Postgres option (appwrite-docs-8). The CLI can generate type-safe SDKs tied to your database schema for both client and server use (appwrite-docs-41), and Appwrite's core SDK model (client/server) is implied throughout its docs ecosystem. Missing for 10: an explicit code sample showing client vs server SDK read/write calls, and independent hands-on verification of database read/write reliability beyond vendor docs.

   • [claimed-docs] “Structured, relational data with typed columns, rows, relationships, and indexes.”
   • [claimed-docs] “A dedicated, native PostgreSQL database you connect to directly.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”
   • [claimed-docs] “An Appwrite database runs either on a shared pool that Appwrite manages for you, or on compute provisioned for your project alone.”
   • [claimed-docs] “The generate command creates a type-safe SDK tailored to your project. It detects your project's language and generates typed helpers based …”

   proof ↗⚑ flag

3. developerExpress relational queries with joins, constraints, and transactions

   weight 2 · round to Supabase
   Supabase~partialcommunity6/10

   Supabase is built on Postgres, so full SQL relational capabilities (joins, constraints, transactions) are inherently available via direct Postgres connections, and evidence shows RLS policies and schema/migration support. However, the evidence pack focuses mainly on REST/PostgREST APIs, RLS, and CLI/branching rather than explicitly documenting joins, transactions, or foreign-key constraints, and community reports note PostgREST limitations pushing developers back to custom API servers. Missing for 10: explicit docs on PostgREST/join query syntax across relations, transaction support via API/client libraries, constraint definition examples, and independent confirmation these work smoothly at scale.

   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”
   • [claimed-docs] “create policy "Individuals can view their own todos." on todos for select to authenticated using ( (select auth.uid()) = user_id );”
   • [claimed-docs] “Supabase APIs are generated from your database, which means that we can use database introspection to generate type-safe API definitions.”
   • [community] “I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info... PostgREST's limita…”
   • [claimed-docs] “Instant ready-to-use REST APIs.”

   proof ↗⚑ flag

   Appwrite~partialclaimed2/10

   Appwrite's docs mention 'relationships' between typed columns/rows (appwrite-docs-6), implying some relational modeling, but there is no evidence of an actual join query syntax, constraint enforcement (e.g., foreign key/unique constraints), or multi-statement transactions. The dedicated PostgreSQL option (appwrite-docs-8) is a separate native database connection, not Appwrite's own query API, so it doesn't substantiate this capability either. missing for 10: explicit join query syntax/examples, constraint definitions (unique/foreign key), transactional guarantees or ACID transaction support, independent verification of any of these.

   • [claimed-docs] “Structured, relational data with typed columns, rows, relationships, and indexes.”
   • [claimed-docs] “A dedicated, native PostgreSQL database you connect to directly.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”

   proof ↗⚑ flag

Realtime

1. developerBuild offline-capable clients whose local writes sync automatically on reconnect

   weight 2 · round drawn
   Supabase—none0/10

   The evidence pack covers Supabase's Realtime (Broadcast, Presence, Postgres Changes), Auth, Storage, and local dev CLI, but nothing addresses offline-first client SDKs, local write queuing, conflict resolution, or automatic sync-on-reconnect. Community threads even flag local development and migrations as weak points, with no mention of offline capability.

   • [claimed-docs] “Broadcast: Send low-latency messages between clients... Presence: Track and synchronize user state across clients... Postgres Changes: Liste…”
   • [claimed-docs] “Broadcast: Send low-latency messages between clients. Perfect for real-time messaging, database changes, cursor tracking, game events, and c…”
   • [claimed-docs] “Presence: Track and synchronize user state across clients. Ideal for showing who's online, or active participants.”
   • [community] “The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dash…”
   • [community] “Even though it looks like a great product initially, it has a lot of errors and bugs when you are trying to actually build something more ro…”

   proof ↗⚑ flag

   Appwrite—none0/10

   No evidence pack items mention offline support, local write queuing, conflict resolution, or sync-on-reconnect capabilities; documentation only covers realtime server events broadcast, not client-side offline persistence. Appwrite's realtime features (appwrite-docs-5, appwrite-docs-28) address live sync while connected, but nothing indicates an offline-first SDK or local cache with automatic reconciliation.

   • [claimed-docs] “Track which signed-in users are active right now and broadcast online, typing, and viewing status in realtime.”
   • [claimed-docs] “Respond to server events in realtime.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”

   proof ↗⚑ flag

2. developerTrack user presence and broadcast ephemeral state between connected clients

   weight 1 · round to Supabase
   Supabase✓fullcommunity9/10

   Supabase Realtime explicitly documents Presence for tracking/synchronizing user state ('who's online') and Broadcast for sending low-latency ephemeral messages between clients, and a launch community post confirms real-world usage at scale (~2000 concurrent users). Missing for 10: independent hands-on verification of presence/broadcast APIs beyond docs and one launch anecdote.

   • [claimed-docs] “Broadcast: Send low-latency messages between clients... Presence: Track and synchronize user state across clients... Postgres Changes: Liste…”
   • [claimed-docs] “Broadcast: Send low-latency messages between clients. Perfect for real-time messaging, database changes, cursor tracking, game events, and c…”
   • [claimed-docs] “Presence: Track and synchronize user state across clients. Ideal for showing who's online, or active participants.”
   • [claimed-docs] “Chat applications - Real-time messaging with typing indicators and online presence”
   • [community] “Supabase CEO on Realtime Multiplayer launch: added Broadcast (ephemeral messages) and Presence (eventually-consistent state) to the Realtime…”

   proof ↗⚑ flag

   Appwrite✓fullclaimed8/10

   Appwrite's docs explicitly describe tracking online/typing/viewing presence and broadcasting realtime status between clients, backed by a general realtime event system for databases and server events. Missing for 10: independent hands-on verification of presence/typing broadcast specifically (only vendor docs cited), and no code example showing ephemeral state channels.

   • [claimed-docs] “Track which signed-in users are active right now and broadcast online, typing, and viewing status in realtime.”
   • [claimed-docs] “Respond to server events in realtime.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”

   proof ↗⚑ flag

3. developerSubscribe to live data changes so my UI updates in real time without polling

   weight 3 · round to Supabase
   Supabase✓fullcommunity9/10

   Supabase Realtime explicitly supports Postgres Changes (listen to DB changes in real-time), plus Broadcast and Presence, enabling UI updates without polling, and community evidence confirms real-world usage (Realtime Multiplayer launch with concurrent users, developers building chat/typing apps on it). Missing for 10: independent hands-on benchmark of Postgres Changes latency/reliability at scale beyond the CEO's launch post.

   • [claimed-docs] “Broadcast: Send low-latency messages between clients... Presence: Track and synchronize user state across clients... Postgres Changes: Liste…”
   • [claimed-docs] “Broadcast: Send low-latency messages between clients. Perfect for real-time messaging, database changes, cursor tracking, game events, and c…”
   • [claimed-docs] “Presence: Track and synchronize user state across clients. Ideal for showing who's online, or active participants.”
   • [claimed-docs] “Chat applications - Real-time messaging with typing indicators and online presence”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”
   • [community] “Supabase CEO on Realtime Multiplayer launch: added Broadcast (ephemeral messages) and Presence (eventually-consistent state) to the Realtime…”
   • [community] “I built backend for my typing app using supabase with row level security(RLS) and OAuth providers to track... Supabase + SvelteKit + Cloudfl…”

   proof ↗⚑ flag

   Appwrite✓fullclaimed6/10

   Appwrite's docs explicitly reference realtime capabilities for databases (broadcasting online/typing/viewing status, 'managed APIs with permissions and realtime', and 'respond to server events in realtime'), indicating a live-subscription mechanism for UI updates without polling. missing for 10: no first-party API/SDK code example for subscribing to database document changes, and no independent/hands-on verification of the realtime channel actually pushing updates.

   • [claimed-docs] “Track which signed-in users are active right now and broadcast online, typing, and viewing status in realtime.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”
   • [claimed-docs] “Respond to server events in realtime.”

   proof ↗⚑ flag

Search

1. developerRun full-text search over my data without wiring up an external search service

   weight 2 · round drawn
   Supabase—none0/10

   The evidence pack covers Supabase's database, realtime, auth, storage, vector/AI, and CLI/MCP capabilities extensively, but nowhere mentions Postgres full-text search (tsvector, GIN indexes, or a dedicated search feature). Full-text search is a fair axis for a database-as-a-service product, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag

   Appwrite—none0/10

   The evidence pack describes Appwrite's database as supporting typed columns, relationships, and generic 'indexes' (appwrite-docs-6, appwrite-docs-23) and vector similarity search for embeddings (appwrite-docs-7), but nowhere documents a full-text search capability (e.g., fulltext index type or search query operators). Since no evidence confirms this specific capability, the axis applies but is unmet.

   • [claimed-docs] “Structured, relational data with typed columns, rows, relationships, and indexes.”
   • [claimed-docs] “Store embeddings and run similarity search to power AI features.”
   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”

   proof ↗⚑ flag

1. developerRun functions automatically in response to database or auth events

   weight 2 · round to Appwrite
   Supabase~partialclaimed3/10

   Supabase does offer Edge Functions (supabase-docs-8) and real-time Postgres Changes streaming (supabase-docs-5/22/23), which are the building blocks for event-driven execution, but the evidence pack never documents the actual Database Webhooks / Auth Hooks mechanism that automatically invokes a function on insert/update/delete or auth events. Missing for 10: explicit docs or hands-on proof of Database Webhooks/Auth Hooks wiring DB/auth events directly to function invocation, and any developer confirmation that this works reliably in practice.

   • [claimed-docs] “Edge Functions are server-side TypeScript functions, distributed globally at the edge—close to your users.”
   • [claimed-docs] “Broadcast: Send low-latency messages between clients... Presence: Track and synchronize user state across clients... Postgres Changes: Liste…”
   • [claimed-docs] “Broadcast: Send low-latency messages between clients. Perfect for real-time messaging, database changes, cursor tracking, game events, and c…”
   • [claimed-docs] “Presence: Track and synchronize user state across clients. Ideal for showing who's online, or active participants.”

   proof ↗⚑ flag

   Appwrite✓fullclaimed7/10

   Appwrite's docs explicitly state that Functions can be triggered by server events (e.g., database and auth events) in addition to HTTP, SDK, webhooks, and scheduled triggers, directly matching the story of running functions automatically on database/auth events. Missing for 10: no explicit enumeration of specific database/auth event types (e.g., document.create, user.create) and no independent/hands-on confirmation of event-triggered execution.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “Respond to server events in realtime.”

   proof ↗⚑ flag

2. developerDeploy server-side functions invoked by HTTP or SDK calls without managing servers

   weight 3 · round drawn
   Supabase✓fullclaimed8/10

   Supabase Edge Functions are explicitly documented as server-side TypeScript functions distributed globally, invocable via HTTP or client SDKs, without server management — matching the story directly. Community evidence corroborates broader platform reliability and real usage, though nothing specifically stress-tests Edge Functions at scale. missing for 10: independent hands-on validation of Edge Function invocation/scaling, and details on cold-start/latency limits.

   • [claimed-docs] “Edge Functions are server-side TypeScript functions, distributed globally at the edge—close to your users.”
   • [claimed-docs] “Add Authentication, Data APIs, Edge Functions, Realtime Data, Storage, and Vector embeddings.”
   • [claimed-docs] “Start your project with a Postgres database. Add Authentication, Data APIs, Edge Functions, Realtime Data, Storage, and Vector embeddings.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”

   proof ↗⚑ flag

   Appwrite✓fullclaimed8/10

   Appwrite Functions are explicitly documented as serverless compute triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions, and the CLI supports creating/deploying these functions, matching the story directly. Missing for 10: independent hands-on verification of function deployment/runtime behavior, and more detail on scaling/cold-start characteristics.

   • [claimed-docs] “These Functions can be triggered by HTTP requests, SDK methods, server events, webhooks, and scheduled executions.”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”

   proof ↗⚑ flag

Ai provisioning

1. ai-native userHave an agent stand up a new backend — schema, auth, and policies — headlessly from the CLI in a script

   weight 3 · round to Appwrite
   Supabase✓fullprobed7/10

   The CLI supports fully headless project scaffolding (`supabase init`/`start`) with no login or key required, confirmed by hands-on probes, and Postgres RLS policies (schema/auth authorization) are defined declaratively in SQL that can be run via the CLI/migrations, matching the 'headless from a script' requirement. missing for 10: explicit hands-on evidence of scripting auth-provider configuration and RLS policy deployment together via `supabase db push`/migrations in one automated flow, and independent (non-vendor) confirmation of a full agent-driven backend bootstrap.

   • [claimed-docs] “With two commands, you can set up and start a new local project: 1. `supabase init` to create a new local project 2. `supabase start` to lau…”
   • [claimed-docs] “With two commands, you can set up and start a new local project: 1. supabase init to create a new local project 2. supabase start to launch …”
   • [claimed-docs] “supabase init to create a new local project 2. supabase start to launch the Supabase services”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [claimed-docs] “create policy "Individuals can view their own todos." on todos for select to authenticated using ( (select auth.uid()) = user_id );”
   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”
   • [claimed-docs] “Your users can use many popular Auth methods, including password, magic link, one-time password (OTP), social login, and single sign-on (SSO…”
   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”

   proof ↗⚑ flag

   Appwrite✓fullprobed8/10

   Appwrite's CLI explicitly supports non-interactive/headless scripted usage (appwrite-docs-42), can create/manage projects, resources, users, functions, deployments (appwrite-docs-12/18/32), and databases/auth/policies are all provisionable via the CLI/API per the docs; this is exactly the kind of scriptable backend-standup an agent could drive headlessly. missing for 10: no end-to-end hands-on example/transcript of an agent actually scripting full schema+auth+policy setup in one script, and no independent/community verification of headless CLI workflows.

   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “Structured, relational data with typed columns, rows, relationships, and indexes.”
   • [claimed-docs] “Appwrite offers a Model Context Protocol (MCP) server that allows LLMs to directly interact with Appwrite's API and docs.”
   • [claimed-docs] “you can use applications such as Claude Code, Codex, Cursor, Claude Desktop, and others to operate on your Appwrite project as well as gain …”
   • [probe] “official CLI documented at https://appwrite.io/docs/tooling/command-line/installation”

   proof ↗⚑ flag

Local

1. developerRun the whole backend stack locally with an emulator or CLI before deploying

   weight 3 · round to Appwrite
   Supabase!disputedcontradicted5/10

   Docs and a keyless hands-on probe confirm the Supabase CLI (`supabase init`/`supabase start`) can spin up the entire stack (DB, Auth, Storage, Realtime, Functions) locally before deploying, which is exactly what the story asks for. However, independent hands-on community reports directly contradict smooth delivery — one calls local dev/migration 'Supabase's biggest weakness' and another describes it as 'a massive pain with random bugs' making the whole platform feel 'like a hack'. Missing for 10: consistent independent corroboration that local stack runs reliably without the bugs/friction reported by hands-on users.

   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [claimed-docs] “With two commands, you can set up and start a new local project: 1. `supabase init` to create a new local project 2. `supabase start` to lau…”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [community] “The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dash…”
   • [community] “Even though it looks like a great product initially, it has a lot of errors and bugs when you are trying to actually build something more ro…”

   proof ↗⚑ flag

   Appwrite~partialprobed6/10

   Appwrite is designed for self-hosting via Docker CLI and one-click marketplace installs, and the Appwrite CLI can manage projects, resources, and functions, including non-interactively — supporting local backend development before deploying to cloud. However, there is no explicit emulator/local-stack CLI command (like 'appwrite emulators start') mirroring the full backend for offline testing, and no direct evidence of a documented local dev workflow tying CLI + self-hosted Docker together as a single 'local emulator' story. missing for 10: dedicated local-emulator tooling or docs explicitly describing running the full stack locally via CLI for pre-deploy testing, independent hands-on confirmation of this workflow.

   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI.”
   • [claimed-docs] “Recommended: Use these pre-configured marketplace apps for instant setup:”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [probe] “official CLI documented at https://appwrite.io/docs/tooling/command-line/installation”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Supabase
   Supabase~partialprobed7/10

   Supabase auto-generates REST/GraphQL APIs directly from the Postgres schema, exposes an openapi.json spec (confirmed live via probe), and ships a CLI/MCP server that lets an AI agent provision, configure, and query projects headlessly (supabase-docs-13, supabase-gh-2, supabase-probe-3, supabase-probe-6, supabase-probe-8). This gives strong data/API-layer parity with the dashboard for CRUD, auth, storage, and realtime features. However, the evidence pack never confirms parity for dashboard-only administrative actions (billing, org/project creation, scaling settings) via a documented Management API, and community notes point to real friction (PostgREST/RLS limitations, CLI instability) that complicate full UI-equivalent control (supabase-comm-10, supabase-comm-12). Missing for 10: explicit Management API docs covering billing/org/project-lifecycle actions, and independent verification that all dashboard settings are scriptable.

   • [claimed-docs] “Instant ready-to-use REST APIs.”
   • [github] “Auto-generated APIs. - [x] REST. [Docs] - [x] GraphQL. [Docs] - [x] Realtime subscriptions.”
   • [probe] “PROBE openapi: HTTP 200 at https://supabase.com/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://supabase.com/docs/guides/local-development/cli/getting-started”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [community] “I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info... PostgREST's limita…”
   • [community] “The Supabase CLI is updated every single time I run `brew upgrade`. It makes me feel like I'm trying to swing a bat around, except it's made…”

   proof ↗⚑ flag

   Appwrite~partialprobed6/10

   Appwrite's docs confirm the CLI/API can create and manage projects, resources (rows, files, users), and deploy Functions—core operations that mirror UI actions—and the platform is explicitly API/SDK-first with MCP and CLI tooling for automation (appwrite-docs-12, appwrite-docs-18, appwrite-docs-32, appwrite-probe-4, appwrite-probe-5). However, there's no explicit vendor statement or independent verification of full UI-API parity, and the OpenAPI spec probe returned 404s, leaving some doubt about complete coverage of every UI action. Missing for 10: an explicit API-completeness statement, a working public OpenAPI/spec reference, and independent confirmation that all UI-only settings (e.g., billing, org management) are also API-accessible.

   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [probe] “official MCP server documented at https://appwrite.io/docs/tooling/ai/mcp-servers”
   • [probe] “official CLI documented at https://appwrite.io/docs/tooling/command-line/installation”
   • [probe] “PROBE openapi: all candidate paths 404 (https://appwrite.io/openapi.json, https://appwrite.io/swagger.json, https://appwrite.io/api/openapi.…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Appwrite
   Supabase~partialcommunity5/10

   Supabase is built on Postgres and offers self-hosting for 'full control over your data,' implying standard SQL/pg_dump portability and no lock-in, but the evidence pack contains no explicit documentation of a data-export feature, backup/download tooling, or migration-out guide. Missing for 10: explicit export/backup documentation (e.g., pg_dump instructions or a dashboard 'export project' feature), independent confirmation that self-hosted migration actually works cleanly, and any community report of successfully exporting/leaving.

   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed service…”
   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements...”
   • [github] “We're building the features of Firebase using enterprise-grade open source tools.”
   • [community] “How easy is it to self host Supabase? Is it more like 'we're open-source, but good luck getting this deployed!'... I wonder if people are do…”

   proof ↗⚑ flag

   Appwrite~partialclaimed6/10

   Appwrite documents self-hosting with 'full control over data location' and one-click migrations between Appwrite Cloud and self-hosted (and from Firebase/Supabase/NHost), plus a CLI that manages/exports resources (rows, files, users) into JSON files, all supporting data portability and open formats. However, there is no single documented 'export all my data' feature or explicit open-format export guarantee spanning all resource types. Missing for 10: an explicit full-data export/backup command or documented complete data-portability workflow, and independent verification that migrations/export are lossless and comprehensive.

   • [claimed-docs] “One-Click migrations lets you migrate from Firebase, Supabase, and NHost. You can also migrate between Appwrite Cloud and self-hosted.”
   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI.”
   • [claimed-docs] “Full control over data location”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “you can split top-level resource arrays into separate JSON files with the `includes` field.”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round drawn
   Supabase✓fullclaimed7/10

   The GitHub repo (supabase/supabase) is explicitly described as built with 'enterprise-grade open source tools' and aims to give a 'Firebase-like developer experience using open source tools,' and the docs describe self-hosting for full control over data, confirming the source is publicly available and open. Missing for 10: explicit citation of the license file/name (e.g., Apache 2.0) and independent confirmation of license terms beyond marketing language.

   • [github] “We're building the features of Firebase using enterprise-grade open source tools.”
   • [github] “Our aim is to give developers a Firebase-like developer experience using open source tools.”
   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed service…”
   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements...”

   proof ↗⚑ flag

   Appwrite✓fullprobed7/10

   Appwrite's own docs and llms.txt describe it as an 'open-source backend platform' and the project is hosted publicly on GitHub (appwrite-gh-1), with extensive self-hosting documentation confirming the source is available for anyone to run and inspect (appwrite-docs-14, appwrite-docs-19, appwrite-probe-1). This satisfies the core story that an AI-native user can read the source under an open license. Missing for 10: explicit citation of the specific license name (e.g. BSD-3-Clause) or a link to a LICENSE file, and independent confirmation of license terms beyond self-hosting claims.

   • [github] “Integrated hosting platform to deploy and scale web applications with support for custom domains, SSR, and seamless backend integration. Git…”
   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://appwrite.io/llms.txt # Appwrite > Appwrite is an open-source backend platform with authentication, data…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Supabase✓fullprobed9/10

   Supabase explicitly documents self-hosting as a supported deployment model for full data control/compliance, with docs and CLI tooling (supabase init/start) to run the entire stack locally or in CI, corroborated by a hands-on probe confirming headless local provisioning. missing for 10: independent hands-on verification of a full production self-hosted deployment (beyond local dev) and community reports raise friction/rough edges in self-hosting experience.

   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed service…”
   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements...”
   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [community] “How easy is it to self host Supabase? Is it more like 'we're open-source, but good luck getting this deployed!'... I wonder if people are do…”

   proof ↗⚑ flag

   Appwrite✓fullcommunity9/10

   Appwrite documents itself as designed from the ground up for self-hosting via Docker, with one-click marketplace deployments, full control over data location, and explicit self-hosted CLI/endpoint support; community evidence corroborates a strong self-hosting experience. missing for 10: independent hands-on verification of feature parity between cloud and self-hosted beyond docs/community anecdotes.

   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “Use a one-click deployment - Choose from marketplace installations for instant setup”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI.”
   • [claimed-docs] “Full control over data location”
   • [claimed-docs] “Recommended: Use these pre-configured marketplace apps for instant setup:”
   • [claimed-docs] “You want to manage your own infrastructure”
   • [claimed-docs] “Add the --endpoint flag if you're using a self-hosted instance of Appwrite.”
   • [community] “Thank you so much for Appwrite! The community on Discord is very helpful and the self hosting guide is great. Very unlike my terrible experi…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Appwrite
   Supabase~partialclaimed5/10

   Supabase docs claim self-hosting as an option for users needing 'full control over your data' or compliance requirements, which implies data residency control by running your own infrastructure (supabase-docs-3/29). However, the evidence pack contains no explicit documentation of region selection for hosted/managed Supabase projects (e.g., a region picker at project creation), which is the more common AI-native use case. Missing for 10: explicit hosted-plan region selection docs, confirmation of available regions, and independent verification of residency guarantees.

   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements that prevent you from using managed service…”
   • [claimed-docs] “Self-hosting is a good fit if you need full control over your data, have compliance requirements...”

   proof ↗⚑ flag

   Appwrite~partialclaimed6/10

   Appwrite's self-hosting docs explicitly state 'full control over data location' and that it can be installed on any Docker-capable infrastructure, letting AI-native users choose where their data resides by hosting themselves (appwrite-docs-24, appwrite-docs-14/19/33). However, there is no evidence of a managed-cloud region-selection feature (e.g., picking an AWS/GCP region in Appwrite Cloud) for users who don't want to self-host. Missing for 10: cloud region/residency selector, explicit list of supported regions for hosted Appwrite, and independent confirmation of data-residency guarantees.

   • [claimed-docs] “Full control over data location”
   • [claimed-docs] “Appwrite was designed from the ground up with self-hosting in mind. You can install and run Appwrite on any operating system that can run a …”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI.”
   • [claimed-docs] “You can install and run Appwrite on any operating system that can run a Docker CLI”
   • [claimed-docs] “You want to manage your own infrastructure”

   proof ↗⚑ flag

2. ai-native userControl data retention and deletion

   weight 2 · round to Appwrite
   Supabase—none0/10

   The evidence pack shows Supabase's self-hosting option ('full control over your data') and RLS/storage access controls, but nothing documents explicit data-retention policies, project/data deletion tooling, backup expiry controls, or user-data erasure workflows that would let an AI-native user manage retention/deletion. Missing for 10: documented deletion APIs (e.g., project/user data deletion), retention policy settings, backup lifecycle controls, and GDPR-style data erasure guarantees.

   ⚑ flag

   Appwrite~partialclaimed4/10

   Appwrite exposes basic delete APIs for files (appwrite-docs-10) and CLI-driven resource management (users, rows, files) (appwrite-docs-12/18/32), and self-hosting gives 'full control over data location' (appwrite-docs-24), which together let an operator remove or relocate data. However there is no documented retention-policy tooling (TTL/expiry rules), no explicit GDPR-style 'delete all user data' workflow, and no data-export/erasure certification beyond generic SOC-2/HIPAA/BAA mentions (appwrite-docs-20). Missing for 10: explicit retention/expiry configuration, documented right-to-erasure workflow, and independent verification of deletion completeness.

   • [claimed-docs] “It provides APIs to upload, download, delete, and list files, with many added utilities.”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions”
   • [claimed-docs] “Full control over data location”
   • [claimed-docs] “SOC-2, HIPAA, and BAA”

   proof ↗⚑ flag

3. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Supabase—none0/10

   No evidence pack item discusses telemetry, usage tracking, opt-out settings, or privacy controls for CLI/dashboard analytics; the pack covers unrelated product features (auth, storage, realtime, MCP, self-hosting). Missing for 10: any docs or settings referencing telemetry collection, an opt-out flag/env var, or privacy policy statement on usage data.

   ⚑ flag

   Appwrite—none0/10

   No evidence in the pack addresses telemetry opt-out or usage tracking controls for Appwrite; while self-hosting (full data control) is documented, there's no explicit statement about disabling telemetry/analytics collection.

   ⚑ flag

Ai migrations

1. ai-native userLet an agent create and test schema changes in an isolated branch or preview environment before production

   weight 3 · round to Supabase
   Supabase~partialprobed7/10

   Supabase documents a first-class branching feature explicitly for testing schema changes in isolation before production (supabase-docs-10/17/24), and separately provides an MCP server plus CLI that let AI agents interact with and provision projects programmatically (supabase-docs-1/27, supabase-probe-4/6/7/8). However, there is no direct evidence tying agent/MCP workflows to the branching feature itself, and community feedback flags migration/local-dev tooling as a weak point ('local development & database migration story is Supabase's biggest weakness' — supabase-comm-7) and notes AI agents often run with elevated service_role access that bypasses RLS (supabase-comm-15), raising safety caveats for autonomous schema testing. Missing for 10: explicit documentation/example of an agent using MCP+CLI to create a branch, apply/test schema changes, and promote to production; independent hands-on validation of that full agent-branch loop.

   • [claimed-docs] “You can use these branching environments to create and test changes like new configurations, database schemas, or features without affecting…”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project. You can use these branching environments to create and …”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project.”
   • [claimed-docs] “Once connected, your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [claimed-docs] “your AI assistants can interact with and query your Supabase projects on your behalf.”
   • [probe] “official MCP server documented at https://supabase.com/docs/guides/ai-tools/mcp”
   • [probe] “PROBE cli-runtime: npx -y supabase --version → "2.116.0" — official Supabase CLI installs from npm and runs headlessly (hands-on, keyless)”
   • [probe] “PROBE mcp-handshake: POST JSON-RPC initialize to https://mcp.supabase.com/mcp → HTTP 401 {"message":"Unauthorized"} — live remote MCP server…”
   • [probe] “PROBE headless-init: npx supabase init in an empty directory scaffolds supabase/config.toml with no login or key — an agent can provision a …”
   • [community] “The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dash…”
   • [community] “The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) p…”

   proof ↗⚑ flag

   Appwrite—none0/10

   No evidence of branch/preview environments for schema changes—Appwrite offers CLI, MCP server, and self-hosting, but nothing about isolated branches or preview environments for testing schema migrations before production. missing for 10: branching/preview environment feature, schema diff/staging workflow, agent-driven isolated testing capability.

   ⚑ flag

Migrations

1. developerManage schema changes as version-controlled migrations applied via the CLI or CI

   weight 3 · round to Appwrite
   Supabase!disputedcontradicted4/10

   Docs confirm the Supabase CLI can run the full stack locally and in CI environments (supabase-docs-21) and branching lets you test schema changes outside production (supabase-docs-10/17), implying a migrations-in-CI workflow, but the evidence pack never shows an actual migration/diff/push command being used. A hands-on community report explicitly states 'The local development & database migration story is Supabase's biggest weakness... I hate having to do migrations live in prod' (supabase-comm-7), directly contradicting the implied smooth CLI/CI migration workflow. missing for 10: explicit evidence of `supabase migration new`/`db push`/`db diff` commands, a documented CI pipeline example, and independent corroboration that migrations work reliably in production.

   • [claimed-docs] “The Supabase CLI enables you to run the entire Supabase stack locally, on your machine or in a CI environment.”
   • [claimed-docs] “You can use these branching environments to create and test changes like new configurations, database schemas, or features without affecting…”
   • [claimed-docs] “Supabase branches create separate environments that spin off from your main project. You can use these branching environments to create and …”
   • [community] “The local development & database migration story is Supabase's biggest weakness. I hate having to do migrations live in prod. The admin dash…”

   proof ↗⚑ flag

   Appwrite~partialclaimed5/10

   Appwrite's CLI can manage and push project resources (collections/attributes) defined in JSON config files, and supports a documented non-interactive/headless mode explicitly for CI automation, which covers schema-as-code applied via CLI/CI. However, there's no evidence of a dedicated migrations framework with versioned history, diffing, or rollback semantics — only generic 'push resources' and 'one-click migrate from other platforms' (data migration, not schema versioning). Missing for 10: explicit migration/version-history commands, rollback support, and independent confirmation of CI-based schema migration workflows in practice.

   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions, and other …”
   • [claimed-docs] “you can split top-level resource arrays into separate JSON files with the `includes` field.”
   • [claimed-docs] “This includes creating and managing projects, managing resources (rows, files, users), creating and deploying Appwrite Functions”
   • [claimed-docs] “The Appwrite CLI can be used in a non-interactive and headless manner, without saving configuration or sessions. This is especially useful w…”
   • [claimed-docs] “One-Click migrations lets you migrate from Firebase, Supabase, and NHost. You can also migrate between Appwrite Cloud and self-hosted.”
   • [claimed-docs] “Add the --endpoint flag if you're using a self-hosted instance of Appwrite.”

   proof ↗⚑ flag

Type safety

1. developerGenerate typed client code (e.g. TypeScript types) from my schema automatically

   weight 2 · round to Supabase
   Supabase✓fullclaimed8/10

   Supabase documents generating type-safe TypeScript definitions (database.types.ts) directly from database introspection via CLI/API tooling, a core first-party feature. Missing for 10: independent/hands-on confirmation of the generated types working in a real project and coverage of edge cases (e.g., custom types, enums) beyond docs.

   • [claimed-docs] “Generate types for your project to produce the `database.types.ts` file”
   • [claimed-docs] “Supabase APIs are generated from your database, which means that we can use database introspection to generate type-safe API definitions.”

   proof ↗⚑ flag

   Appwrite✓fullclaimed7/10

   Appwrite's CLI has a documented `generate` command that detects the project's language and generates a type-safe SDK with typed helpers based on the database schema, directly matching the story of generating typed client code from schema. Missing for 10: no independent/hands-on corroboration of the generate command's output quality, and no detail on which languages/types are supported beyond TypeScript.

   • [claimed-docs] “The generate command creates a type-safe SDK tailored to your project. It detects your project's language and generates typed helpers based …”

   proof ↗⚑ flag

Access control

1. developerRestrict data access per user with row-level security policies or security rules

   weight 3 · round to Supabase
   Supabase~partialcommunity7/10

   Supabase's docs clearly document RLS policy syntax (e.g. per-user select policies using auth.uid()) and extend fine-grained access control to Storage, directly matching the story. However, community evidence shows real-world friction: RLS limitations forcing workarounds (multiple user tables), an MCP integration that bypasses RLS via service_role, and reports of RLS being tricky to get right initially. missing for 10: independent hands-on verification that policies enforce correctly across all Supabase products, clearer documentation on avoiding service_role bypass pitfalls, and resolution of cited RLS/auth issues left open for over a year.

   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”
   • [claimed-docs] “create policy "Individuals can view their own todos." on todos for select to authenticated using ( (select auth.uid()) = user_id );”
   • [claimed-docs] “Fine-grained Access Control - Manage file permissions with row-level security and custom policies”
   • [community] “I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info... PostgREST's limita…”
   • [community] “I hadn't touched SQL for almost 7 years, but dipped my toes back in to build a PoC using Supabase. Despite some initial pains around RLS, I'…”
   • [community] “The cursor assistant operates the Supabase database with elevated access via the service_role, which bypasses all row-level security (RLS) p…”
   • [community] “I built backend for my typing app using supabase with row level security(RLS) and OAuth providers to track... Supabase + SvelteKit + Cloudfl…”

   proof ↗⚑ flag

   Appwrite~partialclaimed3/10

   Appwrite docs mention databases with 'permissions' as part of managed APIs, implying per-resource access control, but the evidence pack lacks detail on document/row-level permission rules, role-based read/write scoping, or policy syntax. Missing for 10: explicit documentation of row/document-level permission model, examples of user/team/role-based access rules, and any hands-on confirmation of enforcement.

   • [claimed-docs] “Choose the database that fits your use case, from managed APIs with permissions and realtime to dedicated native engines you connect to dire…”

   proof ↗⚑ flag

Data protection

1. platform-engineerRely on automated backups and point-in-time recovery for my data

   weight 2 · round drawn
   Supabase—none0/10

   The evidence pack contains no vendor-tier documentation describing automated backups or point-in-time recovery (PITR) features; the only related evidence is a community report (supabase-comm-9) describing nightly pg_dump backups causing write-contention problems and the team merely 'investigating' moving customers to PITR. Since a disputed verdict requires a vendor claim tier plus a contradicting tier, and no first-party docs claim exists here, there is insufficient evidence the capability is delivered at all.

   • [community] “Supabase CEO responding to Val Town's migration postmortem: nightly pg_dump backups caused write-contention issues at midnight on a write-he…”

   proof ↗⚑ flag

   Appwrite—none0/10

   No evidence in the pack mentions automated backups, snapshotting, or point-in-time recovery features for Appwrite databases; the closest related material covers self-hosting, migrations between platforms, and general database product features, none of which address backup/PITR. Missing for 10: any mention of backup scheduling, retention policies, restore/point-in-time recovery tooling, or disaster-recovery documentation.

   ⚑ flag

Files

1. developerUpload and serve user files with access rules and CDN-backed delivery

   weight 3 · round to Supabase
   Supabase✓fullcommunity7/10

   Supabase Storage docs explicitly describe fine-grained access controls via RLS policies and 'optimized delivery' for files of any size, directly matching the story's core ask (upload, access rules, CDN-like delivery). Community feedback confirms real-world usage of RLS with storage but notes storage still lacks direct metadata support, a secondary limitation rather than a failure of access control or delivery. Missing for 10: explicit mention of CDN infrastructure/edge caching details and independent hands-on confirmation of CDN-backed delivery performance.

   • [claimed-docs] “Supabase Storage is a robust, scalable solution for managing files of any size with fine-grained access controls and optimized delivery.”
   • [claimed-docs] “Fine-grained Access Control - Manage file permissions with row-level security and custom policies”
   • [claimed-docs] “Postgres Row Level Security (RLS) gives you granular authorization rules that run inside the database.”
   • [community] “I have been developing with Supabase past two months... there are still some rough corners in general and some basic features missing. Examp…”

   proof ↗⚑ flag

   Appwrite~partialclaimed4/10

   Docs confirm core file storage APIs (upload, download, delete, list, plus unspecified utilities) but the evidence pack never explicitly documents per-file access/permission rules or CDN-backed delivery for storage. Missing for 10: explicit documentation of file-level permission/access rules, CDN or edge-caching delivery mechanism, and any hands-on/independent confirmation of these behaviors.

   • [claimed-docs] “It provides APIs to upload, download, delete, and list files, with many added utilities.”

   proof ↗⚑ flag

2. developerServe resized or transformed images from storage without running my own image pipeline

   weight 1 · round drawn
   Supabase—none0/10

   The evidence only describes Supabase Storage generally as offering 'fine-grained access controls and optimized delivery' (supabase-docs-7, supabase-docs-30) but never mentions image resizing, transformation parameters, or a CDN-based image pipeline feature. Missing for 10: any documentation of an image transformation/resizing API or CDN, hands-on proof of resized image delivery.

   • [claimed-docs] “Supabase Storage is a robust, scalable solution for managing files of any size with fine-grained access controls and optimized delivery.”
   • [claimed-docs] “Fine-grained Access Control - Manage file permissions with row-level security and custom policies”

   proof ↗⚑ flag

   Appwrite—none0/10

   The evidence pack only says Storage provides upload/download/delete/list APIs with vague 'added utilities' (appwrite-docs-10), but nowhere documents an image resize/transform/preview endpoint that would let a developer serve transformed images without a custom pipeline.

   • [claimed-docs] “It provides APIs to upload, download, delete, and list files, with many added utilities.”

   proof ↗⚑ flag