Supabase hay Firebase: hóa đơn đổi theo dữ liệu hay hành vi người dùng

Nếu ứng dụng có nhiều quan hệ dữ liệu và cần dự trù ngân sách, Supabase thường dễ lập kế hoạch hơn nhờ mức phí nền cùng các hạn mức tài nguyên. Nếu dữ liệu hợp với mô hình tài liệu và số thao tác thấp, Firebase với Cloud Firestore Standard có thể tốn ít hơn. Khi lượt truy cập tăng, số tài liệu được đọc mỗi lần mở màn hình và lượng dữ liệu truyền đi mới là biến số cần chú ý.

Vì thế, số người dùng hoạt động hằng tháng không đủ để dự báo hóa đơn. Một feed được mở liên tục có thể tạo nhiều lượt đọc trên cùng tập dữ liệu, trong khi một phần mềm quản trị có nhiều người dùng nhưng ít thao tác có thể phát sinh phí Firestore rất thấp. Ba kịch bản giả định dưới đây dùng cùng một cách đếm để cho thấy chi phí đổi theo hành vi truy cập như thế nào.

Hai cấu trúc giá tính những gì?

Theo bảng giá Supabase, gói Pro khởi điểm 25 USD mỗi tháng, gồm dự án đầu tiên, 100.000 người dùng hoạt động hằng tháng, 8 GB dung lượng đĩa cơ sở dữ liệu cho mỗi dự án và 250 GB egress thông thường; egress vượt hạn mức có giá 0,09 USD mỗi GB. Gói trả phí có tín dụng điện toán đủ cho một máy Micro, còn cấu hình lớn hơn làm chi phí tăng. Supabase không đặt đơn giá riêng cho từng hàng dữ liệu được đọc, nhưng nhiều truy vấn nặng vẫn có thể đòi hỏi máy mạnh hơn.

Gói Free của Supabase có 500 MB cơ sở dữ liệu và 5 GB egress; dự án có thể bị tạm dừng sau một tuần không hoạt động. Vì vậy, mức 25 USD là chi phí của lựa chọn Pro, không phải giá khởi điểm bắt buộc để chạy mọi ứng dụng trên Supabase. Khi so với Firestore, cần nói rõ đang đặt hai gói miễn phí cạnh nhau hay đang tính chi phí của một dự án Pro.

Quy tắc tính phí Cloud Firestore dựa vào lượt đọc, ghi và xóa tài liệu, dung lượng lưu trữ kể cả chỉ mục, cùng băng thông; một cơ sở dữ liệu đủ điều kiện được miễn 50.000 lượt đọc và 20.000 lượt ghi mỗi ngày, 1 GiB lưu trữ và 10 GiB dữ liệu truyền ra mỗi tháng. Hạn mức thao tác được đặt lại theo ngày, nên lưu lượng dồn vào một ngày có thể phát sinh phí dù tổng lượt của cả tháng trông thấp. Một số truy vấn còn tính lượt đọc mục chỉ mục; Security Rules đọc tài liệu phụ thuộc cũng có thể tạo lượt đọc tính phí.

Với Firestore Standard tại vùng us-central1, đơn giá thao tác cơ sở dữ liệu là 0,03 USD cho 100.000 lượt đọc và 0,09 USD cho 100.000 lượt ghi vượt hạn mức. Đây chỉ là giá thao tác của cấu hình được chọn. Lưu trữ, băng thông, xác thực và các dịch vụ Firebase khác không thể gộp vào một giá cố định cho mọi ứng dụng.

Ba workload giả định làm hóa đơn thay đổi ra sao?

Các phép tính sau giả định tháng có 30 ngày, lưu lượng đều mỗi ngày và chỉ một cơ sở dữ liệu Firestore hưởng hạn mức miễn phí. Chúng chưa tính lượt đọc thêm do chỉ mục hoặc Security Rules, lượt xóa, hay phí của những dịch vụ ngoài cơ sở dữ liệu. Số người hoạt động mỗi ngày được nêu riêng vì hai ứng dụng có cùng MAU vẫn có thể tạo lượng thao tác rất khác.

Ứng dụng nhỏ: cả hai có thể chưa mất phí cơ sở dữ liệu

Giả sử ứng dụng có 2.000 MAU, trong đó 300 người sử dụng mỗi ngày; mỗi người đọc 10 tài liệu và ghi 3 lần. Kết quả là 3.000 lượt đọc và 900 lượt ghi mỗi ngày. Nếu toàn bộ dữ liệu lưu trữ, kể cả phần phụ trợ của Firestore, chiếm 0,2 GiB và egress là 2 GiB mỗi tháng, các đại lượng này đều nằm trong hạn mức miễn phí đã nêu của Firestore. Riêng phần Firestore được mô phỏng có phí 0 USD.

Dung lượng và egress giả định cũng nằm trong hạn mức Supabase Free. Trả 25 USD để dùng Pro có thể hợp lý nếu ứng dụng cần điều kiện vận hành của gói đó, nhưng không phải kết quả tất yếu của kịch bản nhỏ này. Khác biệt xuất hiện khi ứng dụng vượt giới hạn Free, cần dự án không tạm dừng hoặc cần nhiều tài nguyên hơn.

Feed đọc nhiều: mỗi lần mở nhân số tài liệu được tính

Giả sử 40.000 người hoạt động mỗi ngày, mỗi người mở feed 10 lần và mỗi lần nhận 50 tài liệu. Phép nhân 40.000 × 10 × 50 cho ra 20 triệu lượt đọc mỗi ngày, hay 600 triệu lượt trong tháng. Sau khi trừ 1,5 triệu lượt miễn phí của 30 ngày, phí đọc Firestore theo đơn giá trên là khoảng 179,55 USD. Đây chưa phải toàn bộ hóa đơn: truy vấn phụ, lượt ghi và dữ liệu truyền ra có thể làm con số tăng thêm.

Nếu giả định mỗi tài liệu tạo đúng 0,5 kB dữ liệu truyền ra trên cả hai nền tảng, lượng dữ liệu từ các lần đọc là khoảng 300 GB trong tháng. Với giả định toàn bộ đó là egress thông thường được Supabase tính phí, Pro vượt hạn mức 250 GB khoảng 50 GB, tức thêm 4,50 USD ngoài mức nền 25 USD. Firestore cũng vượt hạn mức truyền ra miễn phí, nhưng phí mạng phụ thuộc nơi đặt cơ sở dữ liệu và nơi nhận dữ liệu; không thể cộng một khoản chung vào 179,55 USD. Phép so sánh này cũng chưa chứng minh máy Micro của Supabase đủ sức phục vụ lượng truy vấn giả định.

Chỉ đổi cách tải feed đã đổi phép tính. Nếu mỗi lần mở lấy 10 tài liệu thay vì 50, trong cùng giả định về người dùng và số lần mở, lượt đọc giảm còn một phần năm. Còn nếu dùng trình nghe dữ liệu theo thời gian thực, tài liệu được thêm hoặc cập nhật trong tập kết quả có thể tạo thêm lượt đọc. Số bản ghi đang lưu không đổi, nhưng tần suất nhận chúng quyết định phần đáng kể của chi phí.

SaaS nhiều tenant: thao tác rẻ chưa giải quyết bài toán quan hệ

Giả sử một SaaS có 200 tenant, mỗi tenant có 50 người hoạt động mỗi ngày, tổng cộng 10.000 người hoạt động hằng tháng. Mỗi người đọc 10 tài liệu và ghi 5 lần mỗi ngày: Firestore có 100.000 lượt đọc và 50.000 lượt ghi một ngày. Sau hạn mức miễn phí, phần phải trả trong 30 ngày là 0,45 USD cho đọc và 0,81 USD cho ghi, tổng 1,26 USD. Giả định thêm rằng dữ liệu kể cả chỉ mục dưới 1 GiB và egress dưới 10 GiB thì hai mục đó chưa phát sinh phí.

Nếu chọn Supabase Pro cho cùng workload và các tài nguyên đều nằm trong hạn mức, mức nền là 25 USD. Firestore rẻ hơn ở phép tính thao tác này. Tuy nhiên, một báo cáo phải kết hợp người dùng, quyền truy cập và giao dịch giữa các bảng đặt ra câu hỏi khác: cần bao nhiêu truy vấn và bao nhiêu tài liệu để tạo cùng một kết quả? Nếu cách tổ chức tài liệu buộc ứng dụng đọc thêm dữ liệu cho mỗi báo cáo, phải cộng những lượt đó trước khi so giá.

Mô hình dữ liệu quyết định cách phát sinh lượt đọc

Tài liệu cơ sở dữ liệu Supabase xác định mỗi dự án dùng một cơ sở dữ liệu PostgreSQL đầy đủ, hỗ trợ bảng, quan hệ và truy vấn SQL. Với SaaS nhiều tenant, cấu trúc này thuận tiện khi báo cáo cần kết hợp dữ liệu từ nhiều bảng hoặc duy trì ràng buộc giữa các bản ghi. Một truy vấn SQL có thể đọc nhiều hàng mà không có đơn giá theo từng hàng, dù thời gian xử lý và bộ nhớ vẫn chịu giới hạn của cấu hình máy.

Firestore Standard tổ chức dữ liệu thành tài liệu trong collection và subcollection. Cách đó hợp với màn hình lấy một nhóm tài liệu đã xác định, nhất là khi ứng dụng dùng khả năng cập nhật theo thời gian thực hoặc hoạt động ngoại tuyến. Đổi lại, cùng một màn hình có thể tạo lượng đọc khác nhau tùy số tài liệu trả về, cách phân trang, bộ nhớ đệm và các lần kết nối lại. Ở workload đọc nhiều, thiết kế truy vấn tác động trực tiếp đến hóa đơn hơn tên gọi SQL hay NoSQL.

Rời nền tảng tốn công ở phần nào?

Với Supabase, PostgreSQL tạo một đường chuyển tương đối rõ cho phần dữ liệu quan hệ sang môi trường PostgreSQL khác. Công việc vẫn còn ở những phần ứng dụng gắn với dịch vụ của Supabase, như xác thực, lưu tệp và các API đang dùng. Mức phụ thuộc nền tảng vì thế không thể suy ra chỉ từ loại cơ sở dữ liệu.

Với Firestore, hướng dẫn xuất dữ liệu mô tả thao tác sao chép tài liệu sang Cloud Storage; dịch vụ xuất có quản lý yêu cầu bật tính phí và tính một lượt đọc cho mỗi tài liệu được xuất. Tệp xuất không tự biến collection và subcollection thành lược đồ SQL. Nếu chuyển sang PostgreSQL, ứng dụng còn phải thiết kế lại quan hệ, truy vấn, phân quyền và quá trình đồng bộ dữ liệu trong lúc chuyển đổi.

Đại lượng nào quyết định lựa chọn?

Với ứng dụng nhỏ, cần so các gói miễn phí và giới hạn vận hành trước khi mặc định trả phí. Với feed được mở nhiều lần, phép ước lượng hữu ích là người hoạt động mỗi ngày × số lần mở × số tài liệu nhận được, sau đó tính riêng egress và lượt đọc phụ. Với SaaS nhiều quan hệ dữ liệu, mức phí thao tác thấp của Firestore chỉ là một phần quyết định: số truy vấn cần để ghép dữ liệu, tài nguyên máy của Supabase và công chuyển nền tảng cũng có thể làm thay đổi lựa chọn hợp lý.

Đọc thêm:

• PostgreSQL hay MySQL: workload quyết định, không phải một bảng benchmark
• Canada đặt nguyên tắc: trung tâm dữ liệu không được đẩy giá điện sang dân
• Google Document AI hay Azure: hóa đơn một trang có thể chênh giá 10 lần