Chúng tôi hay gặp một tình huống khá quen: một bạn dev làm xong bản MVP chỉ trong một buổi tối. Giao diện chạy, nút bấm hoạt động, ai cũng vui. Nhưng đến lúc cần đăng nhập, lưu ảnh người dùng tải lên và giữ dữ liệu cho đúng, bạn ấy mới phải dừng lại. Backend này lấy ở đâu? Trả phí kiểu gì? Dữ liệu cuối cùng nằm ở đâu? Năm nay những câu hỏi đó xuất hiện dày hơn trong các nhóm dev Việt, nhất là khi các dự án indie bắt đầu có người dùng thật.
Bài này chúng tôi viết để so sánh trung lập ba lựa chọn đang được nhắc nhiều: Supabase, Firebase và MONA Base. Chúng tôi sẽ nói cả điểm mạnh lẫn điểm chưa tốt của từng cái, vì mục tiêu là giúp bạn chọn đúng chứ không phải bán hàng. Nếu bạn đang loay hoay giữa các công cụ cho một dự án nhỏ, hy vọng phần dưới đây sẽ giúp bạn bớt mò mẫm.
Backend có sẵn thường phải lo những gì
Nói dễ hiểu, backend có sẵn là dịch vụ lo phần hạ tầng phía sau ứng dụng để bạn khỏi phải tự viết từ đầu. Bạn không cần tự dựng máy chủ lưu dữ liệu. Bạn cũng không phải tự làm hệ thống đăng nhập hay tự lo chuyện sao lưu. Nghe thì đơn giản, nhưng khi làm thật bạn sẽ thấy có khá nhiều việc được gói lại trong đó.
Thông thường một nền tảng như vậy gồm bốn phần. Phần đầu là cơ sở dữ liệu, tiêu biểu là Postgres, kèm API để app gọi vào lấy dữ liệu. Phần thứ hai là xác thực: đăng ký bằng email, đăng nhập bằng tài khoản mạng xã hội, quản lý phiên đăng nhập. Phần thứ ba là lưu trữ file và phân quyền, tức là ai xem được ảnh nào và ai được sửa gì. Phần cuối là realtime và hàm serverless. Đi kèm tất cả là các hạn mức, tức số lượng yêu cầu, dung lượng hay thời gian chạy mà gói của bạn cho phép. Vượt quá ngưỡng đó thì bạn sẽ bị tính thêm tiền hoặc bị chặn lại.
Supabase: điểm mạnh và những chỗ cần cân nhắc
Supabase là cái tên được nhiều dev quốc tế dùng. Điểm lớn nhất của nó là chạy trên Postgres thật, không phải một lớp giả lập. Kỹ năng SQL bạn học được hoàn toàn dùng lại được. Dữ liệu cũng dễ mang sang nơi khác hơn khi cần. Với một dự án indie, khả năng tự chủ như vậy thường đáng giá hơn người ta nghĩ, vì bạn không bị trói vào một cách viết dữ liệu riêng của nhà cung cấp.
Hệ sinh thái của Supabase cũng khá lớn. Tài liệu và ví dụ cộng đồng dồi dào, nên khi gặp lỗi bạn thường tìm ra lời giải chỉ sau vài phút tra cứu. Nếu muốn kiểm soát máy chủ hoàn toàn, bạn còn có thể tự host phần lõi trên hạ tầng của mình.
Mặt khác, gói miễn phí dễ chạm hạn mức khi lưu lượng tăng, nhất là với các app có nhiều thao tác tải file. Một số tính năng nâng cao nằm ở gói trả phí. Vì vậy trước khi dựa vào một chức năng nào đó, bạn nên kiểm tra xem nó thuộc gói nào. Theo chúng tôi, Supabase hợp nhất với những ai muốn làm quen với cộng đồng và tài liệu quốc tế, và sẵn sàng đọc tiếng Anh khi cần.
Firebase: khi NoSQL và hệ sinh thái Google là lợi thế
Firebase của Google thì mạnh ở realtime. Dữ liệu cập nhật gần như tức thì trên màn hình người dùng, rất hợp với app chat hay bảng theo dõi trực tiếp. Tích hợp với ứng dụng di động cũng khá mượt, và bạn được hưởng sẵn một loạt dịch vụ Google đi kèm.
Điểm yếu nằm ở cách tổ chức dữ liệu. Firebase dùng NoSQL, tức lưu dữ liệu dạng tài liệu lồng nhau thay vì bảng có quan hệ rõ ràng. Với app đơn giản thì cách này ổn. Nhưng khi bài toán có nhiều quan hệ phức tạp, bạn sẽ phải nhân đôi dữ liệu ở vài nơi hoặc viết thêm khá nhiều logic để ghép lại. Chúng tôi từng thấy một đội phải mất cả tuần chỉ để tái cấu trúc, sau khi nhận ra điều này quá muộn.
Chi phí của Firebase tính theo số lượt đọc và ghi. Cách tính này khó đoán nếu bạn chưa quen. Một đoạn code lặp vô tình có thể đốt tiền rất nhanh, nên hãy xem bảng sử dụng định kỳ thay vì đợi đến cuối tháng mới giật mình.
MONA Base: tương thích tốt, nhưng còn ở giai đoạn beta
MONA Base là nền tảng nội địa, hiện đang trong giai đoạn beta. Nó chạy Postgres 17, có sẵn bộ xác thực và lưu trữ file, và API tương thích với thư viện supabase-js. Với bạn đã quen Supabase, điều này có nghĩa là việc chuyển đổi bớt đau đầu hơn nhiều so với viết lại từ đầu. Dữ liệu cũng được lưu tại Việt Nam, một điểm đáng bàn riêng ở phần sau.
Điểm chưa tốt thì khá rõ. Vì còn beta, hệ sinh thái tài liệu và cộng đồng mỏng hơn các đàn anh, và một số tính năng có thể chưa đầy đủ. Nếu dự án của bạn cần một tính năng khá lạ, hãy kiểm tra trước khi đặt cược. Chúng tôi khuyên bạn thử một phần nhỏ của app trước khi chuyển toàn bộ.
Nếu bạn đang cân nhắc thay thế Supabase cho một dự án nhỏ, nên xem qua trang so sánh chi tiết và hướng dẫn chuyển đổi trước khi quyết định. Đọc trước sẽ tiết kiệm cho bạn vài buổi tối mò mẫm, và bạn sẽ biết rõ hơn những bước nào cần làm khi chuyển.
Chi phí thực tế: nhìn cách tính giá, đừng chỉ nhìn con số
Giá thay đổi theo thời gian, nên bạn nên xem bảng giá trên trang chính thức của từng nhà cung cấp tại thời điểm đọc bài này. Đừng tin một con số đã chép từ bài viết cũ, vì nó có thể đã lỗi thời. Nếu cần tham khảo thêm về cách lập ngân sách cho công cụ số, bạn có thể đọc thêm tại bài viết về tiêu dùng thông minh và chi tiêu hợp lý, vì nguyên tắc so sánh giá theo nhu cầu thực tế áp dụng khá giống nhau.
Quan trọng hơn con số là cách tính. Có nền tảng tính theo gói cố định, có nền tảng tính theo lượt đọc hoặc ghi, có nền tảng tính theo tài nguyên đã dùng như CPU, RAM và dung lượng đĩa. Hai cách tính khác nhau sẽ cho hóa đơn rất khác nhau khi lưu lượng biến động.
Một mẹo đơn giản để ước lượng là lấy số người dùng hoạt động mỗi ngày nhân với số thao tác trung bình của một người. Con số này cho bạn biết mình đang đứng ở đâu trên thang chi phí. Nó cũng giúp bạn nhận ra khi nào gói miễn phí bắt đầu không còn đủ dùng.
Dữ liệu ở đâu và quyền kiểm soát
Với dữ liệu người dùng Việt Nam, vị trí lưu trữ có ý nghĩa thực sự. Dữ liệu đặt gần người dùng thường truy cập nhanh hơn. Ngoài ra, một số đơn vị có yêu cầu nội bộ về việc lưu dữ liệu trong nước, và bạn nên biết mình thuộc trường hợp nào trước khi chọn.
Bên cạnh đó là khả năng xuất dữ liệu, sao lưu và rời nền tảng khi cần. Hãy hỏi trước: mình có tải toàn bộ database về được không? Định dạng là gì? Mất bao lâu? Đừng đợi đến lúc muốn chuyển đi mới phát hiện đường ra đã bị khóa.
Về pháp lý, việc bảo vệ dữ liệu cá nhân là trách nhiệm của bạn chứ không chỉ của nhà cung cấp. Hãy đọc chính sách bảo mật trước khi đưa dữ liệu thật lên, và chỉ thu thập những gì ứng dụng thực sự cần.
Quy trình thử nghiệm trong một tuần
Nếu chưa biết chọn cái nào, chúng tôi gợi ý thử nghiệm đúng một tuần theo nhịp dưới đây. Cách này giúp bạn quyết định dựa trên trải nghiệm thật thay vì cảm tính.
Ngày một đến hai, dựng prototype trên hai nền tảng bạn đang phân vân, dùng cùng một schema nhỏ, ví dụ bảng người dùng và bảng bài viết. Làm như vậy bạn sẽ thấy trực tiếp sự khác biệt trong cách viết truy vấn và cấu hình.
Ngày ba đến bốn, đo độ trễ khi gọi API từ vị trí của người dùng thật. Thử đăng nhập và thử tải lên một file vài megabyte. Đây là lúc bạn biết nền tảng có chậm hay có lỗi vặt nào không.
Ngày năm đến bảy, ước tính chi phí ở hai mức một nghìn và mười nghìn người dùng, rồi mới đưa ra quyết định. Một tuần thử nghiệm thật thường cho kết quả đáng tin hơn bất kỳ bài so sánh nào, kể cả bài này.
Sai lầm hay gặp khi chọn backend cho dự án indie
Sai lầm đầu tiên là chọn theo độ nổi tiếng mà không thử với dữ liệu thật. Một cái tên lớn không đảm bảo nó hợp với app của bạn. Sai lầm thứ hai là bỏ qua chi phí khi lưu lượng tăng đột biến. Nhiều dự án chạy rất ổn lúc còn ít người dùng, rồi một đợt lan truyền mạnh đẩy hóa đơn lên gấp nhiều lần chỉ trong vài ngày.
Sai lầm thứ ba là tự khóa mình vào một nền tảng mà không có kế hoạch xuất dữ liệu. Hãy luôn giữ một đường lui: sao lưu thường xuyên, và viết code tách khỏi các tính năng độc quyền nếu có thể.
Câu hỏi thường gặp
Có nên dùng bản beta cho sản phẩm thật không?
Theo chúng tôi là được, miễn là bạn chấp nhận rủi ro và có bản sao lưu riêng. Nếu sản phẩm không chịu được gián đoạn ngắn, hãy chờ bản ổn định hoặc chọn nền tảng đã chín hơn.
Chuyển từ Supabase sang nền tảng khác có khó không?
Tùy độ sâu bạn đã dùng. Nếu chỉ dùng Postgres và API chuẩn thì việc chuyển khá nhẹ nhàng. Nếu bạn phụ thuộc nhiều vào tính năng riêng của nền tảng, công việc sẽ nhiều hơn, nên hãy lên kế hoạch từ sớm.
Firebase có thay thế được Postgres không?
Với bài toán có quan hệ phức tạp thì thường là không tiện bằng. Firebase phù hợp hơn với dữ liệu dạng tài liệu và các tính năng realtime. Chọn theo bản chất dữ liệu của app sẽ đúng hơn là chọn theo thói quen.
Dữ liệu lưu ở Việt Nam có thực sự cần thiết không?
Tùy sản phẩm và đối tượng người dùng. Có ứng dụng thì cần, có ứng dụng thì không quá quan trọng. Hãy đánh giá theo yêu cầu thực tế của bạn và của khách hàng, đừng mặc định.
Làm sao biết khi nào nên nâng gói trả phí?
Khi bạn thấy hạn mức đang chạm ngưỡng đều đặn, hoặc khi thiếu một tính năng cần thiết cho việc phát triển. Theo dõi mức sử dụng hằng tuần sẽ giúp bạn nâng gói đúng lúc, không quá sớm mà cũng không quá muộn.
Nếu phải rút gọn lời khuyên: đừng chọn vội. Dành một tuần thử với dữ liệu thật, đo chi phí ở quy mô bạn kỳ vọng, và giữ đường lui trong tay. Lựa chọn hợp nhất là lựa chọn bạn đã tự kiểm chứng.