# Best backend for apps built with AI coding agents: an honest roundup

floo, Supabase, Firebase, Appwrite, Convex, Neon and PocketBase, compared from their own docs: what each is good at, who should pick it, and where an agent most often gets security wrong on each.

Canonical URL: https://getfloo.com/blog/best-backend-for-apps-built-with-ai-coding-agents

## TL;DR

**Pick the backend by who opens the app and where your agent's code runs. For internal and personal software that a known group signs in to, floo hosts the app and its backend from one `floo.app.toml`, and the browser never holds a database key, so there are no row-level security policies for your agent to get wrong. For public apps with self-signup, realtime-heavy apps, or apps that need a global CDN, another option on this list is the better pick.**

- **Most backends trust the browser and guard the data with rules.** Supabase and Neon's Data API use row-level security, Firebase uses Security Rules, Appwrite uses table permissions, and PocketBase uses API rules. A table without a correct rule is the usual leak.
- **floo puts a server and a sign-in gateway in front of the data instead.** Access decisions live in ordinary code, not in policies an agent writes once and nobody reads.
- **floo is the wrong pick for strangers signing up.** Its app sign-in is invitation-only, and its docs describe no realtime subscriptions, CDN, or multi-region serving.
- **Each alternative has a real strength:** Supabase for Postgres with public auth and realtime, Firebase for mobile and offline sync, Convex for reactive TypeScript apps, Appwrite and PocketBase for self-hosting, Neon when you only want Postgres.

Every claim about another product below comes from that product's own docs, read on November 3, 2026. Sources are at the end. We left prices out, because they change faster than architectures do.

## Why does the backend choice matter more when an agent writes the code?

Because an agent writes access rules as fast as it writes tables, and nobody reads either. Agent-built apps leak through sign-in and permission mistakes. The mechanism is the same across most backends.

The browser holds a public key and talks to the database, or to an API generated from it. The only thing between a stranger and a table is the rule attached to that table. Supabase's docs say to enable row-level security on every table in an exposed schema, and that a table there without it can be read and written by any role with a grant. Tables created in Supabase's SQL editor, which is how migrations usually arrive, need RLS turned on by hand. Neon's Data API says it has no permission layer of its own: Postgres grants and RLS policies are the whole defense. Firebase's docs call Security Rules the safeguard against malicious users, because clients connect to Firestore directly.

None of this is a flaw in those products. It is the price of letting the browser reach the data. The question for an agent-built app is whether you want to pay it.

## What are the two shapes of backend?

| Shape | Who reaches the data | Where the guard lives | Examples |
| --- | --- | --- | --- |
| Browser to database | The browser, with a public key | A rule on every table, collection, or path | Supabase Data API, Firebase, Appwrite, PocketBase, Neon Data API |
| Server in between | Only your server code | Sign-in in front, checks in your code | floo, Convex functions, any app with its own API |

The second shape is not new. It is how web apps worked before backend-as-a-service. The difference now is that an agent can write the server, so the cost of having one has dropped to almost nothing, while the cost of a wrong table rule has not.

## How do the options compare?

| | Hosts your server code | Browser reaches data directly | Access rules live in | Self-signup | Scheduled jobs | Realtime | Self-host |
| --- | --- | --- | --- | --- | --- | --- | --- |
| floo | Yes, any app with a Dockerfile | No | Gateway sign-in plus your code | No, invitation-only | `[cron.<name>]` in config | WebSockets pass through; no subscriptions described | No |
| Supabase | Edge Functions, short-lived; app hosting not described in its docs | Yes, Data API | RLS policies | Yes, can be turned off | Supabase Cron | Yes | Yes, community-supported |
| Firebase | App Hosting runs Next.js and Angular | Yes, Firestore and Realtime Database | Security Rules | Yes, can be restricted | Scheduled functions | Yes | Not described in its docs |
| Appwrite | Sites (static and SSR), Functions | Yes, client SDK | Table and row permissions | Yes; invite-only not described | Function schedules | Yes | Yes |
| Convex | Convex functions only; frontend elsewhere | Through public functions | Checks in each function | Restriction not described | Cron jobs | Yes, reactive queries | Yes |
| Neon | Neon Functions; no website hosting | Yes, Data API | Grants and RLS | Restriction not described | Function cron triggers | Listed in its docs | Not covered here |
| PocketBase | One executable you run | Yes, its API | Collection API rules | Controlled by rules | `cronAdd` in hooks | Yes, over SSE | Self-hosted only |

## floo

**What it is.** floo hosts the whole app and its backend. Your agent writes `floo.app.toml` next to the code, and one push gives the app managed Postgres, invite-only team sign-in at floo's gateway, scoped API keys for agents, scheduled jobs, S3-compatible storage, and Redis. Dev and prod each get their own database and credentials.

```toml
[app]
name = "orders"
access_mode = "accounts"

[services.web]
type = "web"
path = "."
port = 3000
migrate_command = "node scripts/migrate.js"

[managed.default]
type = "postgres"

[cron.nightly-report]
schedule = "0 6 * * *"
command = "node scripts/report.js"
service = "web"
```

**How it handles the leak.** The browser gets no database key and no data API. Every request passes the gateway, which signs the person in and adds `X-Floo-User-Email`, `X-Floo-User-Role`, and two more identity headers before your code runs. Only your server holds `DATABASE_URL`. Deciding which rows a person may see is still your app's job, and floo's docs say so plainly, but that decision is a `WHERE` clause in code your agent can test, not a policy on a table it created three migrations ago.

**Who should pick it.** People building internal and personal software with an agent: a dashboard for the number the team argues about, an approval queue, a tool that replaces a spreadsheet. It also fits apps an agent calls, because each agent gets its own key, scoped to routes you declare and revocable without signing anyone out.

**Where it does not fit.**

- Strangers creating their own accounts. App sign-in admits only invited people; there is no self-signup, no admission by email domain, and no SAML or OIDC for app users yet.
- Realtime database subscriptions. WebSocket requests pass through the gateway, but floo's docs describe no change feeds or presence.
- A global CDN or multi-region serving, which floo's docs do not describe.
- Self-service database restore. Postgres keeps change history, and floo runs restores when you email a request. Redis has no backup.
- Cron that retries. A failed run waits for the next schedule.
- Apps without a Dockerfile, though `floo init` offers to write one, and `floo projects create` starts an app without a GitHub account.

## Supabase

**Good at:** Postgres with a generated REST API, public sign-up with many providers, SAML SSO on paid plans, realtime (Broadcast, Presence, and Postgres Changes), Supabase Cron for scheduled SQL, branching, and a self-hosting path. Its MCP server and agent skills are well documented.

**Watch for:** RLS on every exposed table, including the ones your agent creates in SQL. Supabase's own Security Advisor flags tables with RLS disabled and policies that are always true. Secret keys bypass RLS, so a secret key in the wrong place undoes all of it. Supabase's docs do not describe hosting your frontend; you deploy it elsewhere and set Supabase environment variables there.

**Pick it when** the app is public, people sign themselves up, or you want realtime and Postgres in one product. If you would rather avoid the browser path entirely, its docs describe turning the Data API off.

## Firebase

**Good at:** mobile and web apps that sync data to every client in milliseconds with offline support, a long list of sign-in providers, App Hosting that builds Next.js or Angular into containers on Cloud Run behind Cloud CDN, and scheduled functions. SQL Connect (formerly Data Connect) adds Postgres through server-stored queries that default to no access until you add an `@auth` directive.

**Watch for:** Security Rules. Firestore's test mode lets anyone read and overwrite data, and the docs warn that a rule that only checks a user is signed in is too broad. Restricting sign-up means disabling user actions in Authentication settings or writing a blocking function, which needs the Identity Platform upgrade.

**Pick it when** you are building a consumer or mobile app that needs offline sync and a CDN, and you will review the rules file like code.

## Appwrite

**Good at:** a broad, open-source backend you can self-host with Docker or Helm. Auth with more than 30 OAuth providers, passkeys, and MFA; databases, storage, functions with cron schedules, messaging, realtime, and Sites for static and SSR hosting. API keys are scoped per service, and its MCP server asks for confirmation before writes.

**Watch for:** permissions. A new table grants no one access, which is a safe default, but the quickest fix for a permission error is to grant a whole table to every signed-in user, and an agent reaches for quick fixes. Row-level permissions apply only when row security is turned on. An invite-only switch is not described in its docs; the closest control is a user limit.

**Pick it when** you want an open-source backend you can run yourself, or broad auth options on a public app.

## Convex

**Good at:** reactive apps in TypeScript. Queries update every subscribed client from the same snapshot, scheduled functions and cron jobs are built in, and its AI docs, rules file, and MCP server are some of the most thorough on this list. Its docs describe reads and writes only through query and mutation functions, which is close to floo's server-in-between shape.

**Watch for:** every public function is callable by any client, so each one must check who is calling. Convex Auth is labeled beta, and its Next.js support experimental; Clerk, WorkOS, Auth0, and OIDC providers are the alternatives. Convex runs Convex functions, not arbitrary servers, and its docs send frontends to Vercel, Netlify, or a static host. Restricting sign-up is not described in its docs.

**Pick it when** the app is realtime at its core, such as a shared board, chat, or a multiplayer tool, and you are happy writing everything in TypeScript.

## Neon with Neon Auth

**Good at:** serverless Postgres with instant branches, scale to zero, and point-in-time restore. Neon Auth, built on Better Auth, stores users and sessions in your own database, and the Neon MCP server can manage branches, auth, and the Data API.

**Watch for:** the Data API is authorized only by grants and RLS, and enabling it grants the `authenticated` role access to the `public` schema. Neon Functions, its docs say, are backend primitives rather than app hosting, so the frontend goes elsewhere. Restricting sign-up is not described in its docs.

**Pick it when** you only want Postgres, already have a host, and want branching for every pull request.

## PocketBase

**Good at:** one executable with SQLite, auth, file storage, realtime over server-sent events, an admin dashboard, and cron jobs in Go or JavaScript hooks. Easy to run on a single server you own.

**Watch for:** API rules. A locked rule, the default, means superuser only, but an empty rule means anyone, including guests. An agent that "fixes" a permission error by clearing a rule opens the collection. PocketBase's docs say it is self-hosted only, scales on one server, is not yet at version 1.0, and is not recommended for production-critical apps.

**Pick it when** it is a personal project on hardware you control and SQLite is enough.

## How should you choose?

1. **Who opens it?** A known group: floo, or any option where you add your own invite logic. Anyone who wants an account: Supabase, Firebase, Appwrite, or Convex.
2. **Does the browser need live updates from the database?** Yes: Convex, Firebase, or Supabase.
3. **Will an agent use the app too?** floo gives each agent a key scoped to declared routes. Elsewhere you design that yourself, often around a secret key that bypasses every rule.
4. **Who will read the access rules?** If the honest answer is nobody, choose a shape where the browser never reaches the data.

If floo fits, the fastest path is a [template](https://getfloo.com/templates) or the [backend overview](https://getfloo.com/backend). For an app you already have, [here is how to add a backend to it](https://getfloo.com/blog/how-to-add-a-backend-to-an-app-your-agent-built), and [here is the checklist to run before you share it](https://getfloo.com/blog/backend-checklist-before-you-share-an-ai-built-app). If RLS is the part you are unsure about, read [Do I need row-level security?](https://getfloo.com/blog/do-i-need-row-level-security).

## Sources

- floo: [app sign-in](https://getfloo.com/docs/guides/app-auth), [app API keys](https://getfloo.com/docs/guides/app-api-keys), [Postgres](https://getfloo.com/docs/guides/postgres), [managed services](https://getfloo.com/docs/guides/managed-services), [cron jobs](https://getfloo.com/docs/guides/cron-jobs), [backups](https://getfloo.com/docs/guides/backups), [networking](https://getfloo.com/docs/guides/networking), [quickstart](https://getfloo.com/docs/introduction)
- Supabase: [row-level security](https://supabase.com/docs/guides/database/postgres/row-level-security), [securing your API](https://supabase.com/docs/guides/api/securing-your-api), [API keys](https://supabase.com/docs/guides/api/api-keys), [database advisors](https://supabase.com/docs/guides/database/database-advisors), [hardening the Data API](https://supabase.com/docs/guides/database/hardening-data-api), [auth](https://supabase.com/docs/guides/auth), [Cron](https://supabase.com/docs/guides/cron), [Realtime authorization](https://supabase.com/docs/guides/realtime/authorization), [Edge Functions](https://supabase.com/docs/guides/functions), [deployment](https://supabase.com/docs/guides/deployment), [self-hosting](https://supabase.com/docs/guides/self-hosting), [AI tools](https://supabase.com/docs/guides/ai-tools)
- Firebase: [Security Rules basics](https://firebase.google.com/docs/rules/basics), [insecure rules](https://firebase.google.com/docs/firestore/security/insecure-rules), [Realtime Database](https://firebase.google.com/docs/database), [Authentication](https://firebase.google.com/docs/auth), [manage users](https://firebase.google.com/docs/auth/users), [blocking functions](https://firebase.google.com/docs/auth/extend-with-blocking-functions), [App Hosting](https://firebase.google.com/docs/app-hosting), [scheduled functions](https://firebase.google.com/docs/functions/schedule-functions), [SQL Connect](https://firebase.google.com/docs/sql-connect), [SQL Connect security](https://firebase.google.com/docs/sql-connect/authorization-and-security)
- Appwrite: [Auth](https://appwrite.io/docs/products/auth), [database permissions](https://appwrite.io/docs/products/databases/permissions), [platform permissions](https://appwrite.io/docs/advanced/platform/permissions), [API keys](https://appwrite.io/docs/advanced/security/api-keys), [Functions](https://appwrite.io/docs/products/functions/execute), [Sites](https://appwrite.io/docs/products/sites), [project policies](https://appwrite.io/docs/partners/project/policies), [MCP](https://appwrite.io/docs/tooling/mcp), [self-hosting](https://appwrite.io/docs/advanced/self-hosting)
- Convex: [database](https://docs.convex.dev/database/overview), [auth](https://docs.convex.dev/auth/overview), [Convex Auth](https://docs.convex.dev/auth/convex-auth), [internal functions](https://docs.convex.dev/functions/internal-functions), [realtime](https://docs.convex.dev/realtime), [scheduling](https://docs.convex.dev/scheduling/overview), [hosting](https://docs.convex.dev/production/hosting), [AI](https://docs.convex.dev/ai/overview), [self-hosting](https://docs.convex.dev/self-hosting)
- Neon: [Neon Auth](https://neon.com/docs/auth/overview), [Data API](https://neon.com/docs/data-api/get-started), [Data API access control](https://neon.com/docs/data-api/access-control), [branching](https://neon.com/docs/introduction/branching), [instant restore](https://neon.com/docs/postgres/backup-restore/branch-restore), [Functions](https://neon.com/docs/compute/functions/overview), [MCP server](https://neon.com/docs/ai/neon-mcp-server)
- PocketBase: [introduction](https://pocketbase.io/docs/), [API rules](https://pocketbase.io/docs/api-rules-and-filters/), [FAQ](https://pocketbase.io/faq/), [going to production](https://pocketbase.io/docs/going-to-production/), [jobs scheduling](https://pocketbase.io/docs/js-jobs-scheduling/)

## FAQ

### What is the best backend for an app built with a coding agent?

It depends on who opens the app. For internal or personal software that a known group signs in to, floo hosts the app and its backend together: Postgres, invite-only sign-in, agent API keys, cron, storage and Redis from one floo.app.toml. For a public app where strangers create accounts, or one built around realtime sync, Supabase, Firebase, Convex or Appwrite fit better.

### Why do agent-built apps leak data?

Most backends let the browser query the database with a public key and rely on access rules on every table: row-level security on Supabase and Neon's Data API, Security Rules on Firebase, permissions on Appwrite, API rules on PocketBase. One missing or overly broad rule on a table the agent added exposes that table.

### Does floo need row-level security policies?

No. floo gives the browser no database key and no data API. Requests pass floo's gateway, which signs people in, and only your server code holds DATABASE_URL. Which rows a person may see is decided in that server code, where your agent can test it and you can review it.

### When is floo the wrong choice?

When strangers need to create their own accounts, because floo's app sign-in is invitation-only. Also when the app depends on realtime database subscriptions, a global CDN, or multi-region serving, none of which floo's docs describe.

### Can I self-host any of these?

Supabase, Appwrite, Convex and PocketBase document self-hosting. PocketBase is self-hosted only. floo is a hosted platform.