This isn’t about Supabase vs Convex as products.
It’s about how credibility breaks in devtools — and why engineers react so strongly when it does.
Over the past few days, a third‑party blog post comparing Supabase and Convex triggered an unusually intense backlash across the developer community.
What followed wasn’t just social‑media noise:
- founders publicly calling out factual inaccuracies,
- competing infra CEOs resurfacing old security research,
- and a visible shift in sentiment among highly engaged developers.
This post explains what went wrong, why the reaction was so strong, and what this episode teaches us about trust, marketing, and correctness in developer infrastructure.
The article that started it all
The post in question is titled:
“Is Backend‑As‑A‑Service (BaaS) Enterprise‑Ready?
A Hands‑On Review of Convex and Supabase”
It was published on a consulting firm’s blog and framed as:
- independent
- neutral
- hands‑on
- enterprise‑focused
That framing matters — because once you claim neutrality, technical accuracy becomes non‑negotiable.
The first red flag: framing Convex as “temporary”
One section in particular drew immediate criticism: “When to choose Convex”.
The article suggested Convex is appropriate if:
- you’re validating an idea and don’t expect it to become production
- your app is “primarily CRUD”
- you’re okay migrating away if the project succeeds
- you want to avoid learning SQL/Postgres
This framing strongly implies:
- Convex is not production‑grade
- Convex doesn’t scale to complex systems
- Convex is a stepping stone, not infrastructure
That implication is factually incorrect and reputationally harmful, especially when presented as neutral analysis.
But framing alone wasn’t what caused the blow‑up.
The real issue was objective technical errors.
The factual inaccuracies that broke trust
1. Supabase Edge Functions described as “typical”
The article states:
“Backend logic in Supabase is typically implemented via TypeScript Edge Functions using the Deno runtime…”
This is not how Supabase is typically used in practice.
Reality:
- Most Supabase users:
- use the Supabase SDK
- hit Postgres directly
- rely on Row Level Security (RLS)
- Backend logic commonly runs on:
- Vercel
- Node servers
- serverless platforms outside Supabase
- Edge Functions are optional and often avoided due to:
- cold starts
- Deno quirks
- local DX friction
Calling Edge Functions “typical” strongly suggests the author did not meaningfully use Supabase in production.
2. Convex described as “Node.js‑based”
The article also claims:
“Convex utilizes TypeScript functions … within a Node.js runtime environment”
This is a subtle but fundamental error.
Reality:
- Convex queries and mutations do NOT run in Node
- They run in a deterministic, sandboxed runtime
- Node.js is optional and used only for
actions(side effects, external APIs)
Determinism is Convex’s core architectural thesis.
Describing it as Node‑based misrepresents how the system works at a foundational level.
Why the reaction escalated so quickly
If Supabase had published a first‑party post saying “we prefer our approach”, this likely wouldn’t have mattered.
The backlash happened because all of the following were true at once:
- The article claimed neutrality
- It contained first‑order technical inaccuracies
- It framed a competitor as non‑enterprise
- It was allegedly commissioned by Supabase
In devtools, trust is binary.
Once developers believe you’re willing to publish misleading technical content under a neutral banner, every past issue gets re‑examined.
Why old security research resurfaced (SupaPwn)
Shortly after the backlash began, PlanetScale’s CEO shared a long security write‑up titled “SupaPwn”.
It documented a chained vulnerability in Supabase’s legacy infrastructure that, under specific conditions, allowed tenant escape.
Important context often missing in social media summaries:
- affected ~0.0006% of instances
- limited to deprecated infrastructure
- patched within ~24 hours
- no evidence of exploitation in the wild
- handled via responsible disclosure
By itself, this was a well‑handled security incident.
But once Supabase’s credibility was questioned, it became rhetorical ammunition.
That’s how trust failures work:
past incidents get reinterpreted through a new lens.
What this was actually about: programming models
Lost in the drama is the real, legitimate difference between these tools.
Supabase optimizes for:
- raw PostgreSQL power
- SQL flexibility
- open‑source foundations
- self‑hosting escape hatches
Convex optimizes for:
- correctness by construction
- deterministic application logic
- realtime by default
- state living in code (agent‑friendly)
Neither approach is “more serious”.
They are different tradeoffs.
Reducing that to “CRUD vs enterprise” is not analysis — it’s distortion.
Appendix A: When to choose Supabase vs Convex (neutral)
When Supabase is a good fit
Supabase works best when:
- You want PostgreSQL as your primary abstraction
- You value SQL, relational modeling, and Postgres extensions
- You’re comfortable owning:
- schema design
- indexing
- query performance
- RLS correctness
- You want self‑hosting and infrastructure control
- Your backend architecture is explicitly multi‑tier
- You prefer flexibility over opinionated constraints
In short: Supabase shines when you want power and control, and are willing to manage more complexity.
When Convex is a good fit
Convex works best when:
- You want data access and business logic unified in TypeScript
- You want transactions and consistency by default
- You want realtime without separate infrastructure
- You’re frontend‑heavy or React‑centric
- You want a backend that’s LLM / agent‑friendly
- You prefer fewer footguns, even if that means fewer knobs
In short: Convex shines when you want strong guarantees and a simpler mental model.
Shared ground
Both Supabase and Convex:
- use ACID‑compliant datastores
- integrate well with modern TS/JS frameworks
- provide file storage and vector search
- offer auth, dashboards, and free tiers
- are open‑source (with different scopes)
Neither is “toy infrastructure”.
Appendix B: Common migration reasons (both directions)
Migrations happen both ways, and usually for understandable reasons.
Common reasons teams migrate from Supabase → Convex
- RLS complexity becomes hard to reason about
- Auth + policy bugs are difficult to debug
- Realtime subscriptions add operational overhead
- Backend logic is split across:
- SQL
- policies
- dashboards
- serverless functions
- Desire for:
- stronger invariants
- fewer partial failure modes
- backend logic fully in code
- Better fit for agent‑driven or LLM‑assisted development
This is less about Supabase being “bad” and more about teams wanting more opinionation and guarantees.
Common reasons teams migrate from Convex → Supabase
- Need for raw SQL, complex joins, or analytics queries
- Requirement to integrate with existing Postgres‑based tooling
- Desire for full database control or self‑hosting
- Constraints of Convex’s programming model feel limiting
- Team already deeply SQL‑centric
- Use cases that map naturally to relational modeling
This is less about Convex being “limited” and more about teams wanting maximum flexibility.
A useful mental model
- Supabase migrations usually happen due to complexity fatigue
- Convex migrations usually happen due to flexibility ceilings
Neither is a failure — they’re signals about mismatched abstractions.
Why this mattered more than a CVE
Ironically, Supabase handled the SupaPwn incident better than many companies handle security issues.
What caused lasting damage was:
- outsourcing a competitive comparison
- not rigorously fact‑checking it
- allowing it to be framed as independent
In devtools, epistemic trust matters more than feature parity.
Engineers forgive bugs.
They do not forgive being misled.
Closing thought
Supabase is not doomed.
Convex is not universally better.
But this episode reinforced something many engineers already believe:
In devtools, credibility compounds — and so does the cost of losing it.
Top comments (1)
Have you gotten your bitcoins stolen from your wallet or invested in a fake investment platform, you are not alone because this happened to me too. I initially lost $145,000 in just three months. I contacted the authorities and they referred me to a recovery company who helped me recover all my funds within 2 days. I’m speaking up to improve awareness of these cryptocurrency thieves and help as much as i can to reduce victims to the minimum. If you have been a victim, Simply contact them on coinhackrecovery @gmailcom for a solution.