Thay Supabase bằng Render + Postgres: Backend rẻ hơn 70%

Thay thế Supabase bằng Render + Postgres: triển khai backend tiết kiệm chi phí

Supabase rất tiện: Postgres, Auth, Storage, Realtime, Edge Functions, dashboard đẹp. Nhưng khi sản phẩm bắt đầu có traffic thật, nhiều team gặp cùng bài toán: chi phí tăng, quota chạm trần, cần kiểm soát backend sâu hơn, hoặc muốn tách từng phần để tối ưu. Lúc đó, mô hình Render + Postgres là lựa chọn đáng cân nhắc: đơn giản hơn self-host, rẻ hơn nhiều stack “all-in-one”, vẫn đủ mạnh cho MVP, SaaS nhỏ, internal tool, API production vừa phải.

Ý tưởng chính: thay vì dùng Supabase như một nền tảng backend hoàn chỉnh, bạn triển khai API riêng trên Render, dùng Postgres managed của Render hoặc provider khác, rồi tự chọn auth, storage, queue, cache theo nhu cầu. Kết quả: ít lock-in hơn, chi phí rõ hơn, backend linh hoạt hơn.

Khi nào nên rời Supabase?

Không phải lúc nào cũng nên thay. Supabase tốt nếu bạn cần tốc độ build nhanh, realtime sẵn, auth sẵn, dashboard DB tiện. Nhưng Render + Postgres hợp lý khi:

– Bạn chủ yếu dùng Supabase làm DB + API đơn giản. – Không dùng nhiều Realtime/Storage/Edge Functions. – Auth cần tùy biến sâu: role phức tạp, multi-tenant, permission riêng. – Muốn backend chuẩn REST/GraphQL tự quản. – Muốn tối ưu chi phí theo tài nguyên thật. – Muốn kiểm soát migration, log, job nền, deployment pipeline.

Ví dụ: app quản lý bán hàng, CRM nội bộ, SaaS B2B nhỏ, marketplace nhỏ, dashboard analytics nhẹ. Các app này thường không cần toàn bộ bộ tính năng Supabase. Một API Node.js/NestJS/FastAPI/Rails + Postgres là đủ.

Kiến trúc đề xuất: Render + Postgres

Một kiến trúc gọn:

– Frontend: Vercel, Netlify, Render Static Site, Cloudflare Pages. – Backend API: Render Web Service. – Database: Render PostgreSQL hoặc Neon/Supabase Postgres riêng. – Auth: JWT tự triển khai, Auth.js, Clerk, Lucia, Keycloak tùy mức độ. – File storage: S3, Cloudflare R2, Backblaze B2. – Background jobs: Render Worker + Redis/queue. – Cron: Render Cron Jobs. – Logs/monitoring: Render logs + Sentry + OpenTelemetry nếu cần.

Điểm mạnh: mỗi phần độc lập. Cần scale API → tăng instance. Cần DB mạnh hơn → nâng plan DB. Cần storage rẻ → dùng R2. Không bị buộc dùng một nền tảng duy nhất.

Chi phí: vì sao có thể rẻ hơn?

Supabase gộp nhiều tiện ích trong một gói. Tốt cho tốc độ. Nhưng nếu bạn không dùng hết, bạn vẫn trả theo bundle/quota. Render cho phép trả theo service cụ thể.

Mô hình tiết kiệm thường gặp:

– API nhỏ chạy Render instance thấp. – Postgres managed ở plan phù hợp. – Storage chuyển sang R2/S3. – Auth tự quản hoặc dùng provider miễn phí/giá thấp. – Cron/job chạy riêng, không giữ server phụ nếu không cần.

Với MVP hoặc SaaS nhỏ, backend có thể bắt đầu bằng:

– 1 web service. – 1 Postgres instance. – 1 cron job nếu cần. – 1 bucket storage ngoài.

Chi phí dễ dự đoán hơn. Quan trọng nhất: không dùng gì → không trả phần đó.

Triển khai backend trên Render

Render hỗ trợ deploy từ GitHub/GitLab. Mô hình phổ biến:

1. Push code backend lên repo. 2. Tạo Web Service trên Render. 3. Chọn runtime: Node, Python, Go, Ruby, Docker. 4. Khai báo build command. 5. Khai báo start command. 6. Thêm biến môi trường. 7. Kết nối DB. 8. Deploy.

Ví dụ Node.js + Express:

npm install
npm run build
npm start

Render config thường cần:

– DATABASE_URL – JWT_SECRET – NODE_ENV=production – CORS_ORIGIN – PORT

Lưu ý: Render cấp port qua env. App phải listen theo:

const port = process.env.PORT || 3000
app.listen(port)

Nếu dùng Docker, kiểm soát môi trường tốt hơn, phù hợp production nghiêm túc. Nếu app đơn giản, native runtime đủ.

Thiết kế Postgres thay Supabase

Supabase dùng Postgres thật, nên migration sang Render Postgres tương đối thẳng nếu bạn không phụ thuộc nhiều vào Supabase-specific features.

Các bước chính:

1. Export schema/data từ Supabase. 2. Tạo Postgres DB trên Render. 3. Import data. 4. Cập nhật DATABASE_URL. 5. Chạy migration kiểm tra. 6. Chuyển API sang DB mới.

Có thể dùng:

pg_dump "$SUPABASE_DATABASE_URL" > backup.sql
psql "$RENDER_DATABASE_URL" < backup.sql

Với app production, không nên làm trực tiếp vội. Hãy tạo môi trường staging, import thử, chạy test, kiểm tra index, constraint, extension.

Cần chú ý:

– Extension Postgres có được hỗ trợ không. – Function/trigger có phụ thuộc Supabase không. – Row Level Security đang dùng thế nào. – Storage metadata có cần migrate không. – Realtime subscription có logic thay thế chưa.

Nếu trước đây frontend gọi thẳng Supabase client để query DB, bạn cần chuyển sang gọi API backend. Đây là thay đổi lớn nhất.

Auth: phần cần thay cẩn thận nhất

Supabase Auth là tiện. Khi rời Supabase, bạn cần chọn giải pháp.

Ba hướng phổ biến:

Tự triển khai JWT

Phù hợp app nhỏ, quyền đơn giản.

– Bảng users. – Password hash bằng bcrypt/argon2. – Login → trả access token + refresh token. – Middleware xác thực JWT. – Role/permission lưu DB.

Ưu: rẻ, kiểm soát cao. Nhược: phải tự xử lý bảo mật, reset password, email verify, session revoke.

Dùng Auth.js/Lucia

Phù hợp app web hiện đại. Tích hợp OAuth, session tốt hơn tự viết từ đầu.

Ưu: linh hoạt, open-source. Nhược: vẫn cần hiểu session/auth flow.

Dùng Clerk/Auth0/Cognito

Phù hợp production cần social login, MFA, org/team, audit.

Ưu: nhanh, bảo mật cao. Nhược: thêm chi phí, lock-in auth provider.

Nếu mục tiêu là tiết kiệm nhưng vẫn an toàn, chọn Auth.js/Lucia + Postgres là điểm cân bằng tốt.

Thay Supabase Storage bằng gì?

Nếu dùng Supabase Storage nhiều, chuyển sang object storage riêng.

Lựa chọn tốt:

– Cloudflare R2: rẻ, không egress fee kiểu AWS. – AWS S3: chuẩn ngành, tích hợp rộng. – Backblaze B2: giá tốt. – MinIO: self-host nếu muốn kiểm soát tối đa.

Backend nên tạo signed URL để upload/download. Không để frontend cầm secret key.

Flow chuẩn:

1. User gọi API xin upload URL. 2. API kiểm tra quyền. 3. API tạo signed URL. 4. Frontend upload trực tiếp lên storage. 5. API lưu metadata vào Postgres.

Cách này giảm tải backend, tiết kiệm băng thông, dễ scale.

Realtime: có thật sự cần?

Supabase Realtime là điểm mạnh. Nếu app dùng mạnh realtime, cần tính kỹ.

Thay thế:

– WebSocket server trên Render. – Socket.IO cho chat/notification. – Server-Sent Events cho stream một chiều. – Pusher/Ably nếu muốn managed realtime. – Polling nếu realtime không quá quan trọng.

Nhiều app tưởng cần realtime nhưng thực tế chỉ cần refresh mỗi 10-30 giây. Đừng over-engineer. Realtime managed có thể đắt; polling đơn giản đôi khi rẻ, ổn định, dễ debug.

Migration từ Supabase sang Render: lộ trình an toàn

Không nên “big bang” nếu app đã có user. Lộ trình khuyến nghị:

1. Audit dependency: đang dùng DB, Auth, Storage, Realtime, Edge Functions gì? 2. Tạo backend API mới: bọc mọi DB access sau API. 3. Chuyển frontend: từ Supabase client sang API client. 4. Mirror schema sang Render Postgres. 5. Import dữ liệu staging. 6. Test migration: auth, permission, query, performance. 7. Chạy song song ngắn hạn nếu cần. 8. Cutover vào giờ thấp điểm. 9. Giữ backup Supabase ít nhất vài tuần. 10. Theo dõi log/error/performance sau chuyển.

Điểm quan trọng: nếu frontend đang query trực tiếp Supabase với RLS, bạn phải thay bằng authorization ở backend. Đừng bỏ RLS mà không có permission layer thay thế.

Tối ưu chi phí sau khi chuyển

Render + Postgres chỉ rẻ nếu bạn vận hành đúng.

Checklist:

– Dùng connection pooling nếu traffic tăng. – Thêm index cho query chính. – Tránh N+1 query. – Cache dữ liệu ít đổi bằng Redis hoặc in-memory nếu phù hợp. – Tách worker khỏi web service. – Chạy cron theo lịch, không chạy loop vô hạn. – Theo dõi slow query. – Dọn file rác trong storage. – Chọn region gần user/DB. – Không over-provision DB quá sớm.

Chi phí backend thường phình vì DB query kém, storage không dọn, log quá nhiều, hoặc worker chạy sai. Tối ưu code trước khi nâng plan.

Hạn chế của Render + Postgres

Không có lựa chọn nào miễn phí tuyệt đối.

Nhược điểm:

– Bạn phải tự xây nhiều phần Supabase đã làm sẵn. – Auth/security cần hiểu đúng. – Dashboard quản trị không tiện bằng Supabase. – Realtime/storage phải ghép thêm dịch vụ. – Dev velocity ban đầu có thể chậm hơn. – Cần DevOps tối thiểu: env, migration, backup, monitoring.

Nếu team nhỏ, thiếu kinh nghiệm backend, Supabase vẫn có thể rẻ hơn theo nghĩa “tiết kiệm thời gian”. Chi phí kỹ thuật cũng là chi phí thật.

Kết luận: nên chọn theo mức độ kiểm soát cần thiết

Cách thực tế nhất: đừng rời Supabase chỉ vì “tự host nghe hay hơn”. Hãy rời khi bạn thấy rõ: đang trả cho tính năng không dùng, cần custom backend, cần tối ưu cost, hoặc cần giảm lock-in.

Với nhiều MVP và SaaS nhỏ, Render + Postgres là điểm cân bằng tốt: đủ đơn giản để deploy nhanh, đủ linh hoạt để scale, đủ rẻ để sống lâu qua giai đoạn đầu. Triển khai đúng → backend gọn, chi phí rõ, quyền kiểm soát cao hơn.