Khi Supabase không còn phù hợp: checklist chọn nền tảng backend thay thế
Supabase rất mạnh: PostgreSQL, Auth, Storage, Realtime, Edge Functions, dashboard đẹp, DX tốt. Với MVP, SaaS nhỏ, app nội bộ, sản phẩm cần ra nhanh, Supabase thường là lựa chọn đáng giá.
Nhưng backend không chỉ là “chạy được”. Khi sản phẩm lớn lên, yêu cầu đổi: dữ liệu nhiều hơn, quy trình phức tạp hơn, compliance nặng hơn, chi phí khó đoán hơn, đội kỹ thuật cần quyền kiểm soát sâu hơn. Lúc này, câu hỏi không còn là “Supabase có tốt không?”, mà là: Supabase còn phù hợp với bài toán hiện tại không?
Bài viết này là checklist thực tế để biết khi nào nên rời Supabase, và chọn nền tảng backend thay thế ra sao.
Dấu hiệu Supabase bắt đầu không còn phù hợp
1. Logic nghiệp vụ vượt quá mức “backend đơn giản”
Supabase hợp khi logic nằm nhiều ở client, database policy, trigger, function nhỏ, Edge Function nhẹ. Nhưng nếu hệ thống bắt đầu có:
– Workflow nhiều bước
– Job chạy nền dài
– Queue, retry, dead-letter queue
– Xử lý file lớn, video, import/export dữ liệu
– Tích hợp nhiều hệ thống ngoài
– Saga transaction, event-driven architecture
– Rule nghiệp vụ thay đổi liên tục
Bạn sẽ thấy backend bị “vá” bằng PostgreSQL function, trigger, Edge Function, cron, webhook. Mỗi phần chạy được, nhưng tổng thể khó debug, khó test, khó quan sát.
Dấu hiệu rõ: dev ngại sửa logic vì không biết side effect nằm ở trigger, RLS policy, function hay client.
2. RLS trở thành gánh nặng thay vì lợi thế
Row Level Security là điểm mạnh lớn của Supabase. Nhưng RLS cũng có giá:
– Policy khó đọc khi nhiều role
– Debug lỗi permission mất thời gian
– Query bị ảnh hưởng hiệu năng vì policy phức tạp
– Business logic bị trộn với security logic
– Test phân quyền cần bộ test riêng
Với app đơn giản, RLS đẹp. Với enterprise app nhiều tenant, nhiều cấp quyền, nhiều exception, RLS có thể thành mê cung.
Checklist hỏi nhanh:
– Có bao nhiêu policy mỗi bảng?
– Có policy nào gọi function phức tạp không?
– Dev mới mất bao lâu hiểu quyền truy cập dữ liệu?
– Có test tự động cho permission không?
– Có trường hợp phải dùng service role để “lách” RLS thường xuyên không?
Nếu câu trả lời xấu, cân nhắc backend có authorization layer rõ hơn.
3. Chi phí và quota khó dự đoán
Supabase pricing ổn cho nhiều nhóm. Nhưng khi traffic, realtime, storage, egress, function invocation tăng, chi phí có thể khó dự báo. Đặc biệt với app có:
– Nhiều realtime subscription
– Nhiều file tải xuống
– Nhiều query nặng
– Nhiều môi trường staging/preview
– Nhu cầu backup, PITR, log retention dài
Không nên chờ hóa đơn tăng mới đánh giá. Backend tốt phải cho phép bạn dự báo chi phí theo đơn vị kinh doanh: user, workspace, project, request, GB, job.
Câu hỏi cần có số:
– Chi phí mỗi 1.000 active users?
– Chi phí mỗi tenant lớn?
– Chi phí egress mỗi tháng?
– Query nào đắt nhất?
– Realtime channel nào tốn nhất?
– Có giới hạn nào nếu tăng 10x traffic?
Không trả lời được, rủi ro vận hành tăng.
4. Nhu cầu kiểm soát hạ tầng cao hơn
Supabase managed giúp giảm ops. Nhưng một số đội cần kiểm soát sâu:
– VPC riêng
– Private networking
– Region cụ thể
– Multi-region active-active
– Custom backup policy
– Custom Postgres extension
– Audit log đầy đủ
– Data residency nghiêm ngặt
– On-premise hoặc self-host bắt buộc
Supabase có self-host, nhưng tự vận hành Supabase không giống dùng managed. Bạn phải lo upgrade, security, observability, backup, scaling. Nếu đã cần tự vận hành mạnh, đôi khi chọn stack backend khác rõ ràng hơn.
Checklist chọn nền tảng backend thay thế
1. Xác định kiểu backend thật sự cần
Đừng chọn công cụ trước. Chọn mô hình trước.
Backend-as-a-Service hợp khi:
– Team nhỏ
– Cần ra nhanh
– Logic đơn giản đến trung bình
– Không muốn vận hành server nhiều
Ví dụ: Firebase, Appwrite, Nhost, PocketBase.
Framework backend truyền thống hợp khi:
– Logic nghiệp vụ phức tạp
– Cần test, module, domain rõ
– Cần kiểm soát API và auth sâu
Ví dụ: NestJS, Django, Laravel, Rails, FastAPI, Spring Boot.
Platform serverless hợp khi:
– Workload biến động
– API/job độc lập
– Muốn scale từng function
Ví dụ: AWS Lambda, Cloudflare Workers, Vercel Functions, Google Cloud Run.
Managed platform + database hợp khi:
– Muốn quyền kiểm soát cao
– Vẫn muốn giảm ops
– Cần kiến trúc dài hạn
Ví dụ: PostgreSQL managed + backend riêng trên Fly.io, Render, Railway, AWS, GCP, Azure.
2. Kiểm tra database: dữ liệu trước, framework sau
Supabase gắn chặt với PostgreSQL. Nếu dữ liệu quan hệ là lõi sản phẩm, hãy ưu tiên nền tảng hỗ trợ PostgreSQL tốt.
Checklist database:
– Có transaction mạnh không?
– Có migration chuẩn không?
– Có backup tự động không?
– Có point-in-time recovery không?
– Có read replica không?
– Có connection pooling không?
– Có giới hạn connection rõ không?
– Có hỗ trợ full-text search, vector, JSONB, extension cần dùng không?
– Có cách debug query chậm không?
– Có export dữ liệu dễ không?
Nếu nền tảng thay thế làm bạn mất quyền kiểm soát dữ liệu, coi chừng. Dữ liệu khó migrate hơn code.
3. Đánh giá authentication và authorization
Supabase Auth đủ tốt cho nhiều app. Khi thay thế, đừng đánh giá auth qua màn hình login. Hãy xem vòng đời identity đầy đủ.
Checklist Auth:
– Email/password, OAuth, SSO, SAML có không?
– MFA có không?
– Session, refresh token xử lý sao?
– User deletion, GDPR export có không?
– Organization, team, role có sẵn không?
– Impersonation admin có an toàn không?
– Audit log auth có không?
– Có hỗ trợ service account/API key không?
– Có phân quyền theo resource không?
Với B2B SaaS, cần đặc biệt chú ý multi-tenant authorization. Nhiều nền tảng có login tốt nhưng phân quyền tenant yếu. Khi đó bạn vẫn phải tự xây.
4. Xem năng lực chạy background jobs
Nhiều sản phẩm vỡ vì backend chỉ giỏi request/response, không giỏi job nền.
Cần kiểm tra:
– Queue native hay cần dịch vụ ngoài?
– Retry có cấu hình không?
– Job timeout bao lâu?
– Có delayed job không?
– Có scheduled job không?
– Có dead-letter queue không?
– Có idempotency support không?
– Có dashboard xem job lỗi không?
– Có giới hạn payload không?
– Có chạy worker riêng được không?
Nếu app có thanh toán, email, webhook, AI processing, import CSV, sync CRM, job system là lõi. Đừng xem như phụ.
5. Quan sát hệ thống: log, metric, trace
Backend thay thế phải dễ vận hành lúc có sự cố. Dashboard đẹp không đủ.
Checklist observability:
– Log có search tốt không?
– Log retention bao lâu?
– Có structured logs không?
– Có request ID/correlation ID không?
– Có metric CPU, memory, DB, queue không?
– Có distributed tracing không?
– Có alert theo error rate, latency, saturation không?
– Có audit log cho thao tác admin không?
– Có tích hợp Datadog, Grafana, Sentry, OpenTelemetry không?
Nếu production lỗi mà chỉ có “function failed”, team sẽ tốn nhiều đêm.
6. Kiểm tra deploy, môi trường, quy trình dev
Nền tảng tốt phải hợp workflow team.
Checklist DX/DevOps:
– Có local development tốt không?
– Có preview environment theo pull request không?
– Có migration chạy CI/CD không?
– Có rollback không?
– Có secrets management không?
– Có staging giống production không?
– Có seed data/test data không?
– Có type generation không?
– Có SDK ổn định không?
– Có lock-in nặng không?
Supabase rất mạnh ở DX. Nền tảng thay thế phải bù được điểm này, nếu không năng suất team giảm.
So sánh hướng thay thế phổ biến
Firebase
Hợp: mobile app, realtime, MVP nhanh, ecosystem Google.
Cẩn thận: NoSQL data modeling, query limitation, cost egress/read, vendor lock-in, migration khó nếu model sai.
Chọn Firebase nếu realtime/mobile là lõi và team chấp nhận Firestore model.
Appwrite hoặc Nhost
Hợp: muốn BaaS gần Supabase, open-source, dễ dựng.
Cẩn thận: ecosystem nhỏ hơn, maturity tùy workload, cần test scale thật.
Chọn nếu muốn chuyển nhẹ, không muốn tự xây backend đầy đủ.
Backend riêng với NestJS/Django/Laravel/Rails
Hợp: nghiệp vụ phức tạp, team backend mạnh, cần kiểm soát.
Cẩn thận: cần ops, security, scaling, auth, storage, job, monitoring tự thiết kế.
Chọn nếu logic sản phẩm là lợi thế cạnh tranh và cần kiến trúc rõ.
Cloud Run, Lambda, Workers
Hợp: scale linh hoạt, microservice, event-driven, API độc lập.
Cẩn thận: cold start, timeout, local dev, observability, distributed complexity.
Chọn nếu workload tách được thành service nhỏ, team quen cloud.
Managed Postgres + backend trên Render/Fly/Railway
Hợp: muốn đơn giản hơn AWS nhưng kiểm soát hơn BaaS.
Cẩn thận: giới hạn platform, network, scaling, backup cần đọc kỹ.
Chọn nếu muốn bước chuyển cân bằng: giữ PostgreSQL, thêm backend riêng.
Checklist quyết định cuối cùng
Trước khi rời Supabase, trả lời bằng văn bản:
1. Lý do rời là gì? Chi phí, hiệu năng, compliance, logic, lock-in, team skill?
2. Vấn đề có thể giải bằng tối ưu Supabase không? Index, query rewrite, RLS cleanup, plan upgrade, queue ngoài?
3. Dữ liệu migrate ra sao? Schema, auth users, files, policies, realtime logic?
4. Downtime chấp nhận bao lâu?
5. Ai sở hữu vận hành sau migration?
6. Nền tảng mới tốt hơn Supabase ở điểm nào, kém hơn ở điểm nào?
7. Chi phí 12 tháng sau khi scale 3x là bao nhiêu?
8. Kế hoạch rollback có không?
9. Có proof of concept với workload thật chưa?
10. Team có đủ kỹ năng duy trì stack mới không?
Nếu chưa có câu trả lời rõ, chưa nên migrate.
Kết luận thực tế
Supabase không “tệ” khi bạn muốn rời nó. Thường là sản phẩm đã lớn hơn giả định ban đầu. Công cụ giúp bạn đi nhanh ở giai đoạn 0–1 có thể không còn tối ưu ở giai đoạn 1–10.
Quyết định đúng không phải là chọn nền tảng nổi tiếng nhất. Quyết định đúng là chọn backend khớp với dữ liệu, logic nghiệp vụ, yêu cầu vận hành, năng lực team và chi phí dài hạn.
Cách làm khôn: đừng migration toàn bộ trong một lần. Tách phần đau nhất trước: background jobs, API nghiệp vụ, auth enterprise, reporting, hoặc file processing. Giữ PostgreSQL nếu còn phù hợp. Đo hiệu quả bằng latency, error rate, chi phí, thời gian deploy, thời gian debug.
Backend tốt không phải backend không bao giờ cần đổi. Backend tốt là backend cho phép sản phẩm tiếp tục lớn lên mà team vẫn hiểu, vận hành được, và ngủ được.