At Redpapr, we’ve always believed in using the right tool for the job. As we’ve grown—from a lightweight learning MVP to a full-stack edtech platform with creators, students, content tools, and now desktop AI—we’ve rethought how we store and scale our data.

This is the story of how we evolved our backend—from Firebase, to Supabase, to our current multi-database architecture using:

• 🐘 PostgreSQL — our core relational DB
• 🍃 MongoDB — for flexible, fast-moving internal tools
• 🧱 SQLite — lightweight storage for microapps and our upcoming desktop app

🚀 Phase 1: Firebase – Fast but Fragile

Firebase helped us move quickly in the beginning.

• ✅ Instant setup
• ✅ Realtime features baked in
• ✅ Great for small apps

But we hit walls—fast:

• ❌ Difficult to model relationships cleanly
• ❌ Vendor lock-in around Firestore syntax
• ❌ Complex querying and joins required workarounds
• ❌ Hard to scale into advanced use cases

Firebase was easy to start with—but too rigid and opaque as our app complexity grew.

⚡ Phase 2: Supabase – Closer, but Still Not Enough

Supabase felt like the perfect step forward.

• ✅ PostgreSQL under the hood
• ✅ Built-in auth, storage, and APIs
• ✅ Developer-friendly and open source

We loved it. But eventually:

• ❌ Supabase added abstraction and latency we didn’t need
• ❌ We needed deeper control over migrations, indexing, and performance tuning
• ❌ Supabase's hosted auth and edge functions started limiting us when building tightly coupled systems (like AI tools and creator dashboards)

Supabase made a great bridge—but we were ready to own our infrastructure.

🧠 Phase 3: Native Databases — One Size Doesn’t Fit All

Now, Redpapr uses different databases for different jobs—each chosen for its strength:

🐘 PostgreSQL: Our Main Relational Powerhouse

Everything student-facing now runs on PostgreSQL:

• Structured data (users, enrollments, notes, quizzes, etc.)
• Foreign key relationships, constraints, and transactional safety
• Clean and efficient querying with full control

Postgres is mature, battle-tested, and exactly what we need for core product data.

🍃 MongoDB: Used in Our Internal Creator Portal

Our internal content and creator tools evolve fast—often with new features, fields, and ideas every week.

MongoDB is perfect here:

• Schemaless (or schema-light) by default
• Easy to prototype and ship new features without migrations
• Ideal for storing drafts, templates, metadata, and user-generated structures

In short: when ideas are messy, Mongo gives us room to explore.

🧱 SQLite: Local-First Storage for Microapps and Desktop

We also use SQLite in:

• Internal micro tools (CLI apps, data checkers, light local servers)
• Embedded browser extensions and offline tools
• And most importantly: our upcoming Redpapr Desktop App

Why SQLite?

• Tiny footprint, zero config
• Incredibly fast for local reads/writes
• Works offline, cross-platform
• Supports ACID transactions and even FTS (full-text search)

In our future desktop AI flow, SQLite will help store:

• Local notes
• Bookmarks
• Summaries
• Cached LLM context

All securely, without needing the cloud.

Why This Architecture Works for Us

Instead of fighting one tool to do everything, we embraced specialization.

Final Thoughts

Most companies evolve their database stack over time. At Redpapr, we’ve embraced that evolution as part of our engineering culture.

• We started fast with Firebase.
• We leveled up with Supabase.
• And now we’re confidently running PostgreSQL, MongoDB, and SQLite—each where it shines.

It’s not just about using trendy tools. It’s about choosing the right tech for the right context, and building systems that are scalable, performant, and future-proof.

Want a deeper dive into how we sync SQLite with the cloud or how we manage multi-database ops? We’d love to open-source some of our tooling soon—stay tuned.