tl;dr
Choose Neon when branchable serverless Postgres and its expanding backend primitives are the center of the architecture. Choose floo when the software factory needs one cloud for application services, managed state, production-shaped previews, runtime evidence, and human control.
- Neon is moving beyond Postgres. Auth and Data API are available, while object storage, compute, and an AI gateway are part of its announced backend direction.
- Neon is explicitly agent-oriented. It provides MCP, Agent Skills, an Agent Plan, database branching, and infrastructure-as-code through
neon.ts. - Neon does not currently claim to replace the whole application cloud. Its own platform direction still expects teams to use frontend hosting and other external services.
- floo owns the broader running-system boundary. The application, environment, services, routes, state, diagnostics, and gates share one production model.
- The products can complement one another. Neon can provide an external branchable backend for an application deployed on floo.
Neon is no longer positioning itself as serverless Postgres with a branching feature. It is building a backend stack for applications and agents.
Today that stack includes serverless Postgres, branches, Auth, Data API, MCP, Agent Skills, and an Agent Plan for platforms that provision databases at scale. Neon has announced object storage, compute, and an AI gateway as additional primitives. It has also introduced neon.ts, a typed infrastructure-as-code runtime for project and branch configuration.
Neon's own description is useful: it is building the “boring backend for apps and agents.” The announcement also says Neon is not trying to replace frontend hosting.
That makes the comparison with floo clearer. Neon is expanding the backend. floo is organizing the complete application production loop.
Neon starts from branchable state
Neon's core architectural advantage is a database that can branch quickly, scale to zero, restore, and provide isolated credentials. Branches support development, previews, migrations, and platforms that create databases on behalf of users.
Neon Auth stores user profiles in Postgres, so auth state can follow a database branch. Its Vercel integration can provision Auth URLs for preview branches automatically. Data API exposes branch data over HTTP with optional authentication.
For agents, Neon's MCP server can create projects and branches, run queries, make schema changes, perform migrations, provision Auth, and provision Data API access. Neon documents those capabilities in its MCP server overview.
This is a coherent agent-facing backend model. The database branch is the unit around which state, Auth, API access, and schema work can align.
floo starts from the application environment
floo's unit is the running application environment. A branch can produce services, routes, migration jobs, workers, cron, policy, logs, diagnostics, and preview-owned managed state.
The distinction matters when a proposed change crosses more than the database. An agent may change a frontend, API, worker, queue contract, route, migration, and access rule together. A database branch isolates one critical component. A production-shaped preview gives the whole proposed system an owner.
floo-managed Postgres uses preview-owned schema and role isolation today. Redis and storage also receive preview-owned resources. The preview lifecycle records ownership, supports targeted reset, and removes tracked resources without touching development or production.
neon.ts and repository authority
neon.ts moves Neon closer to the same category argument as floo: agents need infrastructure they can declare, review, and reproduce from the repository. Neon describes it as a branch configuration and infrastructure-as-code file for full-stack projects, with support today for Data API and Auth. Neon introduced it as the configuration runtime for its expanding backend primitives.
floo applies repository authority to the broader application shape: services, routes, access policy, resources, cron, edge policy, preview posture, and managed attachments.
Both products are responding to the same pressure. Agents work better when desired state is explicit and reviewable. The difference is the scope of the desired state each platform owns.
compare the factory loop
| requirement | Neon | floo |
|---|---|---|
| Primary unit | Project, database, and branch | Application and environment |
| Current managed core | Serverless Postgres, Auth, Data API | Services plus Postgres, Redis, and storage |
| Agent interface | MCP, Agent Skills, CLI, API | Structured CLI/API, routed docs, preview and deploy operations |
| Preview isolation | Database and branch-linked backend state | Application topology plus preview-owned managed resources |
| Infrastructure as code | neon.ts for Neon project primitives | Repository-authoritative application configuration |
| Runtime operations | Database/backend logs and management | Service logs, deploy diagnostics, routing, rollback, preview reset and cleanup |
| Human boundary | Tool/client approval and account controls | Consequence-based approval in the deployment lifecycle |
Neon's announced compute and storage direction will narrow parts of this difference. Those capabilities should be evaluated when they ship, not treated as current production facts.
embedded platform versus application cloud
Neon's Agent Plan targets platforms such as app builders that provision large numbers of databases for their users. That is a different role from hosting each finished application's complete service topology.
Neon can sit underneath another platform. A builder provisions a branch, injects a connection string, and lets its user or agent create the application elsewhere. The backend can scale independently of the runtime.
floo aims to be the cloud on which the finished application runs. Its product includes the loop after provisioning: deployment, preview, logs, diagnostics, routing, rollback, state ownership, cleanup, and human review.
This is also why a floo and Neon combination can make sense. Neon supplies specialized branchable Postgres. floo supplies the application runtime and production loop. The cost is an external-state boundary the team must make explicit.
verdict
Choose Neon when branchable Postgres, Auth, Data API, embedded provisioning, or its expanding backend roadmap is the strategic center of the product. It is one of the clearest agent-native infrastructure companies in the market.
Choose floo when the team wants agents to operate the complete application under one production model. floo's claim is broader: repository intent becomes a running system, runtime evidence returns to the agent, and humans retain control over consequential transitions.
Neon is building the branchable backend for apps and agents. floo is building the cloud for the human-agent software team around the whole application. A software factory may use either, or both. The right choice depends on which boundary the team needs one platform to own.