Fluxbase vs Supabase

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

Quick Comparison

Feature	Fluxbase	Supabase	Firebase
Deployment	~50MB binary / ~110MB container	~13 containers (~2.5GB)	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/JS	TypeScript/JS	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 "@fluxbase/sdk";
const client = createClient("http://localhost:8080", "api-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("table:public.posts")
  .on("*", (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:

Supabase: