Supabase Interview — So sánh, Best Practices, Q&A

So sánh Supabase vs các giải pháp khác

Supabase vs Firebase

Supabase vs Neon

Supabase vs PlanetScale

So sánh tổng hợp 5 nền tảng

Best Practices cho Supabase

Database

• Dùng Supavisor transaction mode cho serverless apps (Next.js, Nuxt, Lambda) -- mỗi request là một transaction riêng, không giữ connection
• Migration-based workflow: supabase migration new -> chỉnh sửa SQL -> supabase db push. Không sửa schema trực tiếp trên production
• Type generation: supabase gen types typescript để có type-safe queries -- phát hiện lỗi schema mismatch ngay khi compile
• Sử dụng computed columns và database views thay vì duplicate logic ở client -- giữ business logic gần data
• Backup Storage objects riêng -- backup của Supabase chỉ cover database, không cover Storage files
• Tạo indexes cho tất cả columns dùng trong WHERE, JOIN, ORDER BY
• Dùng pg_stat_statements để phân tích slow queries
• Read Replicas cho read-heavy workloads (Pro plan add-on)

Authentication

• Dùng Magic Link hoặc OAuth thay vì password khi có thể -- bảo mật hơn, UX tốt hơn, không cần quản lý password
• MFA (TOTP) cho ứng dụng nhạy cảm (finance, healthcare)
• Auth Hooks để customize flow mà không cần tự host GoTrue -- gửi email tùy chỉnh, thêm claims vào JWT
• onAuthStateChange() để sync auth state với UI -- handle SIGNED_IN, SIGNED_OUT, TOKEN_REFRESHED events
• Custom SMTP cho transactional emails -- tránh spam filters, tăng deliverability
• CAPTCHA (Turnstile) cho auth endpoints để chống bot

Realtime

• Enable RLS trên bảng subscribed để user chỉ nhận events họ được phép xem
• Dùng Broadcast cho ephemeral data (cursor positions, typing indicators) -- không cần persist
• Dùng Presence cho online status tracking -- tự động sync, tự động clean up khi disconnect
• Rate limiting: Free 2 msg/s, Pro 5 msg/s -- thiết kế app không spam quá rate limit

Edge Functions

• Không bao giờ expose service role key ra client -- nó bypass RLS hoàn toàn
• Dùng Secrets manager (supabase secrets set) thay vì hardcode API keys trong code
• Background Tasks và Queues cho long-running jobs -- Edge Functions có timeout (dưới 10 phút)
• CORS cần được handle trong function nếu gọi từ browser
• Error handling: trả về meaningful HTTP status codes, không leak internal errors
• Logging: dùng console.log / console.error trong function, logs sẽ hiển thị trong Dashboard

Security

• Luôn enable RLS cho tất cả public tables -- đây là lớp bảo mật quan trọng nhất
• Revoke unnecessary grants -- mặc định grants có thể quá rộng
• Dùng Column Level Security cho dữ liệu nhạy cảm (email, phone)
• CAPTCHA (Turnstile) cho auth endpoints
• Custom SMTP cho transactional emails (tránh spam filters)
• Rate limiting trên auth endpoints qua Kong gateway config
• SSL enforcement bắt buộc trên production

Performance

• Dùng connection pooling (Supavisor transaction mode) -- luôn dùng cho serverless
• Indexes: Tạo index cho columns dùng trong WHERE, JOIN, ORDER BY
• pg_stat_statements: Phân tích top slow queries
• EXPLAIN ANALYZE: Test query performance trước khi deploy
• Read Replicas: Phân tán read load (Pro plan add-on)
• Caching: Storage CDN cache cho static files, Edge Function response caching
• Compute sizing: Chọn compute phù hợp -- đừng dùng Micro cho production AI workloads

Development Workflow

# 1. Khởi tạo local project
supabase init

# 2. Start local development (cần Docker)
supabase start

# 3. Tạo migration cho thay đổi schema
supabase migration new add_users_table

# 4. Code và test local
supabase functions serve

# 5. Generate TypeScript types từ schema local
supabase gen types typescript --local > types/supabase.ts

# 6. Push lên production
supabase db push
supabase functions deploy my-function

15+ Câu hỏi phỏng vấn Supabase

Cơ bản

1. Supabase là gì? Khác Firebase ở điểm nào?

Supabase là open-source Backend-as-a-Service (BaaS) xây dựng trên nền PostgreSQL. Nó cung cấp database, authentication, storage, realtime, edge functions, và AI/vector capabilities -- tất cả tích hợp chặt chẽ với nhau.

Khác biệt cốt lõi với Firebase:

• Database: PostgreSQL (SQL quan hệ, JOINs, transactions, constraints, 70+ extensions) vs Firestore (NoSQL document, limited query, no JOINs)
• Open-source: Toàn bộ stack của Supabase là open-source, có thể self-host. Firebase hoàn toàn proprietary
• Vendor lock-in: Supabase dùng PostgreSQL chuẩn -- bạn có thể migrate sang bất kỳ Postgres provider nào. Firebase lock-in Google Cloud
• API: Supabase auto-generate REST + GraphQL từ schema. Firebase cần viết Cloud Functions hoặc dùng Firestore SDK
• Pricing: Supabase tính theo MAU + storage, Firebase tính theo operations (reads/writes/deletes)

2. RLS trong Supabase hoạt động như thế nào?

Row Level Security (RLS) là cơ chế bảo mật ở cấp hàng dữ liệu trong PostgreSQL. Nó cho phép bạn định nghĩa policies để kiểm soát user nào được đọc/ghi hàng nào.

Cách hoạt động:

1. User login -> Supabase Auth tạo JWT chứa sub (user ID) và role
2. Client gửi request kèm JWT trong Authorization header
3. PostgREST set auth.uid() = user ID từ JWT, auth.role() = role từ JWT
4. PostgreSQL kiểm tra RLS policies trước khi thực thi query
5. Nếu policy không cho phép -> row bị lọc khỏi kết quả (SELECT) hoặc query bị reject (INSERT/UPDATE/DELETE)

-- Ví dụ: user chỉ xem được post của chính mình
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can view own posts"
ON posts FOR SELECT
USING (auth.uid() = user_id);

-- Policy cho insert: user chỉ tạo post với user_id của chính mình
CREATE POLICY "Users can create own posts"
ON posts FOR INSERT
WITH CHECK (auth.uid() = user_id);

3. Làm thế nào để bảo vệ API key khi gọi OpenAI từ frontend?

Không bao giờ gọi OpenAI trực tiếp từ frontend. API key sẽ bị expose trong network tab.

Giải pháp đúng: Dùng Edge Function làm proxy:

// supabase/functions/chat/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2'

const OPENAI_API_KEY = Deno.env.get('OPENAI_API_KEY')! // Secret, không expose

Deno.serve(async (req: Request) => {
  const { message } = await req.json()

  // Verify user authentication
  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )
  const token = req.headers.get('Authorization')?.replace('Bearer ', '')
  const { data: { user }, error } = await supabase.auth.getUser(token)
  if (error || !user) {
    return new Response('Unauthorized', { status: 401 })
  }

  // Gọi OpenAI với API key từ secrets
  const response = await fetch('https://api.openai.com/v1/chat/completions', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${OPENAI_API_KEY}`
    },
    body: JSON.stringify({
      model: 'gpt-4o',
      messages: [{ role: 'user', content: message }]
    })
  })

  const data = await response.json()
  return new Response(JSON.stringify(data), {
    headers: { 'Content-Type': 'application/json' }
  })
})

4. Postgres Changes (CDC) hoạt động thế nào?

Postgres Changes dùng logical replication của PostgreSQL (WAL -- Write-Ahead Log):

1. Khi có INSERT/UPDATE/DELETE, PostgreSQL ghi thay đổi vào WAL
2. Publication supabase_realtime lắng nghe WAL cho các bảng được đăng ký
3. Supabase Realtime server đọc WAL records và broadcast qua WebSocket đến subscribed clients
4. Client nhận payload với eventType, new (row mới), old (row cũ -- cho UPDATE/DELETE)

-- Đăng ký bảng vào realtime publication
ALTER PUBLICATION supabase_realtime ADD TABLE messages;

// Client subscribe
supabase.channel('db-changes')
  .on('postgres_changes',
    { event: 'INSERT', schema: 'public', table: 'messages' },
    (payload) => console.log('New message:', payload.new)
  )
  .subscribe()

5. Khi nào dùng Broadcast vs Presence vs Postgres Changes?

Nguyên tắc chọn:

• Nếu dữ liệu cần lưu lại -> Postgres Changes
• Nếu dữ liệu là tạm thời, cần low latency -> Broadcast
• Nếu cần biết ai đang online -> Presence

Trung cấp

6. Supabase Auth flow: sign up -> email verify -> JWT -> RLS

Toàn bộ flow auth trong Supabase:

1. Sign Up: User gửi email + password -> GoTrue tạo user trong auth.users (status: unconfirmed)
2. Email Verify: GoTrue gửi email xác nhận (qua SMTP của bạn hoặc Supabase default) -> User click link -> status chuyển thành confirmed
3. Sign In: User gửi email + password -> GoTrue verify -> Tạo JWT với claims: sub (user UUID), role (authenticated), email, aud
4. Client lưu JWT: localStorage (web) hoặc secure storage (mobile). Supabase client tự động attach JWT vào mọi request
5. API Request: Client gọi supabase.from('posts').select() -> JWT gửi trong Authorization: Bearer [JWT]
6. PostgREST: Set auth.uid() = sub từ JWT, auth.role() = role từ JWT
7. RLS Check: PostgreSQL check policies dùng auth.uid() -> chỉ trả về rows user được phép xem

7. Supavisor session mode vs transaction mode?

Khuyến nghị:

• Serverless (Next.js, Nuxt, Lambda): Dùng transaction mode -- mỗi request là một transaction, pool hiệu quả hơn
• Long-running apps (Express, traditional servers): Dùng session mode nếu cần prepared statements hoặc advisory locks
• Direct connection (port 5432): Cho ORMs, database tools, migrations

8. Làm sao migrate từ Firebase sang Supabase?

Quy trình migration Firebase -> Supabase gồm 3 phần:

1. Auth Migration:

# Export Firebase users (bao gồm password hash parameters)
node firestoreusers2json.js users.json 100

# Import vào Supabase Auth (giữ nguyên password hash)
node import_users.js users.json 100

• Giữ Firebase password hash parameters (scrypt config) để user không cần reset password
• Map Firebase UID sang Supabase auth.users.id

2. Firestore Migration:

• Export Firestore collections ra JSON
• Thiết kế lại schema -- "flatten" nested documents thành relational tables với foreign keys
• Import vào Postgres bằng script json2supabase.js
• Ví dụ: posts/{postId}/comments/{commentId} -> bảng posts và bảng comments với post_id FK

3. Storage Migration:

• Download files từ Firebase Storage -> Upload lên Supabase Storage
• Map metadata và access controls sang RLS policies

9. Edge Functions vs traditional backend?

Quy tắc chọn:

• Edge Functions: webhook receivers, API key proxying (OpenAI, Stripe), lightweight transforms, sending emails
• Traditional backend: complex workflows, long-running jobs (video processing), stateful sessions, legacy integrations

10. pgvector trong Supabase dùng cho gì?

pgvector là PostgreSQL extension cho phép lưu và query vector embeddings ngay trong database:

Use cases chính:

• Semantic Search: Tìm kiếm theo ý nghĩa, không phải keyword chính xác (FAQ, documentation)
• RAG (Retrieval Augmented Generation): Cung cấp context cho LLM từ knowledge base
• Recommendations: Gợi ý sản phẩm/bài viết tương tự dựa trên embeddings
• Image/Video Search: Tìm kiếm đa phương tiện bằng vector similarity
• Anomaly Detection: Phát hiện bất thường bằng distance metrics

-- Tạo bảng với vector column
CREATE TABLE documents (
  id BIGSERIAL PRIMARY KEY,
  content TEXT,
  embedding VECTOR(1536) -- OpenAI ada-002 embedding dimension
);

-- Tạo HNSW index cho fast approximate search
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

-- Similarity search
SELECT content, 1 - (embedding <=> query_embedding) AS similarity
FROM documents
ORDER BY embedding <=> query_embedding
LIMIT 5;

Nâng cao

11. Tại sao nên dùng Supabase thay vì tự build backend?

Supabase phù hợp khi:

• Team nhỏ (1-5 developers), muốn ship nhanh -- không có thời gian build auth, storage, realtime từ đầu
• MVP/POC: Cần validate idea trong vài ngày/tuần -- Supabase cho phép có full backend trong vài giờ
• PostgreSQL là lựa chọn đúng: Bạn cần SQL quan hệ, không phải NoSQL
• Cần auth + database tích hợp chặt: RLS + JWT = authorization tự động không cần viết middleware
• Dự án open-source hoặc muốn tránh vendor lock-in
• Cần realtime capabilities: Postgres Changes, Broadcast, Presence có sẵn

Không nên dùng Supabase khi:

• Cần kiểm soát hoàn toàn infrastructure và kiến trúc
• Có team backend mạnh, đã có sẵn boilerplate/auth system
• Yêu cầu compliance đặc thù không được Supabase hỗ trợ
• High-frequency trading hoặc systems cần microsecond latency

12. Storage trong Supabase có gì đặc biệt?

• S3-compatible API: Tương thích với mọi S3 client library
• RLS tích hợp: Cùng cơ chế bảo mật với database -- storage.objects policies
• CDN toàn cầu: Phục vụ file từ 285+ thành phố
• Image Transformation: Resize, compress, format conversion qua URL parameters (không cần xử lý server-side)
• TUS Resumable Uploads: Upload file lớn với pause/resume
• Signed URLs: Temporary access links với expiration
• Metadata trong Postgres: Mọi file metadata được lưu trong bảng storage.objects, có thể JOIN với data khác

13. Supabase có scale được không?

Có. Supabase scale theo nhiều chiều:

• Vertical scaling: Compute add-ons từ Micro (2-core, 1GB) đến 16XL (64-core, 256GB)
• Horizontal scaling (reads): Read Replicas trên Pro plan
• Connection pooling: Supavisor quản lý hàng nghìn connections hiệu quả
• Edge Functions: Tự động scale theo request volume trên edge network toàn cầu
• Storage CDN: File được cache và phục vụ từ edge gần user nhất
• Disk: General Purpose lên đến 16TB, High Performance lên đến 80,000 IOPS

Giới hạn cần lưu ý:

• PostgreSQL là single-writer -- write throughput có giới hạn
• Realtime connections: Free 200, Pro 500 concurrent (có thể tăng)
• Edge Functions timeout (vài phút) -- không phù hợp cho long-running jobs

14. Self-host vs Managed -- pros/cons?

15. Khi nào KHÔNG nên dùng Supabase?

1. Bạn cần NoSQL: Dữ liệu unstructured, schema thay đổi liên tục, không cần JOINs/transactions -> Firebase hoặc MongoDB phù hợp hơn
2. High-frequency trading / Gaming server: Cần microsecond latency, in-memory state -> Dùng Redis, custom C++/Rust server
3. Đã có team backend mạnh + hệ thống auth/storage sẵn: Không cần BaaS -> chỉ dùng PostgreSQL managed service (RDS, Neon)
4. Yêu cầu compliance đặc thù: On-premise only, air-gapped networks, FIPS 140-2 -> Cần enterprise solutions
5. Cần push notifications (FCM/APNs): Supabase không có push notification service -> Cần Firebase Cloud Messaging hoặc third-party
6. Time-series data ở scale lớn: PostgreSQL có thể handle, nhưng TimescaleDB hoặc InfluxDB tối ưu hơn
7. Cần full-text search engine cấp enterprise: PostgreSQL full-text search tốt nhưng không bằng Elasticsearch/Algolia cho scale rất lớn
8. Budget siêu hạn chế + traffic cao: Firebase pricing có thể rẻ hơn cho app có nhiều reads nhưng ít users do tính theo operations