Supabase

A complete backend on PostgreSQL in one deployment - what you get, which database to put behind it, and where your keys are.

Supabase is a backend you do not have to write: sign-in, an API over your tables, realtime, file storage and server-side functions, all on a PostgreSQL database. On ISOGrid it is a solution like the others - pick a size, pick a database, deploy - and the project is ready in a few minutes.

What a project contains

Everything Supabase's own self-hosted distribution does:

  • Studio, the dashboard: tables, SQL editor, users, storage, policies.
  • Auth: sign-up and sign-in by email and password, with tokens your API trusts.
  • REST and GraphQL APIs, generated from your tables and protected by row-level security.
  • Realtime: Broadcast, Presence and database changes over websockets.
  • Storage: buckets and files, with image resizing.
  • Edge Functions: your own TypeScript, run on the server.

One address serves all of it. Studio asks for the sign-in shown on the project's Overview tab.

Choosing the database

The project lives in a PostgreSQL database, and you choose which kind when you deploy:

A mini-database - one database on a server shared with other tenants. The cheapest way to start, and everything works except one thing: Realtime delivers Broadcast and Presence, but not database changes. Listening to changes needs a permission that, on a shared server, would reach other tenants' data, so it is not given there.

A PostgreSQL server of your own - single, pooled or highly available. The whole of Supabase, database changes included. Choose it for anything in production.

A server you already have - the project keeps its schemas (auth, storage, realtime) in that server's main database, beside your own tables. One project per server.

A database bought with a project is part of it. It does not appear among your databases, it is looked after from the project's Database tab, and it is removed when the project is.

Your keys

The API keys tab has what a client needs:

  • the project URL;
  • the anon key, safe to ship in a browser or a mobile app - row-level security decides what it can see;
  • the service_role key, which bypasses row-level security. Keep it on your servers;
  • the JWT secret and the database connection string, for migrations and SQL clients.
import { createClient } from '@supabase/supabase-js'

const supabase = createClient('<project URL>', '<anon key>')

The keys do not change when the project is redeployed or resized.

Settings

Under Settings: where a confirmation link sends people, whether sign-up is open, how long a session lasts, and the mail server. Until a mail server is set, email confirmation is skipped - nobody could receive the link. Set one and turn confirmation back on before you open sign-up to the public.

Saving restarts the project's services. Its data and files are untouched.

Edge Functions

The Files tab opens the functions directory. Each folder is one function, served at /functions/v1/<folder>; its code is the index.ts inside. A hello function is there to start from. A function answers only requests that carry one of the project's keys or a signed-in user's token.

Extensions

pgvector, PostGIS and the other extensions on the platform's list are switched on from the Database tab. See Databases for the list.

What is not included

Supabase's log analytics is left out; each service's output is on the project's Logs tab instead. Database webhooks, which call out from inside the database, are not available.