BaaS vs FaaS for Light Self-Hosting: Fluxbase, PocketBase, Spin, and Orva as Supabase and Appwrite Alternatives

If you have been following the self-hosting thread on this blog, you know the pattern: a subscription has to earn its keep. The Docker Compose vs Kubernetes post settled when a cluster earns its keep, the Docker vs Podman post settled who owns the process tree, and the durable workflows post drew the line between a queue that retries and an engine that survives a crash. The same question now shows up one layer up, in the backend itself.

Supabase and Appwrite are the two names people reach for, and both are genuinely good products. They are also heavier than most light projects need. Self-hosting Supabase means running a multi-container stack around Postgres, and self-hosting Appwrite means running a Docker Compose deployment with its own services to patch (issues during upgrades are quite common) and back up. If your app is one product with a handful of tables, a login, and a file upload, you are paying for a platform you will not use.

That gap is where the light options live: Fluxbase, PocketBase, Spin, and Orva. This post reviews each one the way an admin reads a repository rather than a landing page: what it is, what its own README claims, what it is better at, where it stops, and the use case where it is the honest answer. There is no code here on purpose, because the decision matters more than the syntax.

The short version

• BaaS and FaaS are different products. A backend as a service gives you the data plane: database, auth, storage, realtime, and generated APIs. A functions as a service gives you compute: write a function, invoke it, schedule it, and bring your own state.
• PocketBase is the lightest BaaS here, and the one with the biggest crowd. One Go binary with embedded SQLite, users, files, realtime subscriptions, and an admin UI, under the MIT license. It is not a FaaS: the JavaScript support is in-process hooks, not isolated functions.
• Fluxbase is the closest thing to a Supabase-shaped BaaS on one binary plus Postgres. PostgREST-compatible REST and GraphQL, auth with OIDC and SAML, storage, realtime, Deno edge functions, pgvector search, row level security, and multi-tenancy. It is also the smallest and youngest project in this list.
• Spin is the most mature FaaS. Apache-2.0, WebAssembly components on Wasmtime, HTTP and Redis triggers, and SDKs for Rust, JavaScript, Go, and Python with key-value and SQL storage built in. It is not a backend: no users, no auth, no file library.
• Orva is the homelab FaaS. Node and Python functions in nsjail sandboxes with warm pools, per-function key-value storage, cron, background jobs, tracing, and an MCP server. Its own README says it is solid for homelabs and internal tools and not recommended for customer-facing production yet.
• TrailBase and Nhost are the two names worth adding. TrailBase is a single Rust executable on SQLite, with Postgres experimental. Nhost is Postgres plus Hasura GraphQL, auth, storage, and Node functions.
• The honest rule: pick the data plane first, then the compute layer, then stop. Most light projects need one of them, not both, and the second one is usually a platform you did not need to run.

BaaS vs FaaS: what you are actually buying

Start with what each family sells. A backend as a service owns the data plane. Someone has decided how tables, permissions, users, files, and subscriptions should work, generated an API from your schema, and given you an admin surface.

You write almost no server code. Supabase, Appwrite, PocketBase, Fluxbase, TrailBase, and Nhost all live here, with different weights and different databases.

A functions as a service owns compute. You write a function, the platform runs it on a trigger and scales it out, and state is your problem: a database, a key-value store, an object bucket. Spin and Orva live here, alongside the hosted classics that taught everyone the vocabulary, AWS Lambda and Cloudflare Workers.

The practical difference is where the hard part sits. In a BaaS the hard part is the schema, the permission model, and the migration path, because the platform owns the query layer and you live inside its rules. In a FaaS the hard part is state: idempotency, retries, what happens when the database is down, and how a function behaves when it is invoked twice.

A useful test before you read any further. If your app is mostly CRUD over a handful of tables with a login, you want a BaaS. If your app is mostly glue, webhooks, scheduled jobs, and small pieces of logic that call other APIs, you want a FaaS. If you need both, run a light BaaS and put functions beside it, which is what Fluxbase does with Deno internally and what PocketBase does with hooks.

The repos, read the way an admin reads them

Here is the snapshot I pulled from each repository while writing this post. Treat it as orientation, not a scorecard: stars measure attention, commits and issues measure activity, and neither tells you whether the thing fits your problem.

PocketBase: the lightest BaaS, and the one with the biggest crowd

PocketBase describes itself as an open source Go backend in one file: an embedded SQLite database with realtime subscriptions, built-in file and user management, an admin dashboard, and a simple REST-ish API. You download a binary, run it, and you have a backend. You can also use it as a Go framework and build your own business logic into the same single executable, and the prebuilt binaries ship with the JavaScript VM plugin enabled, which is how most people extend it.

Better at: the smallest possible footprint and the shortest path from nothing to a working backend. One binary, no Docker, no database server, no Compose file, and an admin UI that is genuinely pleasant. At 61k stars it also has the largest community in this list by an order of magnitude, which matters when you are searching for an answer at midnight. The MIT license removes every commercial question.

Where it stops: it is a BaaS, not a FaaS. The JavaScript support is hooks that run inside the process, which is a fine way to add a route or react to a record change, and it is not the same thing as an isolated function that scales out on its own. SQLite is single-writer, which is fine for a small app and the wrong shape for a write-heavy multi-tenant service. And the project warns that it is still under active development and does not guarantee full backward compatibility before version 1.0, which is a real consideration if you are betting a long-lived product on it.

Fluxbase: Supabase-shaped, single binary, Postgres underneath

Fluxbase describes itself as a lightweight, single-binary backend as a service alternative to Supabase, built in Go with PostgreSQL as the only external dependency.

The feature list is the most Supabase-shaped of anything here: a PostgREST-compatible REST API generated from your schema, GraphQL, authentication with email and magic links plus OAuth2, OIDC, SAML SSO and MFA, realtime subscriptions over PostgreSQL LISTEN and NOTIFY, file storage on the local filesystem or S3 with image transformations, Deno-based edge functions, background jobs with retries and cron, RPC procedures, webhooks with HMAC signing, pgvector semantic search, an MCP server, multi-tenancy with row level security, and database branching. It ships SDKs for TypeScript, React, Vue, Svelte, Kotlin, and Next.

Better at: being the drop-in option for an app that already thinks in Postgres. If your mental model is tables, SQL, row level security, and a REST API generated from a schema, Fluxbase keeps that model and collapses the stack around it to one binary plus a database. The pgvector search and multi-tenancy pieces put it in the same conversation as a small multi-tenant SaaS rather than a hobby backend, and the SDK spread means you are not rewriting your client layer.

Where it stops: at being young. The repository showed 36 stars, 3 forks, and a little over 1,200 commits while I was writing this, which is a serious amount of code and a very small crowd. A project that size has not had years of adversarial attention. It still needs PostgreSQL, so it is not the one-file deployment PocketBase is, and the edge functions need a Deno runtime. The license is AGPL-3.0, which is a non-issue for internal self-hosting and a real conversation if you plan to redistribute or embed it.

Spin: the mature FaaS, and the one that is not a backend

Spin describes itself as an open source framework for building and running fast, secure, and composable cloud microservices with WebAssembly, built on the component model and the Wasmtime runtime. You create an application from a template, build it to Wasm, and run it locally, and the same artifact is what you deploy.

The trigger set is HTTP and Redis, and the feature matrix covers outbound HTTP, configuration variables, key-value storage, SQLite, MySQL and PostgreSQL in some SDKs, outbound Redis, and serverless AI. SDKs are supported for Rust, JavaScript, Go, and Python, with Zig and Moonbit community integrations.

Better at: being the FaaS that has been around long enough to trust. Apache-2.0, 6.5k stars, and more than 5,000 commits is a different class of project from the rest of this list, and the Wasm component model gives it a real story for composable, sandboxed, fast-starting functions in several languages. The built-in key-value and SQL support means a function can hold small state without you running another service for it, and running the whole thing locally with one command is the part that makes the workflow pleasant.

Where it stops: at being a backend. Spin has no user management, no auth service, no file library, and no admin data plane; you bring all of that. The component model and Wasm toolchain are a genuine learning curve if your team lives in Node or Python, and the feature matrix is language-gated: PostgreSQL and MySQL are not in the Python SDK, and the C# SDK lacks key-value and SQLite. There were also 236 open issues at the time of writing, which is normal for a project this size and worth knowing before you adopt it.

Orva: the homelab FaaS, with the caveats it writes down itself

Orva describes itself as a self-hosted functions as a service for homelabs and on-prem, and the pitch is the Lambda workflow on hardware you own: write a JavaScript, TypeScript, or Python function, deploy it, invoke it over HTTP. It runs Node 24 and Python 3.14, sandboxes every invocation in nsjail with a user namespace, chroot, cgroup v2 limits, and a seccomp allowlist, keeps warm pools so repeat calls skip cold starts, and ships a per-function key-value store, background jobs with retries and backoff, cron schedules, function-to-function calls, encrypted secrets, custom routes, signed inbound webhooks, distributed tracing with a waterfall view, content-hashed deploys with rollback, and an MCP server with a built-in AI assistant.

Better at: being the FaaS you can actually run at home without building it. The isolation story is more serious than most homelab projects bother with, the tracing spans a whole HTTP to function to job chain without code changes, and the dashboard plus CLI plus MCP server is a complete operator experience on one box. The 21 starter templates and the preinstalled SDK are aimed at the moment you just want to ship a webhook handler or a cron job.

Where it stops: at the parts its README admits. It says plainly that it is in active development, solid for homelabs, side projects, and internal tools, and not recommended for customer-facing production yet. The repository showed 12 stars and 0 forks, so you are an early adopter, not a late one. It also needs a privileged container to build its sandbox: host PID and cgroup namespaces, SYS_ADMIN, and unconfined seccomp and AppArmor profiles. That is a deliberate trade for real isolation inside the sandbox, and it means you should not put Orva on a box that holds anything else you care about. There is no user or auth data plane either, so it is a compute layer, not a backend.

The two names worth adding: TrailBase and Nhost

Two more repositories came up repeatedly while I was reading around this space, and both belong on the shortlist. TrailBase describes itself as an open, sub-millisecond, single-executable Firebase alternative with type-safe REST and realtime APIs, a built-in WebAssembly runtime, auth, an MCP server, and an admin UI, built on Rust, Wasmtime, and SQLite with experimental PostgreSQL support. It is 5.6k stars, funded through the European NGI Zero Core program, and licensed under OSL-3.0 with permissive Apache-2.0 client libraries, which the project explains at length because the license choice is unusual. Nhost describes itself as an open source Firebase alternative with GraphQL: PostgreSQL, a Hasura instant GraphQL API, auth, storage, and Node serverless functions, MIT licensed, 9.3k stars, with an official docker-compose file for self-hosting. If you want GraphQL as the primary interface, Nhost is the closest thing to a drop-in.

Real use cases, matched to the tool

This is the part that decides it. Features are easy to compare, fit is not.

The combination I would avoid is a full Supabase or Appwrite self-hosted stack for an app with four tables. The stack is not the problem, the maintenance is: every container is something to patch, back up, and debug, which is the same argument the Compose vs Kubernetes post made about platforms in general. Start with the smallest thing that holds your data and your login, and add the compute layer only when you have a function to run.

The limits that bite

• A light BaaS is still a database you own. Whether it is SQLite or Postgres, you are now the backup and restore story, and the drill is the only thing that proves it works. The backup post applies unchanged.
• SQLite is single-writer. PocketBase and TrailBase on SQLite are excellent for reads and small writes, and the wrong shape for a write-heavy multi-tenant service. That is a database property, not a project flaw.
• Cold starts are a design constraint, not a bug. Orva's warm pools exist because they matter, and Spin chose WebAssembly partly because its start times are small.
• The license matters at the edges. PocketBase and Nhost are MIT, Spin and Orva are Apache-2.0, Fluxbase is AGPL-3.0, and TrailBase is OSL-3.0 with Apache-2.0 clients. For internal self-hosting none of that is a problem. If you redistribute or embed, read the terms.
• Young projects have young security stories. Fluxbase and Orva are 36 and 12 stars respectively. Both are readable and honest about their state, and neither has the years of adversarial attention that a 61k-star project has.
• Wasm is a toolchain, not a language. Spin's polyglot story is real and so is the learning curve, and the feature matrix is genuinely different per SDK.
• Version churn is the constant. PocketBase warns that backward compatibility is not guaranteed before 1.0, and every project here ships often. Pin what you run and track releases the way the release-tracking workflow does.

Which should you pick?

• Choose PocketBase when you want a working backend today with the fewest moving parts, you are comfortable with SQLite, and an admin UI matters. It is the default for side projects and internal tools.
• Choose Fluxbase when your app is Postgres-shaped, you want row level security, SQL, and vector search, and you are willing to adopt a young project to get a Supabase-shaped stack in one binary.
• Choose Spin when the work is functions, you want more than one language, and you value a mature project with a real feature matrix over a single-binary deployment.
• Choose Orva when the box is a homelab or an internal tool, you want Node or Python with cron, jobs, and tracing, and you have read the production warning and accepted it.
• Choose TrailBase or Nhost when you want a single-executable BaaS with a realtime API and a permissive client license, or GraphQL and Hasura specifically. Both are lighter than a full Supabase or Appwrite self-host.
• Choose none of them when the app is a multi-step workflow that must survive a crash, or a customer-facing service that needs a platform's compliance and support surface. Use a durable workflow engine for the first, and a hosted BaaS for the second.

My honest read after going through the repositories: the light self-hosting space is finally good enough that the choice is about shape, not capability. PocketBase is the safest bet for a small backend, Fluxbase is the most interesting Supabase alternative if you want Postgres and are comfortable with a young project, Spin is the FaaS to trust, and Orva is the one to watch on a homelab box. Pick the data plane first, add compute only when you have a function worth running, and treat the backup drill as part of the setup rather than a chore for later.

Official sources

• PocketBase: https://github.com/pocketbase/pocketbase and https://pocketbase.io/docs
• Fluxbase: https://github.com/nimbleflux/fluxbase and https://fluxbase.eu
• Spin: https://github.com/spinframework/spin and https://spinframework.dev
• Orva: https://github.com/Harsh-2002/Orva
• TrailBase: https://github.com/trailbaseio/trailbase and https://trailbase.io
• Nhost: https://github.com/nhost/nhost and https://docs.nhost.io
• Supabase: https://supabase.com and Appwrite: https://appwrite.io
• Our Compose vs Kubernetes post: https://systhoughts.com/posts/docker-compose-vs-kubernetes-self-hosted-apps
• Our Docker vs Podman post: https://systhoughts.com/posts/docker-vs-podman-self-hosted-apps
• Our durable workflows post: https://systhoughts.com/posts/durable-workflows-for-architects
• Our backup and recovery keys post: https://systhoughts.com/posts/3-2-1-backup-rule-not-enough-self-hosted-infrastructure
• Our release-tracking workflow: https://systhoughts.com/posts/tracking-software-releases-across-forges

Are you running a light BaaS or a self-hosted FaaS for anything real? Which one earned its keep, and where did you hit the wall the README warned about? Drop it in the comments.

Until next time, keep your systems thoughtful.