Firebase and Supabase SEO blogs

[aishwaripahwa12]

Latest blogs named "The best open-source alternatives to Firebase in 2026" and "The best Supabase alternatives developers should know"

[appwrite]

Appwrite Website

Project ID: 69d7efb00023389e8d27

Sites (1)

Site	Status	Logs	Preview	QR
website 69d7f2670014e24571ca	Failed	View Logs	Preview URL

Website (appwrite/website)

Project ID: 684969cb000a2f6c0a02

Sites (1)

Site	Status	Logs	Preview	QR
website 68496a17000f03d62013	Processing	View Logs	Preview URL

---

Tip

Function scopes give you fine-grained control over API permissions

[greptile-apps]

Greptile Summary

This PR adds two new SEO-focused blog posts — one comparing open-source Firebase alternatives and one comparing Supabase alternatives — along with their cover images and cache entries. Both posts are correctly marked unlisted: true and the aishwari author reference is valid.

• The .optimize-cache.json entries reference cover.png for both new posts, but only cover.avif files were committed. Every other post in the repo follows a PNG-source → AVIF-output pipeline; the missing PNG sources and mismatched cache keys will leave the image optimization step in an inconsistent state.
• Both markdoc files are missing a trailing newline, inconsistent with every other post in the codebase.

Confidence Score: 3/5

The blog content and frontmatter are sound, but the cover images were committed as AVIF without the PNG originals the optimization pipeline expects, and the cache was populated with entries pointing to those non-existent PNG files.

The optimization cache entries reference cover.png files that do not exist in the repository; only cover.avif files were added. Every other post in the repo supplies a PNG source that the tooling converts. This mismatch means the image processing step will either fail to locate its inputs or silently skip conversion, producing incorrect build output for the cover images.

.optimize-cache.json and both cover.avif image files need attention — the PNG source images should be provided, or the cache and markdoc cover paths need to be adjusted to whatever approach is actually supported.

Important Files Changed

Filename	Overview
.optimize-cache.json	Two new cache entries reference cover.png but only cover.avif files were committed; the PNG sources expected by the optimization pipeline are absent.
src/routes/blog/post/the-best-open-source-alternatives-to-firebase-in-2026/+page.markdoc	New SEO blog post comparing Firebase alternatives; frontmatter is valid, author exists, unlisted: true set; missing trailing newline.
src/routes/blog/post/the-best-supabase-alternatives-developers-should-know/+page.markdoc	New SEO blog post comparing Supabase alternatives; frontmatter valid, unlisted: true set; missing trailing newline.
static/images/blog/the-best-open-source-alternatives-to-firebase-in-2026/cover.avif	Cover image added as AVIF directly; no PNG source present, which is inconsistent with the expected optimization pipeline workflow used by other posts.
static/images/blog/the-best-supabase-alternatives-developers-should-know/cover.avif	Cover image added as AVIF directly; no PNG source present, inconsistent with the optimization pipeline workflow.

_{Reviews (1): Last reviewed commit: "latest blogs" | Re-trigger Greptile}

[greptile-apps]

Cache entries reference non-existent .png files

Two entries were added for cover.png, but the actual images committed are cover.avif. Looking at the rest of the cache (e.g. the-complete-vibe-coding-guide-2025/cover.png) and the markdoc convention (which also uses .avif covers), it's clear this project's optimization pipeline expects a PNG source that it then converts to AVIF. These two cache keys point to files that do not exist in the repo, so the optimization step will either fail to find the source or silently skip conversion, leaving the pipeline in an inconsistent state. The AVIF cover images should either be replaced with their PNG originals for normal processing, or the cache entries should be corrected to .avif if a direct AVIF upload path is supported.

[adityaoberai]

Both of these blogs need to be deeper differences blogs, not just high level overviews

Otherwise they might get impressions but they feel like the same AI generated blogs we see on the internet anyway

[adityaoberai]

This is a dead platform and should not be a part of the discussion

[adityaoberai]

Both covers seem very off brand

[adityaoberai]

If it has rows and tables, it cannot be a document style database