Supabase alternative rẻ hơn: cách giảm chi phí backend khi app tăng người dùng
App mới ra mắt thường vui vì “chạy được”, chưa đau vì “chạy tốn”. Supabase rất tốt cho MVP: Postgres, Auth, Realtime, Storage, Edge Functions, dashboard đẹp. Nhưng khi app tăng người dùng, chi phí backend có thể tăng nhanh: database phình, egress nhiều, realtime nhiều kết nối, storage lớn, function gọi dày, log nhiều.
Vấn đề không phải “Supabase đắt” hay “không nên dùng Supabase”. Vấn đề là: mỗi giai đoạn app cần kiến trúc chi phí khác nhau. MVP cần tốc độ. App tăng trưởng cần tối ưu. App lớn cần kiểm soát hạ tầng.
Bài này đi thẳng vào cách chọn Supabase alternative rẻ hơn, khi nào nên đổi, và cách giảm chi phí backend mà không phá app.
Vì sao chi phí Supabase tăng khi app nhiều người dùng?
Supabase gom nhiều dịch vụ tiện: database, auth, storage, realtime, API, edge. Tiện nghĩa là bạn trả tiền cho tính tiện đó. Khi traffic tăng, vài khoản sau dễ thành “điểm đau”.
Database compute
Postgres cần CPU, RAM, IOPS. Query chậm làm máy cần mạnh hơn. Bảng không index làm đọc nhiều. Join nặng làm CPU tăng. Connection nhiều làm Postgres nghẹt.
Nguyên nhân: app tăng user nhưng schema/query vẫn kiểu MVP.
Cách giảm: tối ưu query trước khi nâng plan.
– Thêm index đúng chỗ.
– Dùng EXPLAIN ANALYZE.
– Tránh select *.
– Phân trang bằng cursor thay vì offset lớn.
– Tách bảng nóng/lạnh.
– Cache dữ liệu ít đổi.
Egress và Storage
Ảnh, video, file tải nhiều tạo egress. Storage rẻ lúc đầu, nhưng bandwidth mới đáng sợ.
Nguyên nhân: dùng backend làm nơi phát file trực tiếp.
Cách giảm: đưa file sang object storage + CDN.
– Cloudflare R2: không phí egress về Cloudflare.
– Backblaze B2: rẻ, hợp backup/file.
– S3-compatible storage: dễ đổi nhà cung cấp.
– Image proxy/CDN: resize ảnh trước khi gửi.
Realtime
Realtime hay nhưng tốn nếu lạm dụng. Mỗi user giữ connection. Mỗi thay đổi broadcast nhiều client. Chat, presence, dashboard live đều ăn tài nguyên.
Nguyên nhân: dùng realtime cho dữ liệu không cần realtime.
Cách giảm: chỉ realtime phần cần live.
– Notification quan trọng: realtime.
– Feed, profile, setting: polling/cache.
– Presence: giới hạn room.
– Broadcast: gom event, debounce.
Edge Functions và API
Function tiện cho logic nhỏ. Nhưng nếu chạy nhiều request, gọi external API, xử lý ảnh, job nền, chi phí tăng.
Nguyên nhân: nhét cả backend vào serverless function.
Cách giảm: tách workload.
– Request ngắn: function.
– Job dài: queue + worker.
– Xử lý ảnh/video: service riêng.
– Cron nặng: worker trên VPS.
Khi nào nên tìm Supabase alternative?
Đừng đổi chỉ vì “nghe rẻ hơn”. Đổi backend tốn thời gian, rủi ro, bug. Nên cân khi có dấu hiệu rõ.
Nên ở lại Supabase nếu
– App còn MVP hoặc tiền doanh thu chưa rõ.
– Team nhỏ, cần ship nhanh.
– Chi phí backend vẫn dưới mức chấp nhận.
– Chưa tối ưu query, cache, storage.
– Chưa biết phần nào gây tốn.
Hành động: đo chi phí trước, tối ưu trước.
Nên cân alternative nếu
– Chi phí tăng nhanh hơn doanh thu.
– Database cần cấu hình sâu hơn.
– Realtime/storage/egress là chi phí chính.
– Có kỹ năng DevOps cơ bản.
– App đã ổn định, ít thay đổi schema lớn.
– Cần tự host để kiểm soát vùng dữ liệu, backup, logging.
Hành động: tách từng phần, không migrate toàn bộ một lần.
Các Supabase alternative rẻ hơn đáng cân
Không có lựa chọn “rẻ nhất cho mọi app”. Có lựa chọn hợp workload.
1. Self-host Postgres + backend trên VPS
Mô hình cổ điển: thuê VPS, cài Postgres, backend API, Redis, worker. Nhà cung cấp: Hetzner, Contabo, DigitalOcean, Vultr, Linode, AWS Lightsail.
Hợp với:
– App CRUD nhiều.
– Traffic vừa.
– Team biết deploy.
– Muốn chi phí cố định.
Ưu điểm:
– Rẻ khi traffic tăng vừa.
– Kiểm soát CPU/RAM/disk.
– Không bị tính tiền từng feature.
– Dễ thêm Redis, queue, cron.
Nhược điểm:
– Phải tự backup.
– Phải tự monitor.
– Phải lo update, firewall, restore.
– Sai cấu hình là downtime.
Gợi ý stack rẻ:
– VPS 2-4 vCPU, 4-8GB RAM.
– Docker Compose.
– Postgres.
– Redis.
– Nginx/Caddy.
– Backend: NestJS, Fastify, Express, Django, Laravel, Go.
– Backup nightly sang S3/R2/B2.
Cách tiết kiệm: dùng Supabase chỉ cho Auth hoặc bỏ Supabase hoàn toàn, tự dùng session/JWT.
2. Neon: Postgres serverless
Neon là Postgres serverless, tách compute và storage. Có branching, autosuspend. Rất hợp dev/staging, app có traffic không đều.
Hợp với:
– SaaS nhỏ-vừa.
– Traffic lên xuống.
– Cần Postgres managed.
– Không muốn tự vận hành DB.
Ưu điểm:
– Không tự quản DB.
– Autosuspend giảm chi phí khi ít dùng.
– Branch database tiện test.
– Dùng được với ORM phổ biến.
Nhược điểm:
– Cold start có thể ảnh hưởng.
– Workload liên tục có thể không rẻ nhất.
– Realtime/Auth/Storage phải dùng dịch vụ khác.
Mô hình tốt: Neon + backend riêng + Clerk/Auth.js + Cloudflare R2.
3. Railway / Render / Fly.io
Các nền tảng này giúp deploy backend nhanh hơn VPS, ít DevOps hơn, nhưng vẫn linh hoạt hơn BaaS.
Hợp với:
– Team muốn deploy dễ.
– Backend custom.
– Cần worker/cron.
– Muốn tách khỏi Supabase dần.
Ưu điểm:
– DX tốt.
– Có database managed.
– Deploy từ Git.
– Scale từng service.
Nhược điểm:
– Có thể đắt nếu scale lớn.
– Pricing cần theo dõi.
– Không rẻ bằng VPS tự quản.
Chiến lược: chạy API/worker tại đây, giữ DB ở Supabase/Neon trước. Sau đó migrate DB nếu cần.
4. Appwrite self-host
Appwrite giống BaaS mã nguồn mở: Auth, database, storage, functions. Có thể self-host.
Hợp với:
– Muốn BaaS nhưng tự host.
– App mobile/web cần auth, file, collection.
– Team không muốn viết nhiều backend.
Ưu điểm:
– Nhiều feature có sẵn.
– Self-host giảm chi phí ở quy mô vừa.
– Dashboard tiện.
Nhược điểm:
– Không phải Postgres-first như Supabase.
– Cần vận hành stack.
– Migration từ Supabase không luôn dễ.
Lưu ý: hợp nếu chấp nhận đổi mô hình dữ liệu. Không nên đổi chỉ để tiết kiệm vài đô.
5. PocketBase
PocketBase rất nhẹ: single binary, SQLite, Auth, realtime, file storage, admin UI.
Hợp với:
– MVP, internal tool, app nhỏ-vừa.
– Dữ liệu không quá lớn.
– Muốn backend cực rẻ trên VPS nhỏ.
Ưu điểm:
– Cực dễ deploy.
– Tốn ít RAM/CPU.
– Chi phí thấp.
– DX tốt.
Nhược điểm:
– SQLite có giới hạn write concurrency.
– Không hợp workload lớn nhiều ghi.
– Scale ngang khó hơn Postgres.
Kết luận nhỏ: PocketBase rẻ thật, nhưng không phải thay thế cho app Postgres lớn.
Cách giảm chi phí trước khi migrate
Migration tốn. Tối ưu hiện tại thường lời hơn.
Tối ưu database
Database thường là gốc chi phí. Làm trước:
– Bật query log cho query chậm.
– Kiểm tra index cho cột filter/sort/join.
– Dùng materialized view cho report nặng.
– Tránh N+1 query.
– Dùng pagination bằng created_at hoặc id.
– Archive dữ liệu cũ sang bảng khác.
– Xóa log/event không cần giữ lâu.
Một index đúng có thể rẻ hơn nâng plan nhiều lần.
Thêm cache
Cache giảm đọc database.
– Redis cho session, rate limit, dữ liệu nóng.
– CDN cache cho API public.
– In-memory cache cho config ít đổi.
– Cache tại client với stale-while-revalidate.
Quy tắc: cache dữ liệu đọc nhiều, đổi ít.
Tách file khỏi backend chính
Nếu app có ảnh/video/file, storage nên tách sớm.
– Upload trực tiếp từ client bằng signed URL.
– Lưu metadata trong Postgres.
– File nằm ở R2/B2/S3.
– CDN phát file.
– Tạo thumbnail để tránh gửi ảnh gốc.
Kết quả: DB nhẹ hơn, backend ít bandwidth hơn.
Giảm realtime
– Chỉ subscribe room nhỏ.
– Unsubscribe khi tab ẩn.
– Dùng polling cho dữ liệu không cần tức thì.
– Gộp event trong 1-3 giây.
– Giới hạn presence theo nhóm.
Realtime tốt khi tạo giá trị rõ. Không tốt khi chỉ để UI “có vẻ live”.
Đưa job nền ra queue
Không xử lý việc nặng trong request.
– Email hàng loạt.
– Resize ảnh.
– Import CSV.
– Gọi AI API.
– Tạo report.
– Sync dữ liệu bên thứ ba.
Dùng queue như BullMQ, Faktory, Celery, Sidekiq, hoặc managed queue. Worker chạy trên VPS rẻ.
Chiến lược migrate ít rủi ro
Đừng “big bang migration”. Tách từng phần.
Bước 1: Đo chi phí
Xem chi phí theo nhóm:
– Database compute.
– Storage.
– Egress.
– Function invocation.
– Realtime.
– Logs.
– Auth users.
Không đo thì đổi sai.
Bước 2: Tách storage trước
Storage dễ tách nhất. Chuyển file sang R2/B2/S3. Giữ URL hoặc proxy để không phá client.
Bước 3: Tách backend logic
Viết API riêng cho nghiệp vụ mới. Client gọi API mới dần. Supabase vẫn giữ DB/Auth.
Bước 4: Tách database sau cùng
Database khó nhất. Cần:
– Dump/restore.
– Kiểm tra extension.
– Migrate RLS policy sang logic backend nếu bỏ Supabase.
– Dual-write tạm thời nếu downtime không được phép.
– Plan rollback.
Bước 5: Giữ Auth nếu chưa cần đổi
Auth migration gây đau: password hash, session, OAuth callback, email verification. Nếu Supabase Auth vẫn rẻ, có thể giữ.
Mô hình kiến trúc rẻ, thực tế
App SaaS nhỏ-vừa
– Backend: Fastify/NestJS trên VPS hoặc Fly.io.
– DB: Neon hoặc Postgres VPS.
– Auth: Auth.js/Clerk/Supabase Auth.
– File: Cloudflare R2.
– Cache/Queue: Redis.
– CDN: Cloudflare.
Lý do: scale đủ, chi phí rõ, không quá nhiều DevOps.
App nội bộ hoặc tool B2B nhỏ
– PocketBase trên VPS.
– Backup SQLite hằng ngày.
– Cloudflare Tunnel hoặc Caddy.
– R2 cho file lớn.
Lý do: cực rẻ, deploy nhanh.
App nhiều media
– DB: Supabase/Neon/Postgres.
– File: R2.
– Image resize: Cloudflare Images hoặc worker riêng.
– CDN: Cloudflare.
– Backend không stream file.
Lý do: egress giảm mạnh.
Kết luận: rẻ hơn không chỉ là đổi nhà cung cấp
Supabase alternative rẻ hơn có nhiều: VPS tự host, Neon, Railway/Render/Fly.io, Appwrite, PocketBase. Nhưng tiết kiệm thật đến từ hiểu workload.
Thứ tự đúng:
1. Đo phần nào tốn.
2. Tối ưu query và index.
3. Tách storage sang object storage + CDN.
4. Giảm realtime không cần thiết.
5. Đưa job nặng sang queue/worker.
6. Migrate từng phần nếu chi phí vẫn cao.
Nếu app còn nhỏ, Supabase giúp đi nhanh. Nếu app đã tăng trưởng, backend cần thiết kế lại quanh chi phí. Đừng đổi vì ghét hóa đơn. Đổi khi số liệu nói rõ: phần nào tốn, vì sao tốn, và alternative nào giảm đúng phần đó.