Chọn backend cho dự án nhỏ: Supabase, Firebase hay MONA Base?

Nhiều dự án nhỏ trông như đã xong phần giao diện, nhưng phần khó thật sự nằm ở phía sau. Đó là nơi lưu dữ liệu, xử lý đăng nhập và chứa ảnh hay tài liệu người dùng tải lên. Backend chạy ngầm, người dùng không nhìn thấy, nhưng thiếu nó thì gần như không có gì hoạt động. Chúng tôi đã qua nhiều lần chọn nền tảng cho những dự án như vậy, nên bài này kể lại cách cân nhắc của đội ngũ, kèm những chỗ chưa ổn của từng lựa chọn.

Vì sao backend có sẵn đang được chú ý

Phần lớn prototype không chết vì giao diện xấu. Chúng thường dừng lại vì đội mất nửa tháng dựng hệ thống đăng nhập, rồi thêm nửa tháng chỉ để xử lý chuyện lưu ảnh đại diện. Backend-as-a-Service, gọi tắt là BaaS, là dịch vụ backend trọn gói thuê theo tháng, giúp đội bỏ qua phần việc lặp đi lặp lại đó.

Câu hỏi hay gặp là nên tự dựng VPS hay thuê dịch vụ. Người mới thường nghĩ tự dựng sẽ rẻ hơn. Nhưng thời gian vá lỗi và sao lưu thường nhiều hơn dự kiến rất nhiều. Còn dữ liệu nên đặt ở đâu thì phụ thuộc vào khách hàng và loại dữ liệu bạn đang xử lý.

BaaS thường gồm những phần nào

Một BaaS thường có bốn phần chính. Phần đầu là cơ sở dữ liệu, nơi giữ đơn hàng và hồ sơ người dùng. Phần thứ hai là xác thực, kiểm tra ai đang đăng nhập. Phần thứ ba là lưu trữ tệp cho ảnh và tài liệu. Phần cuối là API tự sinh, cho phép ứng dụng gọi dữ liệu mà không cần viết máy chủ riêng.

Điều nhiều người bỏ qua là sự đánh đổi khi phụ thuộc vào một nhà cung cấp. Khi muốn chuyển đi, bạn phải làm lại việc xuất dữ liệu, viết lại quy tắc phân quyền và đổi cách gọi API. Bạn cũng ít kiểm soát được dữ liệu đang nằm trên máy chủ nào. Với khách hàng có yêu cầu riêng về vị trí lưu trữ, chi tiết này có thể trở thành vấn đề lớn.

Vậy khi nào nên tự host? Khi đội có người vận hành hạ tầng và dữ liệu bắt buộc phải nằm trong hệ thống riêng. Ngoài trường hợp đó, dịch vụ quản lý thường gọn hơn, nhất là với đội nhỏ chưa có người chuyên trách hạ tầng.

Ba tiêu chí chúng tôi dùng để chọn

Tiêu chí đầu tiên là khả năng tương thích SDK. Nếu mã đã viết bằng thư viện của một hãng, đổi sang hãng khác sẽ tốn thời gian. Chúng tôi thường kiểm tra xem có giữ được lời gọi hiện tại không, và cần sửa bao nhiêu chỗ. Con số này quyết định khá nhiều chi phí chuyển đổi về sau.

Tiêu chí thứ hai là vị trí lưu trữ và yêu cầu tuân thủ. Khách hàng trong nước thường hỏi dữ liệu nằm ở đâu. Đây không hẳn là câu hỏi kỹ thuật, mà liên quan trực tiếp đến hợp đồng và cam kết bảo mật bạn ký với họ.

Tiêu chí cuối là mô hình giá. Gói miễn phí lúc đầu thường khá rộng rãi, nhưng khi lưu lượng tăng, băng thông, số lượt gọi hàm và dung lượng lưu trữ có thể khiến hóa đơn tăng rất nhanh. Hãy đặt câu hỏi này ngay từ đầu, đừng đợi sản phẩm chạy rồi mới tính.

Supabase và Firebase: điểm mạnh và điểm yếu

Supabase được xây trên PostgreSQL, hệ quản trị cơ sở dữ liệu quan hệ mã nguồn mở. Dữ liệu tổ chức thành các bảng liên kết với nhau. Điểm mạnh lớn nhất là dữ liệu dễ mang đi, vì đó là Postgres chuẩn. Điểm yếu là bạn cần hiểu SQL và RLS, tức Row Level Security, phân quyền theo từng dòng dữ liệu. Cấu hình RLS sai có thể khiến người dùng này đọc được dữ liệu của người khác. Lỗi kiểu này khá khó phát hiện nếu không kiểm thử kỹ.

Firebase dùng NoSQL, lưu dữ liệu dưới dạng tài liệu linh hoạt, không ràng buộc theo bảng. Nó tích hợp rất tốt với hệ sinh thái Google và ứng dụng di động. Đổi lại, khả năng truy vấn hạn chế hơn, nên những câu hỏi phức tạp khó viết gọn. Chúng tôi thường thấy các đội phải thiết kế lại cấu trúc dữ liệu khi nhu cầu báo cáo tăng lên.

Cả hai đều có một điểm chung cần lưu ý: dữ liệu đặt trên máy chủ nước ngoài, nên độ trễ với người dùng Việt Nam phụ thuộc phần lớn vào vùng bạn chọn. Hãy đo thực tế thay vì chỉ tin con số quảng cáo trên trang chủ.

MONA Base trong bức tranh backend Việt Nam

Hiện MONA Base chính thức đang ở bản beta. Bản này cung cấp Postgres 17, Auth và Storage, đồng thời tương thích với supabase-js. Nếu đội đang dùng Supabase và muốn đổi nhà cung cấp mà không viết lại toàn bộ mã, đây là lựa chọn đáng xem qua.

Điểm thứ hai là dữ liệu đặt tại Việt Nam. Với dự án cần lưu trữ trong nước, điều này bớt đi một lớp câu hỏi khi làm việc với khách hàng. Đội ngũ đã gặp không ít trường hợp muốn thay thế Supabase bằng MONA Base beta tại Việt Nam vì lý do này. Cách làm an toàn nhất là bắt đầu từ một môi trường thử nghiệm nhỏ.

Cũng cần nói rõ những điểm chưa tốt. Đây vẫn là bản beta, hệ sinh thái plugin và tài liệu chưa dày bằng các đối thủ lâu năm. Khi gặp lỗi lạ, bạn sẽ tìm được ít câu trả lời hơn trên diễn đàn. Vì vậy chúng tôi không khuyên đưa thẳng sản phẩm quan trọng lên bản beta khi chưa thử kỹ.

Chi phí thực tế: đọc bảng giá đúng cách

Các con số dưới đây tính đến tháng 11/2026. Trước khi quyết định, hãy kiểm tra lại trên trang chính thức của từng nhà cung cấp, vì giá có thể thay đổi.

Với MONA Base, giá tính theo gói dịch vụ. Các dịch vụ liên quan như MONA Pay và MONA Mail có gói miễn phí với giới hạn: MONA Pay miễn phí 500 giao dịch mỗi tháng, MONA Mail miễn phí 3.000 email mỗi tháng. MONA Cloud tính theo tài nguyên, khoảng 250 đồng cho mỗi core-giờ và 150 đồng cho mỗi GB RAM-giờ, mức tối thiểu 550 đồng mỗi giờ, và có tặng 100.000 credit ban đầu.

Đừng chỉ nhìn giá gói. Chi phí ẩn thường nằm ở băng thông, số lượt gọi hàm và dung lượng lưu trữ khi người dùng bắt đầu tăng. Chúng tôi thường ước lượng lưu lượng thật trong ba tháng đầu rồi mới so sánh, vì con số ước tính lúc đầu hay lệch khá xa thực tế.

Khi nào chọn Supabase, Firebase hay MONA Base

Chọn Supabase nếu bạn cần một hệ sinh thái quốc tế lâu năm và đội đã quen với SQL. Đây là lựa chọn khá an toàn khi dự án có khả năng phát triển dài hạn và cần nhiều tính năng mở rộng.

Chọn Firebase nếu ứng dụng di động là trọng tâm và bạn cần tích hợp sâu với dịch vụ của Google. Với ứng dụng di động đơn giản, Firebase thường giúp đưa sản phẩm ra thị trường nhanh hơn, dù bạn phải chấp nhận giới hạn về truy vấn.

Chọn MONA Base nếu ưu tiên dữ liệu trong nước và muốn chuyển từ Supabase với ít thay đổi mã nhất. Khi đó hãy chấp nhận rủi ro của bản beta và đánh giá lại khi sản phẩm ổn định hơn. Theo chúng tôi, quyết định này nên dựa trên yêu cầu thực tế của khách hàng hơn là cảm tính.

Sai lầm thường gặp khi chuyển backend

Sai lầm đầu tiên là chuyển dữ liệu mà không kiểm tra lại quy tắc phân quyền. RLS hay security rules không phải lúc nào cũng tự đi theo dữ liệu. Đội ngũ từng gặp một bảng chạy đúng ở hệ cũ nhưng lộ dữ liệu sau khi chuyển, chỉ vì quên mang theo một chính sách. Hãy viết lại và thử từng luồng một cách có hệ thống.

Sai lầm thứ hai là bỏ qua sao lưu và kiểm thử khôi phục. Đừng đợi đến lúc có sự cố mới thử lấy lại dữ liệu. Hãy khôi phục thử một bản sao lưu ở môi trường riêng trước khi đưa vào dùng thật.

Sai lầm thứ ba là đánh giá sai hạn mức miễn phí. Gói miễn phí có thể đủ dùng trong vài tuần thử nghiệm, nhưng khi người dùng tăng, mọi thứ thay đổi nhanh. Hãy đặt cảnh báo hạn mức ngay từ đầu để không bị bất ngờ.

Lộ trình chuyển đổi và kiểm thử trước khi go-live

Chúng tôi thường chạy song song một môi trường thử với hệ cũ trong vài tuần. Mỗi truy vấn quan trọng được so sánh cả về kết quả lẫn độ trễ, để chắc chắn dữ liệu trả về giống nhau. Bước này nghe tốn công nhưng tiết kiệm rất nhiều thời gian sửa lỗi về sau.

Sau đó là kiểm thử các luồng chính: đăng nhập, tải tệp lên và phân quyền theo vai trò. Đừng chỉ thử bằng tài khoản quản trị, vì lỗi phân quyền thường chỉ lộ ra với tài khoản thường. Một vòng thử với ít nhất ba loại tài khoản sẽ bắt được phần lớn lỗi dạng này.

Cuối cùng, hãy lập kế hoạch rollback. Nếu nhà cung cấp mới gặp sự cố, bạn phải biết cách quay về hệ cũ trong thời gian ngắn. Với MONA Host, hệ thống có cam kết uptime 99,9% và chính sách hoàn tiền trong 7 ngày, nhưng đội ngũ vẫn khuyên mỗi đội nên có phương án dự phòng riêng. Nếu muốn tham khảo thêm cách chuẩn bị hạ tầng cho website bán hàng, bạn có thể xem các bài viết về website bán hàng trên goacademy.vn.

Câu hỏi thường gặp

MONA Base có tương thích với mã supabase-js hiện có không?

MONA Base tương thích với supabase-js, nên với nhiều dự án bạn chủ yếu chỉ cần đổi địa chỉ kết nối và khóa. Vẫn nên chạy kiểm thử đầy đủ, vì các tính năng nâng cao có thể khác nhau giữa hai hệ.

Dữ liệu lưu ở Việt Nam có ảnh hưởng đến tốc độ không?

Với người dùng trong nước, dữ liệu đặt ở Việt Nam thường giảm độ trễ so với máy chủ nước ngoài. Tốt nhất là đo thực tế từ nhiều vùng khác nhau để có kết quả chính xác cho đúng đối tượng người dùng của bạn.

Bản beta có phù hợp để chạy sản phẩm thật không?

Với sản phẩm nhỏ, ít rủi ro, bản beta có thể dùng được sau khi thử kỹ. Với hệ thống tài chính hoặc dữ liệu nhạy cảm, nên chờ đến khi bản chính thức ổn định hơn.

Có chuyển được dữ liệu từ Supabase hoặc Firebase sang MONA Base không?

Từ Supabase thì khá thẳng vì cùng nền Postgres. Từ Firebase, dữ liệu NoSQL cần chuyển đổi cấu trúc sang bảng nên sẽ tốn công hơn đáng kể.

Nên bắt đầu với gói nào để thử nghiệm?

Hãy bắt đầu với gói miễn phí hoặc gói thấp nhất để chạy môi trường thử. Khi đã đo được lưu lượng thật, bạn sẽ biết cần gói nào và không phải trả tiền cho tài nguyên không dùng đến.