Tự xây backend thay Supabase: PostgreSQL, Auth, Storage miễn phí

Client App
  ↓
API Gateway / Backend
  ↓
PostgreSQL
  ↓
Auth Provider
  ↓
S3-compatible Storage

create table users (
  id uuid primary key,
  email text unique not null,
  display_name text,
  created_at timestamptz default now()
);

create table projects (
  id uuid primary key default gen_random_uuid(),
  owner_id uuid not null references users(id),
  name text not null,
  created_at timestamptz default now()
);

Client
  ↓ request upload URL
Backend
  ↓ tạo presigned URL
Object Storage

Flow tốt:

1. Client gọi backend xin upload.
2. Backend kiểm tra auth/quota/permission.
3. Backend tạo presigned URL.
4. Client upload trực tiếp lên storage.
5. Backend lưu metadata vào PostgreSQL.

Ví dụ bảng metadata:

create table files (
  id uuid primary key default gen_random_uuid(),
  owner_id uuid not null references users(id),
  bucket text not null,
  object_key text not null,
  mime_type text,
  size_bytes bigint,
  created_at timestamptz default now()
);

Ưu điểm:

– Backend không phải stream file lớn.
– Dễ kiểm soát quyền.
– Dễ audit.
– DB biết file thuộc user/project nào.

Public/private file

– File public → dùng CDN/cache.
– File private → luôn cấp signed URL ngắn hạn.
– Không để bucket private bị public nhầm.
– Không tin client gửi owner_id.

6. API layer: không nên bỏ qua

Supabase tiện vì tự sinh API. Nhưng khi tự xây, nên có backend rõ ràng. Lý do:

– Business logic phức tạp.
– Validation.
– Permission.
– Rate limit.
– Audit.
– Integration thanh toán/email/webhook.
– Không expose DB schema trực tiếp.

Stack gợi ý:

– NestJS + Prisma/Drizzle → TypeScript mạnh.
– FastAPI + SQLAlchemy → Python nhanh.
– Go + sqlc/ent → performance, deploy nhẹ.
– Django/Laravel → full-stack backend ổn định.

Pattern nên dùng:

Controller → Service → Repository/DB

Không bắt buộc quá enterprise, nhưng tách lớp giúp code sống lâu.

Validation

Luôn validate input:

– Type.
– Length.
– Format.
– Ownership.
– Business constraints.

Dùng:

– Zod / Valibot cho TypeScript.
– Pydantic cho Python.
– Joi / class-validator.
– Request schema trong OpenAPI.

7. Phân quyền: app-level hay RLS?

Supabase nổi bật nhờ Row Level Security. Tự xây có 2 hướng.

App-level authorization

Backend kiểm tra quyền trước khi query:

where: {
  id: projectId,
  ownerId: currentUser.id
}

Ưu:

– Dễ hiểu.
– Dễ debug.
– Phù hợp đa số app.

Nhược:

– Dev quên filter → leak data.
– Logic phân quyền rải rác.

PostgreSQL RLS

DB tự chặn row không hợp lệ.

Ưu:

– Bảo vệ tầng sâu.
– Hợp multi-tenant.
– Giảm rủi ro query sai.

Nhược:

– Khó debug.
– Cần quản lý DB role/session variable tốt.
– ORM đôi khi gây rối.

Thực tế: bắt đầu app-level. Nếu SaaS multi-tenant lớn → cân nhắc RLS cho bảng nhạy cảm.

8. Docker Compose mẫu tối giản

Một setup local:

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: app_password
      POSTGRES_DB: appdb
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

minio:
    image: minio/minio
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: minio
      MINIO_ROOT_PASSWORD: minio_password
    ports:
      - "9000:9000"
      - "9001:9001"
    volumes:
      - miniodata:/data

volumes:
  pgdata:
  miniodata:

Auth có thể thêm Keycloak:

keycloak:
    image: quay.io/keycloak/keycloak:25.0
    command: start-dev
    environment:
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: admin_password
    ports:
      - "8080:8080"

Production cần secret manager, TLS, backup, monitoring. Không dùng password mẫu.

9. Observability, bảo mật, vận hành

Backend tự xây → bạn chịu trách nhiệm vận hành.

Checklist tối thiểu:

– HTTPS bắt buộc.
– Secret không commit Git.
– Rate limit login/upload/API.
– Audit log hành động quan trọng.
– DB connection pool.
– Migration có rollback plan.
– Log structured JSON.
– Metrics: CPU, RAM, disk, DB connections, slow queries.
– Alert khi disk đầy, DB down, backup fail.
– Sentry/OpenTelemetry cho lỗi app.
– pg_stat_statements để xem query chậm.

Bảo mật file:

– Scan virus nếu user upload file công khai.
– Giới hạn size.
– Kiểm tra MIME thật, không chỉ tin header.
– Random object key.
– Không dùng filename gốc làm path trực tiếp.

10. Khi nào nên tự xây?

Nên tự xây nếu:

– Cần kiểm soát dữ liệu/hạ tầng.
– Chi phí Supabase tăng khó dự đoán.
– Cần auth/storage flow đặc thù.
– Có DevOps/backend đủ mạnh.
– Sản phẩm cần compliance riêng.
– Muốn tránh vendor lock-in.

Không nên nếu:

– MVP cần ra nhanh.
– Team không có người vận hành DB.
– Chưa rõ product-market fit.
– Auth/storage đơn giản.
– Downtime/backup chưa ai chịu trách nhiệm.

Một chiến lược tốt: bắt đầu với Supabase hoặc managed service, sau đó tách dần. Hoặc tự xây từ đầu nhưng dùng managed PostgreSQL/S3 để giảm gánh nặng.

Kết luận thực tế

Tự xây backend thay thế Supabase hoàn toàn khả thi. Lõi kỹ thuật không quá bí ẩn: PostgreSQL cho dữ liệu, Keycloak/Ory/Authentik hoặc auth tự code cho định danh, MinIO/S3 cho storage, backend API cho nghiệp vụ.

Nhưng cái khó không nằm ở việc chạy container. Cái khó là vận hành an toàn lâu dài: migration, backup, restore, monitoring, bảo mật, phân quyền, scale, incident response.

Nếu bạn cần tốc độ → Supabase rất đáng dùng. Nếu bạn cần tự chủ, tuỳ biến sâu, kiểm soát chi phí dài hạn → backend mã nguồn mở là hướng bền vững. Cách khôn ngoan nhất: xây theo từng lớp, giữ kiến trúc đơn giản, dùng chuẩn mở như PostgreSQL, OIDC, S3. Khi đó, dù không dùng Supabase, bạn vẫn có một nền tảng backend hiện đại, linh hoạt, dễ mở rộng.