Bỏ Supabase, dùng Laravel + PostgreSQL để tự chủ backend

Thay thế Supabase bằng Laravel + PostgreSQL: tự chủ backend cho sản phẩm dài hạn

Supabase rất hấp dẫn: tạo project nhanh, có PostgreSQL, auth, realtime, storage, dashboard, API tự sinh. Với MVP, đây là “đường tắt” cực tốt. Nhưng khi sản phẩm đi xa hơn — nhiều logic nghiệp vụ, yêu cầu bảo mật riêng, chi phí tăng, cần kiểm soát dữ liệu, cần tối ưu hạ tầng — đội ngũ thường bắt đầu hỏi: có nên tự chủ backend không?

Một lựa chọn thực tế: Laravel + PostgreSQL. Không phải vì Supabase “kém”, mà vì sản phẩm trưởng thành cần backend có chủ đích. Laravel giúp tổ chức nghiệp vụ rõ. PostgreSQL vẫn là lõi dữ liệu mạnh. Kết hợp này cho phép bạn giữ sức mạnh DB hiện đại, đồng thời lấy lại quyền kiểm soát tầng ứng dụng.

Vì sao nhiều team bắt đầu với Supabase?

Supabase thắng ở tốc độ.

Bạn có thể có:

– PostgreSQL managed – Auth sẵn dùng – REST/GraphQL API tự sinh – Realtime – Storage – Dashboard – Row Level Security – Edge Functions

Với founder, indie hacker, team nhỏ: quá tiện. Không cần dựng backend đầy đủ. Frontend gọi thẳng DB qua API Supabase. Tốc độ thử nghiệm → cao.

Nhưng chính điểm mạnh này cũng có mặt trái: logic dễ bị phân tán giữa frontend, SQL policy, trigger, function, edge function. Khi app lớn, việc hiểu “business rule nằm ở đâu” trở nên khó.

Khi nào nên cân nhắc rời Supabase?

Không cần rời Supabase quá sớm. Nhưng nên cân nhắc nếu gặp các dấu hiệu sau.

1. Logic nghiệp vụ ngày càng phức tạp

Ban đầu chỉ là CRUD. Sau đó xuất hiện:

– Gói subscription – Quyền theo vai trò, team, workspace – Workflow duyệt – Email transaction – Tính phí usage-based – Audit log – Webhook bên thứ ba – Retry job – Report phức tạp

Nếu phần lớn logic nằm trong frontend, trigger, RPC, policy → khó test, khó review, khó onboarding dev mới.

Laravel giúp gom nghiệp vụ vào:

– Controller – Service – Action – Job – Policy – Event/Listener – Form Request – Domain layer

Kết quả: code rõ hơn, test dễ hơn, thay đổi an toàn hơn.

2. Cần kiểm soát auth sâu hơn

Supabase Auth đủ tốt cho nhiều app. Nhưng sản phẩm dài hạn thường cần:

– Multi-tenant phức tạp – SSO/SAML – Impersonation cho support – Session policy riêng – Device management – Risk-based login – Custom password rule – Audit đăng nhập – Permission nhiều tầng

Laravel có hệ sinh thái mạnh:

– Laravel Sanctum cho SPA/mobile token – Laravel Passport cho OAuth2 – Socialite cho social login – Policies/Gates cho authorization – Package role/permission như spatie/laravel-permission

Bạn không bị giới hạn bởi mô hình auth có sẵn.

3. Chi phí tăng theo usage

Supabase giúp giảm chi phí ban đầu. Nhưng khi traffic tăng, storage tăng, realtime tăng, bandwidth tăng, compute tăng → hóa đơn có thể khó dự đoán.

Tự vận hành Laravel + PostgreSQL không luôn rẻ hơn. Nhưng bạn có nhiều lựa chọn hơn:

– VPS mạnh, chi phí cố định – Managed PostgreSQL riêng – Object storage riêng như S3/R2/MinIO – Queue worker scale độc lập – Cache Redis riêng – Read replica nếu cần

Điểm quan trọng: bạn kiểm soát kiến trúc chi phí.

4. Vendor lock-in bắt đầu đáng ngại

Dữ liệu trong PostgreSQL thì portable. Nhưng app phụ thuộc mạnh vào:

– Supabase Auth – Storage URL/signing – Realtime channel – RLS policy – Edge Functions – Client SDK behavior

…thì việc rời đi tốn công.

Laravel không xóa lock-in hoàn toàn, nhưng giảm phụ thuộc platform. Backend là code của bạn. DB là PostgreSQL chuẩn. Deploy ở đâu cũng được: VPS, Kubernetes, PaaS, bare metal, cloud.

Vì sao Laravel + PostgreSQL phù hợp cho dài hạn?

Laravel: backend “có khung xương”

Laravel không chỉ là framework PHP. Nó là bộ công cụ backend hoàn chỉnh:

– Routing rõ – ORM Eloquent dễ dùng – Migration/versioning DB – Queue/job mạnh – Scheduler built-in – Validation tốt – Event system tiện – Cache/session/mail/filesystem thống nhất – Testing tốt – Ecosystem lớn

Điểm mạnh nhất: Laravel ép bạn đưa logic vào backend có cấu trúc. Với sản phẩm lâu dài, đây là lợi thế lớn.

Ví dụ thay vì frontend gọi trực tiếp DB để tạo đơn hàng, bạn có thể có flow:

– Validate request – Check permission – Tính giá – Tạo order trong transaction – Trừ credit – Gửi email – Dispatch job – Ghi audit log – Trả response chuẩn

Tất cả nằm trong backend, test được, log được, rollback được.

PostgreSQL: giữ lại phần tốt nhất của Supabase

Supabase nổi bật vì dùng PostgreSQL. Khi chuyển sang Laravel, bạn vẫn giữ PostgreSQL:

– JSONB – Index mạnh – Full-text search – Transaction – Constraint – View/materialized view – Trigger nếu cần – Extension như pg_trgm, uuid-ossp, postgis

Khác biệt: DB không còn phải gánh quá nhiều vai trò API/auth/business logic. PostgreSQL trở về vai trò lõi: lưu trữ, ràng buộc, truy vấn hiệu quả.

Kiến trúc đề xuất

Một kiến trúc Laravel + PostgreSQL thực tế:

– Laravel API: xử lý business logic – PostgreSQL: dữ liệu chính – Redis: cache, queue, rate limit – Queue workers: email, webhook, xử lý nền – Scheduler: cron task – S3/R2/MinIO: file storage – Nginx/Caddy: reverse proxy – Docker: môi trường nhất quán – CI/CD: test, migrate, deploy – Monitoring: logs, metrics, alert

Frontend không gọi trực tiếp DB nữa. Frontend gọi API Laravel. Backend trở thành lớp kiểm soát trung tâm.

Mapping tính năng Supabase sang Laravel

Auth

Supabase Auth → Laravel Sanctum/Passport.

– SPA/mobile: Sanctum – OAuth2 server: Passport – Social login: Socialite – Role/permission: Spatie Permission – 2FA: Laravel Fortify hoặc custom

Database API

Supabase auto API → Laravel REST/JSON API.

Bạn tự định nghĩa endpoint:

– GET /api/projects – POST /api/orders – PATCH /api/users/{id} – POST /api/webhooks/stripe

Ít “magic” hơn, nhưng kiểm soát tốt hơn.

Row Level Security

RLS → Laravel Policies/Gates + query scope.

Ví dụ:

– User chỉ thấy project thuộc workspace mình – Admin có toàn quyền – Member chỉ xem tài nguyên được cấp

Có thể vẫn dùng RLS trong PostgreSQL cho lớp bảo vệ sâu hơn, nhưng không nên đặt toàn bộ business rule ở đó nếu team khó vận hành SQL policy.

Realtime

Supabase Realtime → Laravel Reverb, Pusher, Soketi, hoặc WebSocket server.

Nếu realtime chỉ là notification, status update, dashboard event → Laravel Broadcasting đủ tốt.

Storage

Supabase Storage → Laravel Filesystem.

Laravel hỗ trợ:

– Local – S3 – Cloudflare R2 – MinIO – DigitalOcean Spaces

Bạn tự kiểm soát signed URL, permission, lifecycle, CDN.

Edge Functions

Supabase Edge Functions → Laravel jobs, commands, queues, serverless tùy nhu cầu.

Phần lớn function nền nên chạy trong queue:

– Send email – Process image – Sync CRM – Retry webhook – Generate report

Chiến lược migration an toàn

Đừng “big bang rewrite” nếu sản phẩm đang chạy. Nên chuyển từng phần.

Bước 1: Audit phụ thuộc Supabase

Liệt kê:

– Bảng DB – Auth flow – RLS policy – Trigger/function – Storage bucket – Realtime channel – Edge functions – API frontend đang gọi

Mục tiêu: biết chính xác app đang phụ thuộc vào gì.

Bước 2: Giữ PostgreSQL schema càng nhiều càng tốt

Nếu DB schema ổn, không cần đập đi xây lại. Laravel migration có thể phản ánh schema hiện tại. Eloquent model mapping vào bảng cũ.

Cần chú ý:

– UUID primary key – Timestamp convention – Naming table/column – Relationship – Index – Constraint

Bước 3: Dựng Laravel API song song

Tạo Laravel backend mới, kết nối PostgreSQL clone/staging. Viết API cho các module quan trọng trước:

– Auth – User profile – Workspace/team – Billing – Core entity

Frontend có thể chuyển dần endpoint từ Supabase client sang Laravel API.

Bước 4: Di chuyển auth cẩn thận

Auth là phần nhạy cảm nhất. Có vài hướng:

– Bắt user reset password khi chuyển – Import user nếu hash tương thích – Dùng migration login: lần đăng nhập đầu xác minh qua Supabase, sau đó tạo credential mới – Duy trì Supabase Auth tạm thời, Laravel chỉ làm backend

Không nên vội nếu chưa có kế hoạch session/token rõ.

Bước 5: Thay storage/realtime sau cùng

Storage và realtime thường có nhiều edge case. Nên chuyển sau khi core API ổn.

Những trade-off cần chấp nhận

Laravel + PostgreSQL không phải thuốc thần.

Bạn sẽ phải tự lo:

– Deploy – Backup – Security patch – Scaling – Monitoring – Queue failure – DB tuning – Incident response

Supabase giúp bạn bỏ qua nhiều việc vận hành. Rời Supabase nghĩa là đổi tốc độ ban đầu lấy quyền kiểm soát dài hạn.

Vì vậy, nếu app còn nhỏ, chưa có doanh thu, logic đơn giản → cứ dùng Supabase. Nếu sản phẩm đã có khách hàng trả tiền, logic riêng nhiều, roadmap dài → Laravel + PostgreSQL đáng cân nhắc.

Kết luận thực tế

Supabase rất tốt để bắt đầu. Laravel + PostgreSQL rất tốt để đi đường dài.

Lựa chọn đúng không phải “công nghệ nào xịn hơn”, mà là giai đoạn sản phẩm cần gì. MVP cần tốc độ. Sản phẩm trưởng thành cần kiểm soát, testability, observability, portability, chi phí dự đoán hơn.

Nếu bạn đang thấy backend bắt đầu rối, policy khó hiểu, logic phân tán, chi phí tăng, auth không đủ linh hoạt — đó là tín hiệu nên thiết kế lại. Không nhất thiết rời Supabase ngay. Nhưng nên bắt đầu đưa business logic về backend riêng.

Cách khôn ngoan: migrate từng phần, giữ PostgreSQL, dựng Laravel API song song, chuyển module theo mức rủi ro.

Tự chủ backend không chỉ là chuyện kỹ thuật. Đó là quyền kiểm soát vận mệnh sản phẩm.