Skip to content

MongoDB

@rebasepro/server-mongo implements Rebase’s BackendBootstrapper against MongoDB. The REST API, the generated SDK, the admin panel and the auth surface all work over it.

pnpm add @rebasepro/server-mongo
import { initializeRebaseBackend } from "@rebasepro/server";
import { createMongoBootstrapper, createMongoDBConnection } from "@rebasepro/server-mongo";
const { db, client } = await createMongoDBConnection(process.env.DATABASE_URL!, "app");
await initializeRebaseBackend({
app,
server,
bootstrappers: [createMongoBootstrapper({ connection: db, client })]
});

Set DATABASE_URL to a MongoDB connection string (mongodb://… or mongodb+srv://…); the second argument names the database.

Data API The full REST surface: list, get, create, update, delete, filters, ordering, pagination
Generated SDK The same typed client as on Postgres
Realtime Change streams. This needs a replica set — a standalone mongod has no oplog to tail, so realtime is silently unavailable there
History Snapshot-based, the same shape as on Postgres
Auth The full auth surface, with its repositories stored in MongoDB
Admin panel Collections, forms, relations in the UI, storage fields
  • No row-level security. See the warning above. This is the important one.
  • No SQL surface. Studio’s SQL editor, the RLS policy editor and pnpm rls:check are Postgres features and are not available.
  • No relational integrity. A relation is a stored reference the application resolves; there is no foreign key, so nothing at the database level stops a dangling one.
  • No rebase db push / generate / migrate. MongoDB has no schema to migrate. Collections appear as documents are written.

Take MongoDB when the data is genuinely document-shaped and the authorization model lives in your application anyway. Take PostgreSQL when you want the database itself to be the thing enforcing who sees which row — which is the argument Rebase makes everywhere else on this site.