Conversation
WalkthroughThis change adds a new blog post file comparing three backend-as-a-service platforms (Supabase, Firebase, and Appwrite) for 2026, along with a corresponding cache mapping entry. The blog post includes frontmatter metadata, platform overviews, feature comparisons across authentication, database, storage, realtime capabilities, serverless functions, and local development, pricing analysis, and a decision guide for selecting the appropriate backend solution. Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/+page.markdoc (1)
182-183: Fix the run-on sentence in the Permissions section.The sentence currently reads as two thoughts merged together, which hurts readability.
✍️ Suggested copy edit
-Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows getting it right early matters. +Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows, so getting it right early matters.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/`+page.markdoc around lines 182 - 183, In the Permissions section replace the run-on sentence "Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows getting it right early matters." with a clear, punctuated version—either split into two sentences or add a conjunction and comma; e.g. make it "Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows, so getting it right early matters." to fix readability.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/`+page.markdoc:
- Around line 194-199: The Firebase paragraph in the blog content incorrectly
claims the Blaze plan "comes with $300 in free credit"; update the Firebase
wording in the block that begins "**Firebase** operates..." to remove that claim
and instead state the accurate billing model (Blaze is pay-as-you-go and
inherits Spark free-tier limits) with wording sourced from
firebase.google.com/pricing; also append a time qualifier "as of March 2026" to
the pricing section header or each provider block (Firebase, Supabase, Appwrite)
so all listed figures are explicitly dated.
---
Nitpick comments:
In
`@src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/`+page.markdoc:
- Around line 182-183: In the Permissions section replace the run-on sentence
"Permissions determine who can access what across your database, storage, and
functions. A poorly designed permissions model becomes one of the hardest things
to refactor as an application grows getting it right early matters." with a
clear, punctuated version—either split into two sentences or add a conjunction
and comma; e.g. make it "Permissions determine who can access what across your
database, storage, and functions. A poorly designed permissions model becomes
one of the hardest things to refactor as an application grows, so getting it
right early matters." to fix readability.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ffb18a5a-bb05-4b9d-a5b0-646c14692cf2
⛔ Files ignored due to path filters (1)
static/images/blog/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/cover.pngis excluded by!**/*.png
📒 Files selected for processing (2)
.optimize-cache.jsonsrc/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/+page.markdoc
| **Firebase** operates on a two-tier model: the **Spark (no-cost) plan** for getting started with no payment method required, and the **Blaze (pay-as-you-go) plan** which comes with $300 in free credit. The catch is that Blaze pricing scales across reads, writes, storage, bandwidth, and Cloud Functions invocations separately, making costs genuinely difficult to forecast as usage grows. Teams that hit scale without careful monitoring have been caught off guard by Firebase bills. | ||
|
|
||
| **Supabase** positions itself around predictable, flat-rate tiers. The **Free plan** ($0/month) supports 50K monthly active users, 500MB database storage, and 5GB egress, suitable for side projects and prototypes. The **Pro plan** starts at **$25/month**, covering 100K MAUs, 8GB disk, and 250GB egress with clear overage rates. For teams needing SOC2, HIPAA, SSO, and 14-day backups, the **Team plan** starts at **$599/month**. Enterprise pricing is custom. | ||
|
|
||
| **Appwrite** mirrors Supabase's entry pricing with a **Free plan** ($0/month) offering 75K MAUs, 5GB bandwidth, 2GB storage, and 750K function executions. The **Pro plan** starts at **$25/month** and significantly increases limits, covering 200K MAUs, 2TB bandwidth, 150GB storage, and 3.5M executions, along with organization roles and daily backups. **Enterprise** is custom, adding SOC-2, HIPAA, SSO, and bring-your-own-cloud options. | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Verify current pricing/limits for Firebase (Spark/Blaze), Supabase (Free/Pro/Team), and Appwrite (Free/Pro/Enterprise) from official pricing pages, and confirm whether the values in this draft are accurate as of March 2026.
💡 Result:
Current pricing and limits as of March 2026 from official sources: Firebase (Spark/Blaze): - Spark: No-cost plan with generous usage limits (e.g., Cloud Firestore: 1 GiB storage, 20K writes/day, 50K reads/day; Hosting: 10 GB storage, 10 GB/month transfer; Authentication: 50K MAUs). Exceeding limits shuts off the product until next cycle. No payment method needed. - Blaze: Pay-as-you-go, includes Spark no-cost usage + billing for excess (e.g., Cloud Firestore/Google Cloud rates; Hosting uncached $0.20/GiB after 10 GiB). Access to more services like Cloud Functions. Supabase (Free/Pro/Team): - Free: $0/month, 500 MB database, 50K MAUs, 5 GB bandwidth, 1 GB storage, 2 projects max (paused after 1 week inactivity), 500K Edge Function invocations. - Pro: From $25/month + $10 compute credits, 8 GB database/project, 100K MAUs ($0.00325/extra), 250 GB bandwidth ($0.09/GB extra), 100 GB storage ($0.021/GB extra), email support, daily backups. - Team: From $599/month + $10 compute credits, adds SOC2, HIPAA add-on, more roles. Appwrite (Free/Pro/Enterprise): - Free: $0, 5 GB bandwidth/month, 2 GB storage, 750K executions/month, 75K MAUs, community support, limits: 1 database/bucket, 2 functions/project, 2 projects (paused after 1 week inactivity). - Pro: From $25/month, dedicated resources/project: 2 TB bandwidth, 150 GB storage, 3.5M executions, 200K MAUs, organization roles, email support, add-ons ($15/100GB bandwidth extra, $2.8/100GB storage extra), unlimited databases/functions. - Enterprise: Custom pricing, uptime SLAs, 24/7 support, SOC2/HIPAA, log drains. The draft's values cannot be verified without the specific draft content provided in the query. However, the above reflects official pricing from firebase.google.com/pricing, supabase.com pricing pages/docs, and appwrite.io/pricing as of 2026-03-30. No major changes noted in recent changelogs (e.g., Appwrite Free functions reduced to 2 in Jan 2026). Use pricing calculators for precise estimates.
Citations:
- 1: https://firebase.google.com/pricing
- 2: https://firebase.google.com/docs/projects/billing/firebase-pricing-plans
- 3: https://firebase.google.com./pricing
- 4: https://firebase.google.com/docs/hosting/usage-quotas-pricing
- 5: https://supabase.com/docs/guides/platform/billing-on-supabase
- 6: https://styx.studio/pricing
- 7: https://appwrite.io/pricing
- 8: https://appwrite.io/changelog/entry/2026-01-08
- 9: https://supabase.com/docs/guides/functions/pricing
Firebase Blaze pricing claim is factually incorrect.
The statement that the Blaze plan "comes with $300 in free credit" cannot be verified against official Firebase pricing documentation. Firebase Blaze is a pure pay-as-you-go model that includes Spark's free tier usage limits, but does not advertise a $300 free credit. Remove or replace this claim with accurate information from firebase.google.com/pricing.
Also add an explicit "as of March 2026" date qualifier to the pricing section since these figures are time-sensitive and may change.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/`+page.markdoc
around lines 194 - 199, The Firebase paragraph in the blog content incorrectly
claims the Blaze plan "comes with $300 in free credit"; update the Firebase
wording in the block that begins "**Firebase** operates..." to remove that claim
and instead state the accurate billing model (Blaze is pay-as-you-go and
inherits Spark free-tier limits) with wording sourced from
firebase.google.com/pricing; also append a time qualifier "as of March 2026" to
the pricing section header or each provider block (Firebase, Supabase, Appwrite)
so all listed figures are explicitly dated.
Greptile SummaryThis PR adds a new comparison blog post titled "Supabase vs Firebase vs Appwrite: Choosing the right backend in 2026," along with a cover image and the corresponding image-optimization cache entry. The post provides a structured breakdown of the three platforms across authentication, databases, storage, real-time, serverless functions, developer experience, permissions, and pricing, and fits well within the existing series of comparison articles on the site. Two issues were found:
Confidence Score: 3/5Not safe to merge until the Firebase pricing claim is corrected, as it contains a factual inaccuracy that could mislead readers. The Firebase Blaze plan '$300 in free credit' statement is factually incorrect and should be corrected before publishing. A P1 factual inaccuracy in a public-facing comparison blog post warrants blocking merge. src/routes/blog/post/supabase-vs-firebase-vs-appwrite-choosing-the-right-backend-in-2026/+page.markdoc — lines 182 and 194 Important Files Changed
Reviews (1): Last reviewed commit: "new comparison blog" | Re-trigger Greptile |
|
|
||
| ## Permissions & Security | ||
|
|
||
| Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows getting it right early matters. |
There was a problem hiding this comment.
Missing punctuation between two sentences
The sentence "A poorly designed permissions model becomes one of the hardest things to refactor as an application grows getting it right early matters." is missing punctuation between the two independent clauses. "grows" and "getting" need to be separated.
| Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows getting it right early matters. | |
| Permissions determine who can access what across your database, storage, and functions. A poorly designed permissions model becomes one of the hardest things to refactor as an application grows — getting it right early matters. |
|
|
||
| Pricing is often where backend platforms diverge the most, and where early decisions can create expensive surprises later. | ||
|
|
||
| **Firebase** operates on a two-tier model: the **Spark (no-cost) plan** for getting started with no payment method required, and the **Blaze (pay-as-you-go) plan** which comes with $300 in free credit. The catch is that Blaze pricing scales across reads, writes, storage, bandwidth, and Cloud Functions invocations separately, making costs genuinely difficult to forecast as usage grows. Teams that hit scale without careful monitoring have been caught off guard by Firebase bills. |
There was a problem hiding this comment.
Potentially misleading Firebase free credit claim
The statement "the Blaze (pay-as-you-go) plan which comes with $300 in free credit" is inaccurate. The $300 free credit is a general Google Cloud new-account trial credit, not a benefit specifically tied to the Firebase Blaze plan. The Blaze plan itself is purely pay-as-you-go with no bundled credit. Readers might interpret this as a permanent feature of subscribing to the Blaze plan rather than a one-time new-GCP-account incentive. Consider revising to avoid this conflation.
Supabase vs Firebase vs Appwrite
Summary by CodeRabbit