Supabase or Cloudflare? Infrastructure decisions for small products
Supabase buys speed; Cloudflare can reduce the operational surface when your product already lives at the edge. Neither fixes a weak architecture. Start with the product's risk, data model and actual traffic.
When infrastructure cost becomes visible, switching platforms is tempting. I felt the same pressure when Ordovia's backend traffic grew and Supabase spend stopped being invisible.
The deeper lesson was that backend choice is not a pricing-table decision. It also selects your auth model, data relationships, deployment surface, debugging workflow and migration burden.
The useful question is not “Supabase or Cloudflare?” It is “what complexity does this product actually need today?”
They are not the same category of product
Supabase is an opinionated backend platform built around PostgreSQL, auth, storage, realtime and APIs. Cloudflare is a set of composable primitives such as Workers, D1, R2, KV, Queues and Pages. The choice is closer to managed backend platform versus edge-oriented composition.
Why Supabase is powerful early
For an independent builder, attention is usually more expensive than servers. If auth, relational data, RLS and storage are not the differentiating part of your product, having them available immediately can be excellent product economics.
const earlyStagePriority = [ "problem validation", "usable product", "real feedback", "then infrastructure perfection",];Why Cloudflare becomes attractive
When deployment, domains, edge APIs and storage already live on Cloudflare, Workers, R2 and sometimes D1 can reduce the number of operational surfaces. That is more interesting to me than a simple unit-price comparison.
Do not migrate because a bill annoyed you
Ordovia reached roughly 2.6 million monthly Supabase requests before I examined alternatives more seriously. Some of that pressure came from application behavior: polling, repeated fetches, weak cache policies and broad invalidation. Moving those patterns to another vendor would not repair them.
const migrationDecision = { badReason: "current bill feels annoying", betterReasons: [ "architecture fits the new platform better", "operations become simpler", "measured savings matter", "migration risk is acceptable", ],};Relational complexity matters
When a product has deeply connected domains, PostgreSQL is not a minor implementation detail. Transactions, foreign keys, views, functions and rich querying can be part of the product model itself. Forcing a mature relational product into a different model to save money can create more complexity than it removes.
Auth can be more expensive to move than data
A migration is rarely just tables. If your product relies on Supabase Auth, refresh tokens, RLS and user-scoped access, identity logic may be spread across the entire system. That makes auth migration a product-risk decision, not merely a database task.
type MigrationSurface = | "data" | "auth" | "storage" | "api" | "background_jobs" | "observability" | "deployment";My four-step framework
- Find the product's main risk: adoption, relational complexity, traffic or something else.
- Validate with the smallest operational burden possible.
- Measure real usage before optimizing infrastructure.
- Treat migration as an economic project with engineering and risk costs.
A simple decision matrix
| Situation | My bias |
|---|---|
| Fast MVP + auth + relational data | Supabase |
| Rich relational model + RLS | Supabase |
| Edge API + R2 + simple data | Evaluate Cloudflare |
| Small tool already on Cloudflare | Cloudflare is a strong candidate |
| Bill simply increased | Measure and fix architecture first |
| Large migration, tiny savings | Do not move |
Infrastructure work can become productive procrastination
New infrastructure is satisfying because it is concrete. Product uncertainty is not. It is easy to spend a week moving databases while avoiding the harder question of whether the product creates enough value.
Running an unwanted product 40% cheaper is not a win.
Conclusion
I use Supabase when it buys product speed and strong relational primitives. I evaluate Cloudflare when the product can genuinely become simpler by living closer to an existing edge stack. The decision changes with product stage, data model, traffic and migration cost.
function chooseInfrastructure(product: Product) { return optimizeFor([ product.validationSpeed, product.dataModel, product.operationalSimplicity, product.measuredCost, product.migrationRisk, ]);}SaaS Systems: Architecture, Cost and Simplicity
Field notes and decision frameworks connecting backend cost, cloud choices and product complexity as one systems problem.