Firebase vs Appwrite

Agent access

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

   weight 2 · round to Appwrite
   Firebase—none0/10

   A direct probe shows firebase.google.com/llms.txt returns 404, and no evidence pack item shows any agent-oriented docs bundle or llms.txt equivalent; the MCP server (firebase-docs-12) is a separate tool-integration axis, not an agent-readable docs file.

   • [probe] “PROBE llms.txt: HTTP 404 at https://firebase.google.com/llms.txt”

   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 Appwrite
   Firebase~partialprobed6/10

   Firebase ships a scriptable CLI (firebase-tools) that can deploy code, manage hosting, import/export auth data, and run a Local Emulator Suite for offline integration testing/QA and mocha-based unit tests — all of which are usable in a headless/CI context (firebase-docs-8, firebase-docs-9, firebase-docs-24, firebase-docs-31, firebase-gh-1/2/3). However, there is no explicit CI/CD pipeline documentation (e.g., GitHub Actions integration, service-account auth for non-interactive CLI use) or independent confirmation of CI usage. Missing for 10: explicit CI/CD integration docs (e.g., GitHub Actions workflow), non-interactive auth guidance for automated environments, and independent/hands-on evidence of running the emulator suite or CLI in a CI pipeline.

   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “This means you can connect your app directly to these emulators to perform integration testing or QA without touching production data.”
   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [claimed-docs] “Unit Tests: using the Firebase Test SDK, you can write unit tests in Node.js using the mocha test runner.”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site”
   • [github] “Import/Export users into/from Firebase Auth”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”

   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 userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Firebase—none0/10

   Evidence only shows Firebase publishing its own MCP server for external AI tools (Claude, Cursor, VS Code Copilot, etc.) to consume — the opposite direction from this story, which asks whether Firebase itself (e.g., via Gemini in Firebase) can act as an MCP client and consume external MCP servers' tools. No evidence indicates Firebase's Gemini assistant or console supports plugging in external MCP servers. Missing for 10: any documentation of Firebase acting as an MCP client, any way to register external MCP servers within Firebase's own AI features.

   • [claimed-docs] “The Firebase MCP server works with any tool that can act as an MCP client, including: Antigravity, Claude Code and Claude Desktop, Cline, Cu…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”

   proof ↗⚑ flag

   Appwrite—none0/10

   The evidence only shows Appwrite exposing its own MCP server so external AI agents (Claude Code, Cursor, etc.) can call Appwrite's API — the opposite direction from the story, which asks whether Appwrite itself can plug in and consume other MCP servers' tools. No documentation or CLI feature describes Appwrite acting as an MCP client or importing external MCP tool servers.

   • [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 userConnect an agent via an official MCP server

   weight 3 · round to Firebase
   Firebase✓fullprobed9/10

   Firebase ships an official documented MCP server that works with any MCP client tool (Antigravity, Claude Code/Desktop, Cline, Cursor, VS Code Copilot, Windsurf, etc.), enabling agents to manage Firebase projects, Auth, Firestore, and more. This is corroborated by both docs and a dedicated probe confirming the official page. Missing for 10: independent hands-on community report validating the MCP server's real-world reliability.

   • [claimed-docs] “The Firebase MCP server works with any tool that can act as an MCP client, including: Antigravity, Claude Code and Claude Desktop, Cline, Cu…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [probe] “official MCP server documented at https://firebase.google.com/docs/ai-assistance/mcp-server?hl=en”

   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

5. ai-native userUse an official CLI

   weight 2 · round drawn
   Firebase✓fullprobed8/10

   Firebase ships an official CLI (firebase-tools) documented both in GitHub and Firebase docs, covering deploy, hosting, auth, and Firestore data management, and is corroborated by a dedicated CLI docs page (firebase-probe-4). This CLI is the standard tool for automating Firebase workflows, which AI-native/agentic users would drive programmatically or via the complementary MCP server for AI agents. missing for 10: explicit documentation of AI-native features built into the CLI itself (e.g., natural-language command generation) beyond its use as an MCP-server backend.

   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site”
   • [github] “Import/Export users into/from Firebase Auth”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”
   • [claimed-docs] “The Firebase MCP server works with any tool that can act as an MCP client, including: Antigravity, Claude Code and Claude Desktop, Cline, Cu…”

   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

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

   weight 3 · round drawn
   Firebase✓fullprobed8/10

   Firebase exposes a well-documented public surface for programmatic/agentic use: the official CLI (firebase-tools) for deploying, managing data, and auth; Admin/REST SDKs for Firestore, Auth, and Functions; and a dedicated first-party MCP server that lets AI agents (Claude, Cursor, VS Code Copilot, etc.) manage Firebase projects, auth, and Firestore data directly. missing for 10: a discoverable machine-readable spec (openapi.json/llms.txt both 404), and independent hands-on confirmation of the MCP server working reliably in production agent workflows

   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [claimed-docs] “The Firebase MCP server works with any tool that can act as an MCP client, including: Antigravity, Claude Code and Claude Desktop, Cline, Cu…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [probe] “official MCP server documented at https://firebase.google.com/docs/ai-assistance/mcp-server?hl=en”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”

   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

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

   weight 2 · round to Appwrite
   Firebase—none0/10

   Firebase has Security Rules and Identity Platform for general access control, but no evidence describes issuing scoped or least-privilege API credentials specifically for an AI agent (e.g., a restricted service-account/API-key flow tied to MCP or agent use). The MCP server docs only describe what an agent-connected editor can do, not how to scope its permissions. missing for 10: documentation of agent-specific scoped credentials/service accounts, least-privilege API key issuance workflow, any first-party or community confirmation of this capability.

   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [claimed-docs] “Firebase Security Rules leverage extensible, flexible configuration languages to define what data your users can access for Realtime Databas…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”

   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

8. ai-native userBuild against official SDKs

   weight 2 · round to Firebase
   Firebase✓fullprobed8/10

   Firebase provides official SDKs across Firestore, Auth, Functions, Storage, and Rules, well documented with first-party docs and CLI (firebase-tools), plus emulator suite for local dev and testing. Community evidence corroborates real-world usage of these SDKs for building apps. missing for 10: independent hands-on validation specifically of SDK quality/versioning for AI-native workflows, and no explicit llms.txt/openapi spec found (probe results show 404s) which would strengthen AI-native discoverability.

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “FirebaseUI provides a drop-in auth solution that handles the UI flows for signing in users with email addresses and passwords, phone numbers…”
   • [claimed-docs] “The Firebase Authentication SDK provides methods that allow users to sign in with their Google, Facebook, Twitter, and GitHub accounts.”
   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”
   • [community] “I'm a big fan of firebase and use it whenever I can. The reason it's appealing is the suite of tools and how well they work together for boo…”

   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

9. ai-native userSubscribe to events via webhooks

   weight 2 · round to Appwrite
   Firebase—none0/10

   Firebase evidence shows event-driven Cloud Functions triggers and real-time listeners (Firestore/RTDB), but no documented webhook subscription mechanism for external endpoints to receive events; no first-party or community evidence of a webhooks feature.

   ⚑ 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 Firebase
   Firebase~partialclaimed6/10

   Firebase documents Gemini in Firebase providing AI-generated insights and suggestions from app data — e.g., actionable crash root-cause analysis and fix suggestions (Crashlytics) and summarization/recommendations for messaging campaign performance — directly matching the story's intent. However, this is scoped to specific data types (crash reports, messaging analytics) rather than general insights across all stored data (e.g., Firestore documents), and no independent/hands-on evidence corroborates the quality of these AI suggestions. Missing for 10: broader data-insight coverage (e.g., Firestore/database content analysis), independent user validation of insight quality.

   • [claimed-docs] “AI assistance provides actionable insights into your app's crashes, including a full description of the issue, information about possible ro…”
   • [claimed-docs] “Gemini in Firebase can summarize and analyze your messaging campaigns, providing actionable recommendations to improve performance.”
   • [claimed-docs] “If you use Crashlytics and enable Gemini in Firebase, you can get AI assistance for debugging and troubleshooting issues in your Apple and A…”
   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”

   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 Firebase
   Firebase✓fullclaimed8/10

   Firebase Cloud Functions explicitly support autonomous, event-driven background execution, including triggers from Firebase/Cloud events, HTTPS requests, and Cloud Scheduler jobs, letting users run scheduled or event-triggered automations without manual intervention. Docs also show one-command deployment and auto-scaling for these functions. Missing for 10: independent/hands-on corroboration of scheduler reliability and any dispute resolution for the older community complaint about lacking scheduled tasks (which predates Cloud Scheduler support).

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “The functions you write can respond to events generated by various Firebase and Google Cloud features, from Firebase Authentication triggers…”

   proof ↗⚑ 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 to Firebase
   Firebase✓fullclaimed8/10

   Firebase ships Gemini in Firebase, a built-in natural-language AI assistant embedded in the console that answers product questions, generates code, and provides crash/debugging insights and messaging analytics — directly fulfilling task delegation to a built-in AI assistant. missing for 10: independent/hands-on verification of Gemini in Firebase's task-execution quality beyond first-party docs, and clearer detail on the scope of tasks it can autonomously complete versus just advise on.

   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”
   • [claimed-docs] “AI assistance provides actionable insights into your app's crashes, including a full description of the issue, information about possible ro…”
   • [claimed-docs] “Gemini in Firebase can summarize and analyze your messaging campaigns, providing actionable recommendations to improve performance.”
   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”
   • [claimed-docs] “If you use Crashlytics and enable Gemini in Firebase, you can get AI assistance for debugging and troubleshooting issues in your Apple and A…”

   proof ↗⚑ 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
   Firebase✓fullprobed8/10

   Firebase documents both a natural-language chat interface (Gemini in Firebase) for getting answers, generating code, and troubleshooting, and an official MCP server that lets AI editors/agents create and manage Firebase projects, Auth users, and Firestore data via natural-language commands routed through MCP clients like Claude Code, Cursor, VS Code Copilot, etc. Missing for 10: independent/hands-on validation that MCP-driven natural-language operations reliably perform complex actions, and confirmation Gemini in Firebase supports action-taking beyond Q&A/insights.

   • [claimed-docs] “The Firebase MCP server works with any tool that can act as an MCP client, including: Antigravity, Claude Code and Claude Desktop, Cline, Cu…”
   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [probe] “official MCP server documented at https://firebase.google.com/docs/ai-assistance/mcp-server?hl=en”

   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 drawn
   Firebase—none0/10

   No evidence of an interactive API reference with runnable examples; probes confirm llms.txt and openapi endpoints return 404, and docs pack contains no mention of a live/interactive reference or embedded runnable code samples.

   • [probe] “PROBE llms.txt: HTTP 404 at https://firebase.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://firebase.google.com/openapi.json, https://firebase.google.com/swagger.json, https://firebase…”

   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 drawn
   Firebase—none0/10

   Probes for llms.txt and common OpenAPI/swagger spec paths all returned 404, and no documentation in the evidence pack references a downloadable OpenAPI/Swagger spec for Firebase APIs.

   • [probe] “PROBE llms.txt: HTTP 404 at https://firebase.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://firebase.google.com/openapi.json, https://firebase.google.com/swagger.json, https://firebase…”

   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 Firebase
   Firebase✓fullclaimed8/10

   Firebase's Local Emulator Suite explicitly lets developers connect apps to emulators for integration testing or QA 'without touching production data,' covering Firestore, Auth, Functions, Storage, Hosting, and more, with unit test support via mocha. missing for 10: independent/hands-on corroboration of emulator fidelity and AI-native/agent-specific usage examples beyond generic dev testing.

   • [claimed-docs] “This means you can connect your app directly to these emulators to perform integration testing or QA without touching production data.”
   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [claimed-docs] “Unit Tests: using the Firebase Test SDK, you can write unit tests in Node.js using the mocha test runner.”

   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
   Firebase—none0/10

   No evidence pack item documents API versioning schemes or a deprecation policy for Firebase's APIs/SDKs; probes for openapi.json/llms.txt both 404, and no docs reference version support windows or deprecation timelines.

   • [probe] “PROBE llms.txt: HTTP 404 at https://firebase.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://firebase.google.com/openapi.json, https://firebase.google.com/swagger.json, https://firebase…”

   proof ↗⚑ 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 Firebase
   Firebase✓fullclaimed8/10

   Firebase ships Gemini in Firebase, a natural-language chat interface in the dashboard that answers product questions, generates code, and provides AI-driven crash/debugging insights, directly matching the story of asking an AI assistant to write queries, debug, and explain the backend. missing for 10: independent hands-on user reports validating query-writing/debugging accuracy in Gemini in Firebase specifically (only vendor docs cited).

   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”
   • [claimed-docs] “AI assistance provides actionable insights into your app's crashes, including a full description of the issue, information about possible ro…”
   • [claimed-docs] “Get instant answers to questions about Firebase products and features, generate code for faster development, and shorten your troubleshootin…”
   • [claimed-docs] “If you use Crashlytics and enable Gemini in Firebase, you can get AI assistance for debugging and troubleshooting issues in your Apple and A…”

   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 Firebase
   Firebase✓fullclaimed8/10

   Firebase documents dedicated Cloud Firestore vector search functionality with KNN vector search, including storing vector values and creating/managing KNN vector indexes, directly matching the story. Missing for 10: independent/hands-on developer corroboration of vector search in production and details on scale/performance limits.

   • [claimed-docs] “This page shows you how to use Cloud Firestore to perform K-nearest neighbor (KNN) vector searches”
   • [claimed-docs] “This page shows you how to use Cloud Firestore to perform K-nearest neighbor (KNN) vector searches using the following techniques”
   • [claimed-docs] “This page shows you how to use Cloud Firestore to perform K-nearest neighbor (KNN) vector searches using the following techniques: Store vec…”

   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
   Firebase✓fullcommunity8/10

   Firebase Authentication SDK explicitly supports email/password plus Google, Facebook, Twitter, and GitHub OAuth sign-in, and FirebaseUI offers a drop-in solution handling these sign-in flows out of the box, matching the 'minutes' setup claim; community feedback also corroborates Firebase's ease of bootstrapping auth alongside other services. missing for 10: independent hands-on account of specifically timing/adding OAuth sign-in setup, and no mention of other providers like Apple/Microsoft.

   • [claimed-docs] “FirebaseUI provides a drop-in auth solution that handles the UI flows for signing in users with email addresses and passwords, phone numbers…”
   • [claimed-docs] “The Firebase Authentication SDK provides methods that allow users to sign in with their Google, Facebook, Twitter, and GitHub accounts.”
   • [claimed-docs] “FirebaseUI provides a drop-in auth solution that handles the UI flows for signing in users with email addresses and passwords, phone numbers…”
   • [community] “I'm a big fan of firebase and use it whenever I can. The reason it's appealing is the suite of tools and how well they work together for boo…”
   • [community] “One of the things I find quite nice about firebase is the powerful separation between data retrieval/update logic and the enforcement of acc…”

   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 Firebase
   Firebase~partialclaimed6/10

   Firebase's own docs state that native Firebase Authentication does not include MFA or enterprise SSO by default — these require upgrading to 'Firebase Authentication with Identity Platform,' which unlocks multi-factor authentication, SAML and generic OpenID Connect support, and enterprise-level support (firebase-docs-28). This confirms the capability exists but only via a paid upgrade path, not as a standard included feature — a significant caveat for a platform engineer evaluating baseline auth. Missing for 10: first-party documentation detailing MFA/SSO configuration steps, enforcement policies, and independent/hands-on validation of enterprise SSO setup.

   • [claimed-docs] “When you upgrade to Firebase Authentication with Identity Platform, you unlock additional features, such as multi-factor authentication, blo…”

   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 to Firebase
   Firebase~partialcommunity5/10

   Firebase provides some bulk-oriented capabilities—bulk import/export of Auth users via the CLI (firebase-gh-1, firebase-gh-3), multi-filter/sort queries in Firestore (firebase-docs-2), and MongoDB-compatible API access that could support bulk driver operations (firebase-docs-4/16/27)—but there's no direct documentation of a native batch-write/bulk-update API for arbitrary large-scale item operations, and community feedback notes limitations like lacking count queries without full downloads (firebase-comm-16). missing for 10: explicit batch-write/bulk-update API documentation, evidence of scale/performance for bulk operations, and independent hands-on confirmation of bulk data manipulation beyond auth import/export.

   • [claimed-docs] “Your queries can include multiple, chained filters and combine filtering and sorting.”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Import/Export users into/from Firebase Auth”
   • [claimed-docs] “Cloud Firestore offers a MongoDB-compatible API. You can use existing MongoDB application code, drivers, tools, and the open-source ecosyste…”
   • [community] “When will it support a count query? Now to be able to count number of children I have to download all the data. Count is such an important f…”

   proof ↗⚑ 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 Firebase
   Firebase✓fullclaimed8/10

   Firebase's Cloud Functions is explicitly a serverless event-trigger system: it runs backend code automatically in response to background events, HTTPS requests, Admin SDK, Auth triggers, Storage triggers, or Cloud Scheduler jobs, directly matching the 'rules that trigger actions on events' story. This is well documented across multiple first-party pages with concrete trigger types listed. Missing for 10: independent/hands-on corroboration of trigger reliability at scale, and clarification of any AI-native-specific tooling for defining these rules beyond standard docs.

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “The functions you write can respond to events generated by various Firebase and Google Cloud features, from Firebase Authentication triggers…”
   • [claimed-docs] “Cloud Functions now has experimental support for Dart. Flutter developers can now write both their frontend and backend in a single language…”
   • [claimed-docs] “Experimental: Cloud Functions now has experimental support for Dart. Flutter developers can now write both their frontend and backend in a s…”

   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
   Firebase~partialcommunity6/10

   Firebase docs confirm Cloud Functions can be triggered by Cloud Scheduler jobs, enabling recurring/scheduled workflows (firebase-docs-7, firebase-docs-29), but this relies on the external Cloud Scheduler service rather than a native, first-class 'scheduled job' primitive within Firebase itself, and there is only one high-level doc mention with no setup detail or independent validation of current experience. An older community comment even flagged the historical absence of scheduled-task support as a pain point, suggesting this capability was a later addition rather than a mature core feature. missing for 10: dedicated documentation/tutorial on defining a scheduled function end-to-end, independent/hands-on confirmation that scheduling works reliably today, and any AI-native/agent-specific workflow scheduling support.

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “The functions you write can respond to events generated by various Firebase and Google Cloud features, from Firebase Authentication triggers…”
   • [community] “I have built apps with firebase in the past and the feature I missed the most was performing scheduled tasks on the database... AWS Lambda w…”

   proof ↗⚑ 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 drawn
   Firebase—none0/10

   Firebase's evidence describes Cloud Functions, Security Rules, and CLI deployment, but nothing documents version history, review workflows, or rollback specifically for these 'automations' (functions/rules/triggers). Missing for 10: documented versioning/rollback of Cloud Functions or Security Rules, review/approval workflow, and any audit trail for automation changes.

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”

   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 drawn
   Firebase~partialclaimed4/10

   Firebase's Firestore Enterprise edition offers a MongoDB-compatible API, letting developers reuse existing MongoDB drivers/tools/ORM ecosystem, which partially satisfies 'standard clients and ORMs' — but this applies only to the Enterprise edition, not the default Firestore or Realtime Database, and no connection-string mechanism is documented anywhere in the evidence pack. Missing for 10: explicit connection-string documentation, ORM support for the standard (non-Enterprise) Firestore/Realtime DB products, and independent/hands-on confirmation that MongoDB drivers actually connect successfully.

   • [claimed-docs] “Cloud Firestore offers a MongoDB-compatible API. You can use existing MongoDB application code, drivers, tools, and the open-source ecosyste…”
   • [claimed-docs] “You can use existing MongoDB application code, drivers, tools, and the open-source ecosystem of MongoDB integrations with Cloud Firestore in…”
   • [claimed-docs] “Cloud Firestore offers a MongoDB-compatible API. You can use existing MongoDB application code, drivers, tools, and the open-source ecosyste…”

   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 drawn
   Firebase✓fullcommunity8/10

   Firebase offers managed NoSQL databases (Cloud Firestore, Realtime Database) with official client SDKs for web/mobile and Admin SDK for server-side access, backed by docs on data sync, offline caching, and security rules, plus CLI/GitHub tooling for data interaction; community hands-on reports confirm fast, real-time read/write from clients and servers. Missing for 10: independent benchmark on server SDK write/read latency, and community notes cite real limitations (query features, count queries, historical offline-persistence gaps) that keep it from a perfect score.

   • [claimed-docs] “Store and sync app data at global scale without managing servers.”
   • [claimed-docs] “Your queries can include multiple, chained filters and combine filtering and sorting.”
   • [claimed-docs] “Cloud Firestore caches data that your app is actively using, so the app can write, read, listen to, and query data even if the device is off…”
   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [claimed-docs] “Firebase Security Rules leverage extensible, flexible configuration languages to define what data your users can access for Realtime Databas…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [community] “We were one of the first hundred users to join Firebase (ID:68) and I remember how easy it was to add real time notifications to one of my p…”
   • [community] “We used the original Firebase database product to build socrates.io 3.5 years ago, and I remember getting it running in a few hours.”
   • [community] “I've had only good experiences with firebase. They added an HTTP api, web hosting, multiple security rule preprocessors (pain point), and go…”
   • [community] “How do the querying features compare to Firebase? Firebase is notorious for having an unintuitive lack of server-side query options when you…”
   • [community] “When will it support a count query? Now to be able to count number of children I have to download all the data. Count is such an important f…”
   • [community] “So, still no offline persistence for JS. What a huge disappointment.”

   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 Appwrite
   Firebase—none0/10

   Firebase's Firestore/Realtime Database are NoSQL document stores; evidence shows only chained filter/sort queries (firebase-docs-2) and a MongoDB-compatible API option (firebase-docs-4), with no mention of relational joins or multi-document transactions, and community evidence explicitly calls out the lack of server-side query capability (firebase-comm-4) and missing features like count queries (firebase-comm-16). No documentation of join support or transaction semantics appears in the pack.

   • [claimed-docs] “Your queries can include multiple, chained filters and combine filtering and sorting.”
   • [claimed-docs] “Cloud Firestore offers a MongoDB-compatible API. You can use existing MongoDB application code, drivers, tools, and the open-source ecosyste…”
   • [community] “How do the querying features compare to Firebase? Firebase is notorious for having an unintuitive lack of server-side query options when you…”
   • [community] “When will it support a count query? Now to be able to count number of children I have to download all the data. Count is such an important f…”

   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 to Firebase
   Firebase✓fullcommunity7/10

   Firestore docs explicitly describe local caching and offline write/read/sync capability that reconciles when connectivity returns, directly matching the story (firebase-docs-3). Confidence is tempered by an older community report claiming lack of JS offline persistence and by the absence of independent, recent hands-on corroboration of sync behavior. missing for 10: independent/hands-on confirmation of reconnect-sync behavior, and clarification on which SDKs currently support offline persistence.

   • [claimed-docs] “Cloud Firestore caches data that your app is actively using, so the app can write, read, listen to, and query data even if the device is off…”
   • [community] “So, still no offline persistence for JS. What a huge disappointment.”

   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 Appwrite
   Firebase~partialcommunity4/10

   Firebase's Realtime Database is built for syncing live data across connected clients, and community evidence describes real-time multi-client state sync (whiteboarding with synced positions, real-time notifications), which supports ephemeral broadcast use cases. However, the evidence pack never explicitly documents Firebase's presence-detection features (onDisconnect, .info/connected) which are the canonical mechanism for this story. Missing for 10: explicit docs on presence detection/onDisconnect API, independent verification of presence tracking specifically (not just generic realtime sync).

   • [claimed-docs] “Store and sync app data at global scale without managing servers.”
   • [community] “I built a real time whiteboarding app for teachers over 10 years ago on the backbone of the original Firebase service. It was so fast I was …”
   • [community] “We were one of the first hundred users to join Firebase (ID:68) and I remember how easy it was to add real time notifications to one of my p…”

   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 Firebase
   Firebase✓fullcommunity7/10

   Firebase's core value proposition includes real-time data sync — docs confirm apps can 'write, read, listen to, and query data' even offline, and multiple independent developers describe building live-updating apps (real-time whiteboard, real-time notifications, live sync across clients) confirming push-based updates rather than polling. missing for 10: explicit documentation of the onSnapshot/listener API surface and any first-party performance benchmarks for real-time delivery.

   • [claimed-docs] “Cloud Firestore caches data that your app is actively using, so the app can write, read, listen to, and query data even if the device is off…”
   • [community] “I built a real time whiteboarding app for teachers over 10 years ago on the backbone of the original Firebase service. It was so fast I was …”
   • [community] “We were one of the first hundred users to join Firebase (ID:68) and I remember how easy it was to add real time notifications to one of my p…”
   • [community] “We used the original Firebase database product to build socrates.io 3.5 years ago, and I remember getting it running in a few hours.”

   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
   Firebase—none0/10

   The evidence shows Cloud Firestore supports filtering/sorting queries and vector (KNN) similarity search for embeddings, but nothing indicates native full-text search over string fields; Firestore is well known for requiring an external service (e.g., Algolia/Elasticsearch) for text search, and community comments even complain about limited query capabilities. No documentation or hands-on evidence shows a built-in full-text search feature.

   • [claimed-docs] “Your queries can include multiple, chained filters and combine filtering and sorting.”
   • [claimed-docs] “This page shows you how to use Cloud Firestore to perform K-nearest neighbor (KNN) vector searches”
   • [claimed-docs] “This page shows you how to use Cloud Firestore to perform K-nearest neighbor (KNN) vector searches using the following techniques”
   • [claimed-docs] “This page shows you how to use Cloud Firestore to perform K-nearest neighbor (KNN) vector searches using the following techniques: Store vec…”
   • [community] “How do the querying features compare to Firebase? Firebase is notorious for having an unintuitive lack of server-side query options when you…”

   proof ↗⚑ 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 Firebase
   Firebase✓fullclaimed9/10

   Cloud Functions for Firebase is explicitly documented as a serverless framework that runs backend code automatically in response to background events, HTTPS requests, Admin SDK actions, or scheduler jobs, including Firebase Authentication triggers and Cloud Storage/Firestore triggers. This directly matches the story of running functions in response to database/auth events. missing for 10: independent hands-on report specifically confirming database/auth trigger reliability (community evidence focuses on other pain points, not this specific capability).

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “The functions you write can respond to events generated by various Firebase and Google Cloud features, from Firebase Authentication triggers…”

   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 to Firebase
   Firebase✓fullclaimed9/10

   Cloud Functions for Firebase is explicitly documented as a serverless framework to run backend code triggered by HTTPS requests, Admin SDK/client SDK calls, or background events, with one-command CLI deployment and automatic scaling. Missing for 10: independent hands-on corroboration of production-scale reliability of Functions specifically (community evidence mostly discusses Firestore/Auth/pricing rather than Functions usage).

   • [claimed-docs] “Cloud Functions for Firebase is a serverless framework that lets you automatically run backend code in response to events triggered by backg…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [claimed-docs] “The functions you write can respond to events generated by various Firebase and Google Cloud features, from Firebase Authentication triggers…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”

   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
   Firebase~partialprobed6/10

   Firebase CLI (firebase-tools) supports scripted, headless deployment of Firestore/Realtime Database security rules, Cloud Functions, and Auth user import/export, and the MCP server also exposes project/auth/data management to agents, covering schema+auth+policies largely from the command line. However, there's no single documented 'init a full backend' one-shot command evidenced, and evidence doesn't show a non-interactive schema-creation flow (Firestore is schemaless, so 'schema' setup maps to rules/indexes only). missing for 10: a documented fully non-interactive scripted bootstrap command chaining project creation, schema/indexes, auth, and rules; independent hands-on confirmation of headless end-to-end setup.

   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Import/Export users into/from Firebase Auth”
   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [claimed-docs] “Firebase Security Rules leverage extensible, flexible configuration languages to define what data your users can access for Realtime Databas…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”
   • [probe] “official MCP server documented at https://firebase.google.com/docs/ai-assistance/mcp-server?hl=en”

   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 Firebase
   Firebase✓fullprobed8/10

   Firebase's Local Emulator Suite explicitly supports running Firestore, Realtime Database, Storage, Auth, Hosting, Functions, Pub/Sub, and Extensions locally for integration testing without touching production, and the firebase-tools CLI supports running a local hosting server and interacting with data/deploying. This directly matches the story of running the whole backend stack locally before deploying, with unit-test support via mocha also documented. Missing for 10: independent/hands-on verification of full-suite parity beyond docs, and no community corroboration specifically praising the emulator suite's completeness.

   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [claimed-docs] “This means you can connect your app directly to these emulators to perform integration testing or QA without touching production data.”
   • [claimed-docs] “Unit Tests: using the Firebase Test SDK, you can write unit tests in Node.js using the mocha test runner.”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”

   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 drawn
   Firebase~partialprobed6/10

   Firebase ships extensive first-party APIs/SDKs (Firestore, Auth, Functions, Rules) plus a CLI (firebase-tools) that can deploy, manage hosting, interact with database data, and import/export Auth users, and an official MCP server that lets AI tools create/manage projects, manage Auth users, and work with Firestore data — strong evidence of broad API/CLI parity with console actions. However, there is no explicit documentation or independent confirmation that *every* console capability (e.g., analytics/Gemini insights, billing, project-level admin settings) is exposed via API/CLI, and probes show no OpenAPI spec or llms.txt is published, weakening claims of full programmatic parity. Missing for 10: explicit full-parity documentation, independent hands-on confirmation that all UI actions map to API/CLI, and a published OpenAPI/machine-readable spec.

   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site”
   • [github] “Import/Export users into/from Firebase Auth”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “Deploy your JavaScript, TypeScript, or Python code to our servers with one command from the command line. After that, Firebase automatically…”
   • [probe] “official MCP server documented at https://firebase.google.com/docs/ai-assistance/mcp-server?hl=en”
   • [probe] “official CLI documented at https://firebase.google.com/docs/cli?hl=en”
   • [probe] “PROBE llms.txt: HTTP 404 at https://firebase.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://firebase.google.com/openapi.json, https://firebase.google.com/swagger.json, https://firebase…”

   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
   Firebase!disputedcontradicted3/10

   Firebase CLI documents import/export of Auth users (open JSON) and one user notes deliberately keeping Firestore as a plain JSON store for portability, but there is no documented open-format export path for Firestore, Storage, or Security Rules, and multiple community accounts explicitly describe painful lock-in ('keenly aware of the cost of lock-in', 'need to reimplement storage rules — an absolute pain', 'the lock-in effect is super bad') when trying to migrate away. Missing for 10: comprehensive documented export of Firestore/Storage/Rules in open formats, first-party migration tooling, and independent confirmation that leaving is frictionless.

   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Import/Export users into/from Firebase Auth”
   • [community] “I use Firebase Database but keep it arms length by avoiding any of the proprietary features it offers. I use it exclusively as a JSON store …”
   • [community] “My app is currently built on top of Firebase but I'm keenly aware of the cost of lock-in as traffic escalates.”
   • [community] “Besides the pricing, the other painful thing about Firebase are the storage rules. If I switch serverless I need to reimplement them — an ab…”
   • [community] “After being both delighted and frustrated about Firebase I decided that something must be done. The developer experience on Firebase is awes…”

   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 to Appwrite
   Firebase~partialclaimed3/10

   Evidence shows firebase-tools (the CLI) is hosted on a public GitHub repo, implying it is open source, but the core Firebase backend/service (Firestore, Auth, Functions runtime) is proprietary and no license or full source is documented for the platform itself. missing for 10: explicit open-source license statement, source availability for the core backend/service, independent confirmation of license terms for firebase-tools.

   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site”
   • [github] “Import/Export users into/from Firebase Auth”

   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 to Appwrite
   Firebase—none0/10

   Firebase is a fully-managed, closed Google Cloud service with no self-hosted/on-premise deployment option documented anywhere in the evidence; the emulator suite is explicitly for local testing/QA, not production self-hosting, and community comments highlight lock-in concerns rather than any self-hosting path.

   • [claimed-docs] “This means you can connect your app directly to these emulators to perform integration testing or QA without touching production data.”
   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [community] “My app is currently built on top of Firebase but I'm keenly aware of the cost of lock-in as traffic escalates.”
   • [community] “After being both delighted and frustrated about Firebase I decided that something must be done. The developer experience on Firebase is awes…”

   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
   Firebase—none0/10

   No evidence in the pack mentions data residency, region selection, or location settings for Firebase services (Firestore, Storage, Functions, etc.), even though Firebase/GCP products do typically allow region selection in reality. Absence of evidence for this applicable capability yields 'none'.

   ⚑ 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 userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Firebase—none0/10

   No evidence pack item addresses AI-training data usage or opt-out policies for Firebase data; the docs cover storage, auth, functions, and AI-assistance features, but nothing about preventing data from being used to train AI models.

   ⚑ flag

   Appwrite—none0/10

   No evidence in the pack addresses AI-training data usage policies, opt-out mechanisms, or any explicit privacy commitment regarding model training; self-hosting gives data control but that's not the same as an explicit no-AI-training policy. As a backend platform, this axis is plausible (buyers could ask whether their hosted data is used for AI training), so absence of evidence yields 'none'.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Appwrite
   Firebase—none0/10

   The evidence pack covers Firestore querying, security rules, auth, functions, and emulators, but contains no documentation of data retention policies, TTL/expiration settings, or deletion/export APIs for privacy compliance (e.g., GDPR-style user data deletion). No citations address controlling how long data is kept or how it can be purged.

   ⚑ 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

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

   weight 2 · round drawn
   Firebase—none0/10

   No evidence pack items mention telemetry, usage tracking, or an opt-out mechanism for Firebase's own tooling/services; only unrelated docs on Firestore, Auth, Functions, and pricing are present.

   ⚑ 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 Firebase
   Firebase~partialprobed4/10

   Firebase's Local Emulator Suite lets developers (or an agent driving the CLI) test Firestore/Security Rules changes locally without touching production data, and the MCP server exposes Firestore project/data management to AI agents — together giving a rough isolated-testing story. However, Firestore is schemaless (no formal schema-migration concept) and there is no documented branch/preview-environment feature (e.g., a project 'branch' with automatic promotion) analogous to database branching tools. Missing for 10: explicit schema/migration versioning, a true branch/preview-environment workflow, and evidence of an agent autonomously provisioning/testing such a branch before production.

   • [claimed-docs] “This means you can connect your app directly to these emulators to perform integration testing or QA without touching production data.”
   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [claimed-docs] “An editor configured to use the Firebase MCP server can use its AI capabilities to help you: Create and manage Firebase projects, Manage you…”
   • [probe] “official MCP server documented at https://firebase.google.com/docs/ai-assistance/mcp-server?hl=en”

   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
   Firebase—none0/10

   Firebase's CLI can deploy static config like Firestore security rules and indexes, but there is no evidence of a schema-migration framework (versioned, incremental migrations with up/down scripts) applied via CLI/CI; in fact a community report explicitly notes the lack of a business-logic layer makes schema changes 'extremely challenging' for deployed clients, underscoring the absence of this capability.

   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [github] “Deploy code and assets to your Firebase projects - Run a local web server for your Firebase Hosting site - Interact with data in your Fireba…”
   • [community] “The concern I've always had with Firebase is the lack of a business logic layer between clients and the database. This tends to force the bu…”

   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 Appwrite
   Firebase—none0/10

   No evidence of Firebase generating typed client code/TypeScript types from a schema; docs cover Firestore, Auth, Functions, emulators, security rules, and MCP/Gemini AI features but nothing about automatic type generation from schema.

   ⚑ 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 Firebase
   Firebase✓fullcommunity8/10

   Firebase Security Rules are extensively documented as the mechanism to restrict data access per user across Firestore, Realtime Database, and Cloud Storage, with granular, expression-based rule languages, and community evidence corroborates real-world use (e.g., failed attempts blocked by rules, separation of auth logic from data access). missing for 10: no independent hands-on audit of rule robustness/edge cases, and community notes rules can be painful to maintain/reimplement, slightly denting polish.

   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [claimed-docs] “Firebase Security Rules leverage extensible, flexible configuration languages to define what data your users can access for Realtime Databas…”
   • [claimed-docs] “You can write simple or complex rules that protect your app's data to the level of granularity that your specific app requires.”
   • [community] “One of the things I find quite nice about firebase is the powerful separation between data retrieval/update logic and the enforcement of acc…”
   • [community] “"This includes failed attempts which are blocked by their security rules." Ouch!”
   • [community] “Besides the pricing, the other painful thing about Firebase are the storage rules. If I switch serverless I need to reimplement them — an ab…”

   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
   Firebase—none0/10

   No evidence in the pack mentions automated backups or point-in-time recovery for Firestore/Realtime Database; only security rules, querying, offline caching, and emulator suite are documented. This is a plausible axis for a database/backend platform, so absence of evidence yields 'none'.

   ⚑ 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 Appwrite
   Firebase~partialcommunity3/10

   Evidence only mentions 'Cloud Storage' in passing as one of the products covered by Firebase Security Rules and the Emulator Suite (firebase-docs-10, firebase-docs-18, firebase-docs-24), with community mentions of 'storage rules' as a pain point (firebase-comm-5, firebase-comm-8). There is no documentation in the pack describing file upload/download APIs, access-rule granularity for files, or CDN-backed delivery specifics. missing for 10: docs on Cloud Storage upload/download SDK, CDN delivery details, access-rule examples for file objects, independent corroboration of CDN performance.

   • [claimed-docs] “Use our flexible, extensible Firebase Security Rules to secure your data in Cloud Firestore, Firebase Realtime Database, and Cloud Storage.”
   • [claimed-docs] “Firebase Security Rules leverage extensible, flexible configuration languages to define what data your users can access for Realtime Databas…”
   • [claimed-docs] “The Firebase Local Emulator Suite is a set of advanced tools for developers looking to build and test apps locally using Cloud Firestore, Re…”
   • [community] “Besides the pricing, the other painful thing about Firebase are the storage rules. If I switch serverless I need to reimplement them — an ab…”
   • [community] “I'm a big fan of firebase and use it whenever I can. The reason it's appealing is the suite of tools and how well they work together for boo…”

   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
   Firebase—none0/10

   No evidence pack items mention Firebase Extensions for image resizing, Cloud Storage image transformation, or any built-in image pipeline capability; the pack covers Firestore, Auth, Functions, Rules, and MCP but nothing about serving resized/transformed images.

   ⚑ 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