PocketBase Alternatives in 2026: When a Single Binary Is Not Enough

PocketBase packs a backend into one Go binary: an embedded SQLite database with realtime subscriptions, auth, file storage and an admin dashboard. You download it, run it, and have an API in minutes. It fits prototypes, internal tools and small apps, and you can extend it in Go or JavaScript when the built-in collections are not enough.

The single binary is also the ceiling. These are the reasons teams look for PocketBase alternatives:

• It runs as one process on one server with SQLite, so scaling means a bigger machine, and high availability is something you build around it.
• It is still before v1.0, and the project states that full backward compatibility is not guaranteed until then.
• Backups, upgrades, TLS and monitoring are yours on whatever server you run.
• Business logic grows into hooks inside the same process, which gets hard to test and split as the app grows.

PocketBase alternatives at a glance

Each option is covered below, starting with Encore.

Running a Go or TypeScript backend in your own cloud with Encore

Encore combines an open source infrastructure SDK for TypeScript and Go with a platform that provisions and deploys into your own AWS or GCP account. Where PocketBase gives you collections and hooks, Encore gives you services: typed API endpoints, an auth handler, and Postgres databases, Pub/Sub, cron jobs, buckets and secrets declared in code. Encore provisions RDS, SNS and SQS, S3 and Fargate on AWS or the GCP equivalents, with an IAM role for each service.

PocketBase API rules such as "only the owner can list their posts" become ordinary Go:

// posts/posts.go
package posts

import (
	"context"
	"crypto/sha256"
	"encoding/hex"

	"encore.dev/beta/auth"
	"encore.dev/beta/errs"
	"encore.dev/storage/sqldb"
)

var db = sqldb.NewDatabase("posts", sqldb.DatabaseConfig{
	Migrations: "./migrations",
})

// AuthHandler runs for every request with an Authorization: Bearer header.
// Session tokens are stored hashed, so a database leak does not expose them.
//
//encore:authhandler
func AuthHandler(ctx context.Context, token string) (auth.UID, error) {
	sum := sha256.Sum256([]byte(token))
	var userID string
	err := db.QueryRow(ctx, `
		SELECT user_id FROM sessions
		WHERE token_hash = $1 AND expires_at > now()`, hex.EncodeToString(sum[:]),
	).Scan(&userID)
	if err != nil {
		return "", &errs.Error{Code: errs.Unauthenticated, Message: "invalid session"}
	}
	return auth.UID(userID), nil
}

type Post struct {
	ID    int64  `json:"id"`
	Title string `json:"title"`
}

type MineResponse struct {
	Posts []Post `json:"posts"`
}

//encore:api auth method=GET path=/posts/mine
func Mine(ctx context.Context) (*MineResponse, error) {
	uid, _ := auth.UserID()
	rows, err := db.Query(ctx,
		`SELECT id, title FROM posts WHERE owner_id = $1 ORDER BY id DESC`, string(uid))
	if err != nil {
		return nil, err
	}
	defer rows.Close()
	resp := &MineResponse{}
	for rows.Next() {
		var p Post
		if err := rows.Scan(&p.ID, &p.Title); err != nil {
			return nil, err
		}
		resp.Posts = append(resp.Posts, p)
	}
	return resp, rows.Err()
}

The migration in posts/migrations creates the sessions and posts tables the queries use:

-- posts/migrations/1_create_tables.up.sql
CREATE TABLE sessions (
    token_hash TEXT PRIMARY KEY,
    user_id TEXT NOT NULL,
    expires_at TIMESTAMPTZ NOT NULL
);

CREATE TABLE posts (
    id BIGSERIAL PRIMARY KEY,
    owner_id TEXT NOT NULL,
    title TEXT NOT NULL
);

encore run starts Postgres locally and applies the migrations, so the endpoint, the auth handler and the query are tested together on your laptop. In the cloud, the database is RDS or Cloud SQL with backups, and the service runs on Fargate or Cloud Run with as many instances as traffic needs. You can also verify tokens from Clerk, Auth0 or Firebase Auth in the same handler instead of keeping sessions yourself.

~/orders — claude

Claude Code v2.1.180Opus 5.5~/orders

What you give up is PocketBase's admin UI for editing records and the zero-code collections. Encore fits apps whose logic lives in backend code.

Supabase: PocketBase convenience on Postgres

Supabase is the closest match in spirit: a dashboard, auth, file storage, realtime and generated APIs, but on PostgreSQL. Access rules are Row Level Security policies, server code runs as Edge Functions on Deno, and you can self-host it or use the hosted service.

Moving from SQLite to Postgres gets you replicas, extensions and standard tooling. You also leave the single binary, and on the hosted free tier, projects pause after a week of inactivity.

Appwrite: a fuller self-hosted backend

Appwrite is an open source backend server with databases, auth, storage, functions, messaging and realtime, plus SDKs for web, mobile and server platforms. You self-host it with Docker or use Appwrite Cloud, and its console covers much of what PocketBase's admin UI does.

It is a bigger system to run than PocketBase: a set of containers instead of one binary. Teams choose it when they want to keep self-hosting but need more services and SDKs than PocketBase offers.

Convex: a reactive TypeScript database

Convex stores documents and runs queries and mutations as TypeScript functions, and clients that subscribe to a query update automatically when the data changes. It is hosted, with an open source backend you can self-host, and it suits apps where live updates are the core of the product.

It is a different model from both PocketBase and SQL. Data access goes through Convex functions, and moving away later means rewriting those functions against another database.

Nhost: Postgres with GraphQL

Nhost combines Postgres, Hasura's GraphQL engine, auth, storage and serverless functions. Permissions are Hasura rules on tables and roles, and clients query everything through GraphQL with subscriptions for realtime.

It fits teams that want GraphQL as the primary API. If your frontend already speaks REST to PocketBase, that is a bigger switch than moving to Supabase.

Firebase: managed services for mobile apps

Firebase offers Cloud Firestore, auth, storage, Cloud Functions, push notifications and hosting, all managed by Google. Its mobile SDKs handle offline sync and realtime listeners, which is often what PocketBase users building mobile apps want next.

The data model is documents, not tables, and Firestore bills per read, write and delete. Apps with relational data or heavy reads tend to find that harder to live with as they grow.

How to choose

Pick Encore when your PocketBase hooks have turned into a backend and you want Go or TypeScript services on Postgres in your own AWS or GCP account, with local development that matches the cloud. Pick Supabase to keep the dashboard-and-API model on Postgres, Appwrite to keep self-hosting with more features, Convex for realtime TypeScript apps, Nhost for GraphQL, and Firebase for mobile apps that need offline sync.

Related guides

• Supabase alternatives
• Firebase alternatives
• How to migrate from Appwrite to AWS
• How to add a database to a Go API