Fluxbase vs Supabase

Fluxbase provides API-compatible alternatives to Supabase’s core features in a single container (or binary). If you’re evaluating Fluxbase as a Supabase or Firebase alternative, this guide highlights key differences.

Quick Comparison

Feature	Fluxbase	Supabase	Firebase
Deployment	1 binary / 1 container	~13 containers	Cloud only
Dependencies	PostgreSQL only	PostgreSQL + 5+ services	Proprietary
Self-hosting	✅ Easy	⚠️ Complex	❌ No
REST API	✅ Built-in	✅ PostgREST	✅ Auto-generated
Authentication	✅ Built-in	✅ GoTrue	✅ Built-in
Realtime	✅ WebSocket	✅ WebSocket	✅ WebSocket
Storage	✅ S3 or local	✅ S3 or local	✅ Cloud Storage
Edge Functions	✅ Deno	✅ Deno	✅ Cloud Functions
Secrets	✅ Built-in	✅ Vault	❌ No
AI Chatbots	✅ Built-in	❌ No	❌ No
Background Jobs	✅ Built-in	✅ pg_cron (ext)	❌ No
Database	PostgreSQL 15+	PostgreSQL 15+	Proprietary (NoSQL)
Row-Level Security	✅ Yes	✅ Yes	⚠️ Rules-based
Client SDK	TypeScript, React	JS, Flutter, Python, Swift, Kotlin, C#	TypeScript/JS
Horizontal Scaling	✅ Yes (distributed backends)	✅ Yes (read replicas)	✅ Yes (auto)
Open Source	✅ AGPLv3	✅ Apache 2.0	❌ Proprietary
CLI	✅ Fluxbase CLI	⚠️ Only cloud version	⚠️ Only cloud

SDK Compatibility

The Fluxbase SDK is API-compatible with Supabase. Only the import statement differs:

// Supabase
import { createClient } from "@supabase/supabase-js";
const client = createClient("https://project.supabase.co", "anon-key");

// Fluxbase
import { createClient } from "@nimbleflux/fluxbase-sdk";
const client = createClient("http://localhost:8080", "anon-key");

// Everything else is identical
const { data, error } = await client
  .from("users")
  .select("id, name")
  .eq("status", "active");

All query methods (.select(), .insert(), .update(), .delete(), .eq(), .order(), etc.) work identically.

Authentication

Same JWT-based flow with identical method signatures:

// Sign up
const { data, error } = await client.auth.signUp({
  email: "user@example.com",
  password: "password123",
});

// Sign in
await client.auth.signInWithPassword({ email, password });

// Get session
const {
  data: { session },
} = await client.auth.getSession();

Both support email/password, magic links, OAuth providers, and session management.

RLS syntax:

USING (auth.uid() = user_id)

Realtime

Similar patterns with different syntax:

// Supabase
client
  .channel("changes")
  .on(
    "postgres_changes",
    { event: "*", schema: "public", table: "posts" },
    (payload) => console.log(payload),
  )
  .subscribe();

// Fluxbase
client.realtime
  .channel("posts-changes")
  .on("postgres_changes", { table: "posts" }, (payload) => console.log(payload))
  .subscribe();

Storage

Identical API for file operations:

// Upload
await client.storage.from("avatars").upload("user1.png", file);

// Download
await client.storage.from("avatars").download("user1.png");

// List
await client.storage.from("avatars").list();

Edge Functions

Both use Deno runtime with different deployment approaches:

Supabase: CLI-based deployment with serve() function

Fluxbase: File-based (GitOps), API-based, or dashboard deployment with handler() function

Function code requires minor adaptation when switching platforms.

When to Choose Fluxbase

• You want simple deployment (single binary or container)
• You prefer self-hosting with full control
• You need predictable costs (no usage fees)
• You want to customize backend code
• You want horizontal scaling with just PostgreSQL (no Redis required)
• You need AI chatbots with database access built-in

When to Choose Supabase

• You want a hosted service with free tier
• You prefer fully managed infrastructure
• You want professional support
• You don’t want to manage any infrastructure
• You need built-in read replicas and global edge functions

Deployment

Fluxbase: Single binary or container

Supabase: Multiple services via docker-compose

Migration Considerations

Switching between platforms requires:

• Database: Standard PostgreSQL migration (pg_dump/restore)
• RLS policies: Update syntax (auth.uid() ↔ current_setting())
• SDK code: Change import statement only
• Edge functions: Adapt function signature
• Testing: Verify behavior in new environment

Not a one-click migration, but API compatibility minimizes code changes.

Scaling

Fluxbase: Supports both vertical and horizontal scaling with distributed state backends

Supabase: Horizontal scaling with read replicas for high traffic

Fluxbase horizontal scaling features:

• Distributed rate limiting - Shared counters across all instances (via PostgreSQL or Redis/Dragonfly)
• Cross-instance broadcasts - Pub/sub for realtime application events
• Scheduler leader election - Prevents duplicate cron job execution
• Stateless authentication - Nonces stored in PostgreSQL for multi-instance auth flows

Requirements:

• External PostgreSQL database (stores data, sessions, and distributed state)
• S3-compatible storage (MinIO, AWS S3, etc.) instead of local filesystem
• Load balancer with session stickiness for WebSocket connections

Configuration:

# Enable distributed state (PostgreSQL backend, no extra dependencies)
FLUXBASE_SCALING_BACKEND=postgres
FLUXBASE_SCALING_ENABLE_SCHEDULER_LEADER_ELECTION=true

# Or use Dragonfly for high-scale (1000+ req/s)
FLUXBASE_SCALING_BACKEND=redis
FLUXBASE_SCALING_REDIS_URL=redis://dragonfly:6379

See Deployment: Scaling for full configuration details.

Resources

Fluxbase:

• Documentation
• GitHub
• API Reference

Supabase:

• Documentation
• GitHub
• Pricing