When building a web application, you often need to quickly spin up a backend with authentication, database, and realtime updates. Supabase, an open-source platform built on PostgreSQL, covers these needs in one ecosystem. We have configured Supabase for dozens of projects—from startup MVPs to high-load services with millions of requests. In this article, we walk through a real configuration: schema, RLS, Edge Functions, and integration with React/Next.js. We'll share typical mistakes to avoid and a case study from a news feed service with realtime updates.
Why Supabase over Firebase?
| Criterion | Supabase | Firebase |
|---|---|---|
| License | Open source (Apache 2.0) | Proprietary |
| Database | PostgreSQL (relational, SQL) | Firestore (NoSQL, documents) |
| Realtime | WebSockets, PG notify | WebSockets with limits |
| Authentication | Built-in, OAuth, Magic Link | Firebase Auth |
| Storage | S3-compatible (MinIO) | Firebase Storage |
| Edge Functions | Deno (TypeScript) | Cloud Functions (Node.js) |
| Vendor lock-in | No (self-hosted possible) | High |
Supabase gives you full control: you can deploy it on your own servers or use the cloud version. This is critical for projects with data residency requirements.
Project Creation
Via dashboard.supabase.com—select region, set database password. For self-hosted:
git clone --depth 1 https://github.com/supabase/supabase cd supabase/docker cp .env.example .env # Edit .env: POSTGRES_PASSWORD, JWT_SECRET, ANON_KEY, SERVICE_ROLE_KEY docker compose up -d Client Setup and Type Generation
import { createClient } from '@supabase/supabase-js' import type { Database } from './database.types' export const supabase = createClient<Database>( process.env.NEXT_PUBLIC_SUPABASE_URL!, process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY! ) // For server-side operations—service role key export const supabaseAdmin = createClient<Database>( process.env.SUPABASE_URL!, process.env.SUPABASE_SERVICE_ROLE_KEY! ) Run npx supabase gen types typescript --project-id your-project-id > src/types/database.types.ts for autocompletion and type safety.
Schema and Row Level Security
-- Profiles table (extension of auth.users) CREATE TABLE profiles ( id uuid PRIMARY KEY REFERENCES auth.users ON DELETE CASCADE, username text UNIQUE, avatar_url text, bio text, updated_at timestamptz DEFAULT now() ); -- RLS—each user sees only their own ALTER TABLE profiles ENABLE ROW LEVEL SECURITY; CREATE POLICY "profiles_select_own" ON profiles FOR SELECT USING (auth.uid() = id); CREATE POLICY "profiles_update_own" ON profiles FOR UPDATE USING (auth.uid() = id); -- Public profiles—everyone can read CREATE POLICY "profiles_select_public" ON profiles FOR SELECT USING (true); -- Posts table with RLS CREATE TABLE posts ( id uuid PRIMARY KEY DEFAULT gen_random_uuid(), user_id uuid REFERENCES auth.users NOT NULL, title text NOT NULL, content text, is_public boolean DEFAULT false, created_at timestamptz DEFAULT now() ); ALTER TABLE posts ENABLE ROW LEVEL SECURITY; CREATE POLICY "posts_select_public_or_own" ON posts FOR SELECT USING ( is_public = true OR auth.uid() = user_id ); CREATE POLICY "posts_insert_own" ON posts FOR INSERT WITH CHECK (auth.uid() = user_id); CREATE POLICY "posts_update_own" ON posts FOR UPDATE USING (auth.uid() = user_id); CREATE POLICY "posts_delete_own" ON posts FOR DELETE USING (auth.uid() = user_id); How to Set Up Authentication and CRUD Operations
// Registration const { data, error } = await supabase.auth.signUp({ email: '[email protected]', password: 'password', options: { data: { username: 'john_doe' } } }) // OAuth (Google, GitHub, etc.) await supabase.auth.signInWithOAuth({ provider: 'google', options: { redirectTo: `${window.location.origin}/auth/callback` } }) // Insert with return const { data: post, error } = await supabase .from('posts') .insert({ title, content, user_id: user.id }) .select() .single() // Query with filters and JOIN const { data: posts } = await supabase .from('posts') .select(` id, title, created_at, profiles ( username, avatar_url ), tags ( name ) `) .eq('is_public', true) .order('created_at', { ascending: false }) .range(0, 23) // Full-text search (PostgreSQL tsquery) const { data } = await supabase .from('posts') .select('*') .textSearch('content', query, { config: 'russian', type: 'websearch' }) How to Set Up Realtime Subscriptions and Edge Functions
// Subscribe to new records const channel = supabase .channel('posts-feed') .on('postgres_changes', { event: 'INSERT', schema: 'public', table: 'posts', filter: 'is_public=eq.true' }, (payload) => { setPosts(prev => [payload.new as Post, ...prev]) }) .subscribe() // Edge Function: send-notification import { serve } from 'https://deno.land/[email protected]/http/server.ts' import { createClient } from 'https://esm.sh/@supabase/supabase-js@2' serve(async (req) => { const { userId, message } = await req.json() const supabase = createClient( Deno.env.get('SUPABASE_URL')!, Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')! ) await supabase .from('notifications') .insert({ user_id: userId, message }) return new Response(JSON.stringify({ ok: true }), { headers: { 'Content-Type': 'application/json' } }) }) Typical Mistakes When Configuring Supabase
- Duplicating RLS policies. Many developers create multiple policies for one table, leading to undefined behavior. A single policy per operation with correct conditions suffices.
- Missing indexes. Without indexes, queries filtering by
user_idoris_publiccan run tens of times slower. Add indexes on frequently used columns. - Ignoring database connections. In serverless environments, each new Supabase client creation opens a new connection. Use connection pooling or a client singleton.
How We Configure Supabase: Step-by-Step Process
- Analysis and schema design—We discuss requirements, design tables, indexes, and relationships.
- Authentication setup—We configure OAuth providers and create RLS policies.
- Frontend integration—We set up the client SDK and generate TypeScript types.
- Deploy and monitor—We deploy to cloud or self-hosted, configure backups, and document all decisions.
What's Included in Turnkey Setup
- Designed database schema with indexes and migrations.
- Ready RLS policies for data protection.
- Authentication integration (email/password, OAuth, Magic Link).
- Client code with TypeScript types (React, Vue, Next.js).
- Realtime subscriptions and Edge Functions for your use cases.
- API and access documentation.
- Team training on Supabase.
- 30-day free support warranty.
Estimated Timeline
| Phase | Duration |
|---|---|
| Analysis and design | 1–2 days |
| Authentication and RLS | 1–2 days |
| Frontend integration | 2–3 days |
| Deploy and testing | 1–2 days |
| Edge Functions and realtime (optional) | 2–3 days |
Full cycle takes 5–10 working days depending on complexity.
We have been working with Supabase since its early versions and have accumulated experience in query optimization, replication setup, and self-hosted deployment. Contact us for professional Supabase configuration—we will assess your project and propose the optimal solution.
Why RLS Is Critical for Security
Row Level Security (RLS) is not just a checkbox. Without RLS, any authenticated user could read or modify other users' data if no API-level restrictions exist. For example, in the news feed project, we implemented a policy that allows SELECT only for public posts or the user's own entries. This prevented private data leaks.
How we optimized queries on a real project?
In a project with 50,000 users and 500,000 posts, initial queries without indexes took 800 ms. After adding indexes on `user_id` and `is_public`, query time dropped to 12 ms. Edge Functions for notifications handled 200 requests per second under peak load. Infrastructure cost savings compared to Firebase amounted to 60%.







