The platform

Everything your appneeds from a backend.In one program.

A database with plain-language access rules, sign-in in every form, files, live updates and a dashboard anyone can use. All of it answers on one address.

Architecture

One address.
Every service.

Everything answers on one port. Quenchbase sends each request to the right part, and only Postgres, PostgREST and imgproxy run beside it.

Your appsupabase-js, Swift, Kotlin, Flutter…
quenchbase:8000
/DashboardBuilt in
/auth/v1AuthBuilt in · a port of GoTrue
/rest/v1REST and GraphQLPostgREST, run alongside
/storage/v1StorageBuilt in · imgproxy for resizing
/realtime/v1RealtimeBuilt in · WebSockets
/pgpostgres-metaBuilt in · secret key only
Postgres
supabase/postgres, your data in Docker volumes
db-datastorageconfig
The parts

Five parts. Zero glue.

01 · Database

Postgres you can talk to.

Your tables over REST and GraphQL the moment you create them. Decide who can read and change rows in plain words.

  • Ready-made access rules, written as policies for you
  • Show SQL on every change, so you learn as you go
  • Start from a blank table or a CSV file
Who can read rows?
Nobody yetAdd rules later. Your server code with the secret key can still read.
AnyoneIncluding visitors who haven't signed in.
Signed-in usersAnyone with an account.
Only the row's ownerEach person sees just their own rows.
02 · Auth

Sign-in, every way people expect.

A port of GoTrue, built into the same program. Turn methods on from the dashboard, not a config file.

  • Email and password, magic links and phone
  • Social logins, SAML and passkeys
  • Multi-factor authentication
How will people sign in to your app?
Let people create accountsTurn this off if you'll add every user yourself.
Ask new users to confirm their emailThey get a link before their first sign-in.
Allow guest sign-insPeople can try your app before making an account.
PasskeysMagic linksSAMLMFA
03 · Storage

Files, without the fuss.

Buckets for everything your app keeps. Uploads that survive a dropped connection, and images resized when they're requested.

  • Resumable uploads
  • Image resizing through imgproxy
  • An S3-compatible API for your existing tools
avatarsAnyone with a file's link can view it.
Public
uploadsOnly people with permission or a signed link.
Private
invoicesOnly people with permission or a signed link.
Private
GET /storage/v1/render/image/public/avatars/ada.png?width=256
04 · Realtime

Live, three ways.

Send messages between clients, see who's online, and hear about database changes the moment they happen. All over WebSockets.

  • Broadcast
  • Presence
  • Database changes
ALGHKJ
3 online
INSERTtodos · "Ship the landing page"
UPDATEtodos · done → true
BROADCASTcursor · x 412, y 96
db.channel("todos")
  .on("postgres_changes", { event: "*", schema: "public" }, show)
  .subscribe();
05 · Dashboard

A dashboard that explains itself.

Written for someone who has never run a backend. Plain language, safe defaults, and a confirmation before anything you can't undo.

  • Every error says what to do next
  • Light and dark, keyboard and screen readers
  • Embedded in the binary, with no outside calls
Search or jump to…⌘K
OverviewTable editorSQL editorUsersSign-in methodsStorageRealtimeDatabaseAPI docsLogs
Specs

Under the hood.

Built with
Rust. One program instead of a dozen services.
Runs as
Four containers: Quenchbase, Postgres (supabase/postgres), PostgREST and imgproxy.
Needs
Docker and about 1 GB of memory.
Setup
A short wizard in your browser. No configuration file to write; every secret is generated for you.
Your data
In Docker volumes: db-data, storage and config. The config volume holds your keys.
Compatibility
Speaks the Supabase API, so Supabase client libraries work as they are.
Drop-in mode
Stands in for the auth, meta, storage and realtime containers of a self-hosted Supabase setup.
Verified
Each service is checked against the original implementation with differential test suites.
License
Apache-2.0.

See it for yourself.