nself vs Firebase

Firebase is Google's app development platform with authentication, Firestore (NoSQL), hosting, cloud functions, and analytics. nself is a self-hosted SQL-first backend with a plugin ecosystem. These are fundamentally different architectures: document-oriented vs relational, managed vs self-hosted, proprietary vs open-source.

Feature matrix

See the [full comparison table](/compare) for a side-by-side view of all 24 features across nself, Supabase, Nhost, Firebase, and Appwrite.

Where Firebase is better

Global scale with zero ops. Firebase scales automatically across Google's infrastructure. No capacity planning, no server management, no failover configuration. For apps that need to handle unpredictable traffic spikes globally, Firebase handles it without you thinking about infrastructure. Source: [Firebase infrastructure](https://firebase.google.com/docs).

Mobile SDKs and offline sync. Firebase has mature, battle-tested SDKs for iOS, Android, Flutter, and web with built-in offline persistence. Firestore caches data locally and syncs when connectivity returns. nself does not provide client-side offline sync out of the box. Source: [Firebase SDKs](https://firebase.google.com/docs/firestore/manage-data/enable-offline).

Authentication breadth. Firebase Auth supports 30+ OAuth providers, phone auth, anonymous auth, email link, and multi-factor auth with minimal configuration. nself's auth covers common providers (Google, GitHub, Apple, email, magic link) but has fewer pre-built integrations. Source: [Firebase Auth](https://firebase.google.com/docs/auth).

Integrated analytics and crash reporting. Firebase Analytics, Crashlytics, and Performance Monitoring are tightly integrated. You get user behavior data, crash reports, and performance traces in one console. nself provides server-side monitoring (Prometheus/Grafana) but not client-side analytics. Source: [Firebase Analytics](https://firebase.google.com/docs/analytics).

Where nself is better

Relational data with real SQL. nself runs PostgreSQL with Hasura GraphQL. If your data has relationships (users have posts, posts have comments, comments have votes), SQL with foreign keys, joins, aggregations, and window functions is simpler and more powerful than Firestore's document model. Firestore requires denormalization and multiple reads for related data. Source: [Firestore data model](https://firebase.google.com/docs/firestore/data-model).

Predictable pricing. Firebase bills per read, write, storage byte, and bandwidth byte. Costs can spike without warning. A viral post that generates 10M reads in a day can cost hundreds of dollars. nself runs on a fixed-cost VPS. At 100K MAU, Firebase can cost $200-500/mo vs nself's $10-20/mo. Source: [Firebase pricing](https://firebase.google.com/pricing).

No vendor lock-in. Firebase uses proprietary APIs (Firestore, Firebase Auth, Cloud Functions for Firebase). Moving off Firebase means rewriting your entire backend. nself uses standard PostgreSQL and Hasura GraphQL, which work with any hosting provider. Source: [Firebase documentation](https://firebase.google.com/docs).

Data ownership and privacy. Your nself database runs on hardware you control. Google stores Firebase data on their infrastructure and processes it under their terms of service. For GDPR, HIPAA, or government data residency requirements, self-hosting eliminates third-party data processor concerns. Source: [Firebase privacy](https://firebase.google.com/support/privacy).

Side-by-side pricing

*Prices from public pricing pages, verified April 2026.*

| Scale | nself | Firebase (Blaze plan) |

|-------|-------|-----------------------|

| **Startup (10K MAU)** | $5/mo (VPS) + $0 CLI | ~$25/mo (reads + writes + storage) |

| **Growth (100K MAU)** | $10-20/mo (larger VPS) | ~$200-500/mo (usage-based) |

| **Scale (1M MAU)** | $50-100/mo (dedicated) | ~$2000-5000/mo (usage-based) |

Firebase pricing is highly variable. The estimates above assume moderate read/write patterns. Apps with high read-to-write ratios (social feeds, dashboards) can cost significantly more.

Choose nself if...

1. Your data is relational and you need joins, aggregations, and foreign keys

2. Predictable monthly billing is a hard requirement

3. You cannot accept vendor lock-in to Google's proprietary APIs

4. Data sovereignty, GDPR, or air-gapped deployment is required

5. You want server-side plugins for AI, media processing, chat, or billing

Choose Firebase if...

1. You need automatic global scaling with zero infrastructure management

2. Your app is mobile-first and needs offline sync, push notifications, and crash reporting

3. You prefer a document/NoSQL data model over relational

4. You need 30+ OAuth providers and phone auth with minimal configuration

5. You want integrated client-side analytics (user behavior, funnels, A/B testing)

Migration guide

Firebase to nself is a larger migration because the data models differ fundamentally (NoSQL documents to SQL tables).

### Step 1: Export Firestore data

# Using gcloud CLI
gcloud firestore export gs://YOUR-BUCKET/firestore-export \
  --project YOUR-FIREBASE-PROJECT-ID

# Download the export locally
gsutil -m cp -r gs://YOUR-BUCKET/firestore-export ./firestore-export

### Step 2: Convert Firestore documents to SQL

Firestore documents need to be flattened into relational tables. Each collection becomes a table. Nested documents and arrays become foreign key relationships.

// scripts/migrations/firebase-to-nself/convert-firestore.mjs
import { readFirestoreExport } from './lib/firestore-reader.mjs'

// Example: Convert a 'posts' collection with nested 'comments' subcollection
// Firestore: /posts/{postId}/comments/{commentId}
// SQL: posts table + comments table with post_id foreign key

const collections = await readFirestoreExport('./firestore-export')

for (const [name, docs] of Object.entries(collections)) {
  // Generate CREATE TABLE from document shape
  const schema = inferSchema(docs)
  const createTable = generateCreateTable(name, schema)
  const inserts = generateInserts(name, docs, schema)

  writeFileSync(`./sql/${name}.sql`, [createTable, ...inserts].join('\n'))
}

### Step 3: Export Firebase Auth users

# Using Firebase Admin SDK
firebase auth:export firebase_users.json \
  --project YOUR-FIREBASE-PROJECT-ID \
  --format json

# Convert to nself auth format
node scripts/migrations/firebase-to-nself/convert-auth-users.mjs \
  firebase_users.json \
  nself_users.json

### Step 4: Install nself and import

curl -fsSL https://install.nself.org | sh
nself init my-project
cd my-project
nself start

# Create your relational schema
nself db migrate up

# Import converted data
for f in ./sql/*.sql; do
  nself db psql -f "$f"
done

# Import auth users
nself auth import nself_users.json

### Step 5: Transfer Cloud Storage files

# Download from Firebase Cloud Storage
gsutil -m cp -r gs://YOUR-FIREBASE-STORAGE-BUCKET ./storage-export

# Upload to nself MinIO
nself storage upload ./storage-export/ /default/

### Step 6: Rewrite Cloud Functions

Firebase Cloud Functions need to be rewritten as nself Functions or Custom Services:

// Before (Firebase Cloud Function)
exports.onUserCreate = functions.auth.user().onCreate(async (user) => {
  await admin.firestore().collection('profiles').doc(user.uid).set({
    displayName: user.displayName,
    createdAt: admin.firestore.FieldValue.serverTimestamp(),
  })
})

// After (nself Hasura Event Trigger + webhook)
// 1. Create event trigger on auth.users INSERT in Hasura console
// 2. Handle in your Functions service or Custom Service:
app.post('/webhooks/user-created', async (req, res) => {
  const { event } = req.body
  const user = event.data.new
  await hasuraClient.mutate({
    mutation: INSERT_PROFILE,
    variables: {
      userId: user.id,
      displayName: user.display_name,
    },
  })
  res.json({ ok: true })
})

### Step 7: Update client code

Replace Firebase SDK calls with GraphQL:

// Before (Firebase)
const snapshot = await db.collection('posts')
  .where('userId', '==', uid)
  .orderBy('createdAt', 'desc')
  .limit(20)
  .get()
const posts = snapshot.docs.map(doc => ({ id: doc.id, ...doc.data() }))

// After (nself / Hasura GraphQL)
const { data } = await client.query({
  query: gql`
    query GetPosts($userId: uuid!) {
      posts(
        where: { user_id: { _eq: $userId } }
        order_by: { created_at: desc }
        limit: 20
      ) {
        id
        title
        content
        created_at
      }
    }
  `,
  variables: { userId: uid },
})
const posts = data.posts

FAQ

**Can I use Firebase client SDKs with nself?**

No. Firebase SDKs are tightly coupled to Google's proprietary APIs (Firestore, Firebase Auth, Cloud Functions). You need to switch to a GraphQL client for data and nself's auth endpoints for authentication.

**Is Firestore or PostgreSQL better for my app?**

If your data is mostly flat documents with simple key-value lookups, Firestore works fine. If you need joins, aggregations, transactions across tables, or complex queries, PostgreSQL is a better fit. Most production apps with user-generated content benefit from relational data modeling.

**Does nself support push notifications?**

Yes, via the notify pro plugin. It supports FCM (Firebase Cloud Messaging), APNs (Apple Push), and web push. You can keep using FCM for push delivery while running your backend on nself.

**What about Firebase Hosting?**

nself does not include frontend hosting. Deploy your frontend to Vercel, Netlify, Cloudflare Pages, or serve static files through nself's Nginx.

**Can I keep Firebase Analytics while using nself?**

Yes. Firebase Analytics runs in the client and does not depend on your backend. You can use Firebase Analytics, Crashlytics, and Performance Monitoring alongside an nself backend.

**What replaces Firestore Security Rules?**

Hasura's role-based permission system. You define which roles can access which tables, columns, and rows. It is more granular than Security Rules (column-level access, aggregation permissions) but uses a different configuration model.

**How long does Firebase migration take?**

Longer than migrating from Supabase or Nhost because the data model changes. Plan 2-5 days for a medium-complexity app: 1 day for data conversion, 1 day for auth migration, 1-3 days for rewriting Cloud Functions and client code.

**Does nself support Firebase's offline sync?**

Not natively. nself provides real-time subscriptions via Hasura WebSockets, but client-side offline caching and sync must be implemented in your app layer. Libraries like Apollo Client provide offline cache capabilities.

**What about Firebase Remote Config and A/B testing?**

nself does not have equivalents. For feature flags and A/B testing, use a third-party service like LaunchDarkly, PostHog, or Statsig alongside your nself backend.

**Can I migrate incrementally from Firebase?**

Yes. You can run Firebase and nself in parallel. Move one feature at a time: start with new features on nself, then migrate existing Firebase collections to Postgres tables as you go.

Ready to try nself?

The CLI is MIT-licensed and free. SQL-first, plugin-powered, self-hosted. Membership starts at $0.99/mo for pro plugins.

[Install nself](https://install.nself.org) | [Run the migration script on a test project](/vs/firebase#migration-guide)