Supabase эсвэл Firebase: үнэгүй quota өсөхөд өөр төрлийн төлбөр болдог

Шинэ аппад Supabase эсвэл Firebase сонгохдоо үнэгүй хэмжээнээс хэзээ гарахаа, дараа нь юугаар төлөхөө хамт харах хэрэгтэй. Холбоотой өгөгдөл ихтэй жижиг SaaS-д Supabase-ийн Postgres болон багцын үнэ илүү зохимжтой байж болно. Баримт бичигт суурилсан, клиентэд шууд шинэчлэлт хүргэдэг аппад Firebase-ийн Cloud Firestore тохирч болох ч уншилт нэмэгдэхэд төлбөр дагаж өснө. Аль нь хурдан ажиллахыг тарифын хүснэгт дангаараа хэлэхгүй.

Supabase-ийн тариф Free багцад 500 MB өгөгдлийн сан, сарын 5 GB egress, 50,000 идэвхтэй хэрэглэгч багтааж, Pro-г сарын $25-аас эхлүүлэн нэг төсөл, 8 GB өгөгдлийн сан, 250 GB egress, 100,000 идэвхтэй хэрэглэгч олгодог. Firebase-ийн тариф Cloud Firestore Standard-д 1 GiB хадгалалт, өдөрт 50,000 баримтын уншилт, 20,000 бичилт, сард 10 GiB гарах урсгалыг үнэгүй олгодог; Realtime Database-ийн тусдаа үнэгүй хэмжээ нь 1 GB хадгалалт, өдөрт 360 MB таталт юм. Иймээс Firebase-ийн хоёр өгөгдлийн сангийн квотыг нэг саванд нэмж тооцож болохгүй.

Ижил ачааллыг ямар нэгжээр харьцуулах вэ?

Дараах гурван апп бол бодит үйлчилгээний хэмжилт бус, нөхцөлт сарын ачаалал юм. Тус бүрт нэвтэрсэн идэвхтэй хэрэглэгч, Firestore-ийн баримтын уншилт ба бичилт, өгөгдлийн сангийн хэмжээ, өгөгдлийн сангаас клиент рүү гарах урсгалыг авсан. Уншилт, бичилтийг 30 өдөрт жигд хуваасан тул нэг өдрийн огцом өсөлт бодит төлбөрийг энэ загвараас өөрчилж болно.

Энд нэг уншилт гэдэг нь нэг HTTP хүсэлт эсвэл нэг дэлгэц нээх үйлдэл биш, Firestore-оос уншигдсан нэг баримт юм. Нэг дэлгэц олон баримт татвал уншилт мөн олширно. Supabase API хүсэлт бүрийг тусдаа үнэлэхгүй ч илүү ачаалал нь өгөгдлийн сангийн compute болон дамжуулсан өгөгдөлд нөлөөлнө. Харьцуулалтад зураг, видео, CDN-ийн кэшээс үүсэх урсгалыг оруулаагүй; Supabase-д кэшээр дамжсан egress тусдаа квоттой. Мөн Firebase-ийн GiB нь Supabase-ийн GB-тай яг ижил хэмжээ биш тул босгод тулсан хэрэглээг нэгжийг нь хөрвүүлж шалгана.

Чат апп: давтагдах уншилт үнэгүй босгыг давна

Нөхцөлт чат апп сард 10,000 нэвтэрсэн идэвхтэй хэрэглэгч, 6 сая баримтын уншилт, 900,000 бичилт, 0.8 GB өгөгдлийн сан, 18 GB гарах урсгалтай гэж үзье. Жигд хэрэглэвэл Firestore-д өдөрт 200,000 уншилт, 30,000 бичилт ногдоно. Үнэгүй хэмжээнээс сардаа 4.5 сая уншилт, 300,000 бичилт илүү гарна; урсгал ч үнэгүй босгоос давна. Хадгалалт харин багтана. Firebase-ийн төлбөрт тариф сонговол эдгээр илүүдэл үйлдэл болон урсгал хэрэглэсэн хэмжээгээр тооцогдоно.

Supabase Free-д энэ аппын өгөгдлийн сан ч, egress ч багтахгүй. Нэг Micro төсөлтэй Pro багцын зарласан өгөгдлийн сан, egress, идэвхтэй хэрэглэгчийн хэмжээнд бол багтана. Гэхдээ энэ нь compute хүрэлцэнэ гэсэн гүйцэтгэлийн дүгнэлт биш. Олон хүн зэрэг чатлах үед Realtime-ийн зурвасын тоо, оргил холболт нэмэгддэг тул зөвхөн хадгалалт ба урсгалаар нийт зардлыг тогтоож болохгүй.

Firestore-ийн уншилтын тооцооны тайлбар сонсож буй хүсэлтийн үр дүнд баримт нэмэгдэх эсвэл шинэчлэгдэхэд дахин уншилт тооцдог; зарим дахин холболт ч шинэ хүсэлт шиг тооцогдоно. Тиймээс чат нээсэн тоогоор сарын баримтын уншилтыг орлуулбал ачааллыг дутуу үнэлнэ. Supabase-д энэ үйлдлийн тоо төлбөрийн тусдаа мөр болохгүй ч query, индекс болон compute-ийн хэрэгцээг өсгөж болно.

Жижиг SaaS: өгөгдлийн холбоо ба төслийн үнэ

Нөхцөлт жижиг SaaS сард 3,000 нэвтэрсэн идэвхтэй хэрэглэгч, 900,000 уншилт, 90,000 бичилт, 0.3 GB өгөгдлийн сан, 3 GB гарах урсгалтай байг. Өдөрт дунджаар 30,000 уншилт, 3,000 бичилт болж, жигд ачааллын энэ хувилбар хоёр үйлчилгээний үндсэн үнэгүй хэмжээнд багтана. Харин Supabase-ийн Free төсөл идэвхгүй удвал түр зогсдог; тасралтгүй ажиллах production орчныг Pro дээр байрлуулах шийдвэр тогтмол багцын төлбөр авчирна.

Энд өгөгдлийн загвар үнийн зөрүүнээс чухал байж болно. Байгууллага, гишүүн, захиалга, эрх зэрэг олон холбоотой өгөгдөлтэй SaaS-д Postgres-ийн хүснэгт, холбоос, SQL query ойлгомжтой суурь өгнө. Firestore-д баримтын бүтцийг дэлгэц бүрийн унших хэв маягт нийцүүлж төлөвлөнө; олон холбоог хамарсан өөрчлөлт гарах үед клиент код болон өгөгдөл шинэчлэх логикт нэмэлт ажил үүсэж болно. Энэ бол тарифын баталгаа бус, хөгжүүлэлтийн өртгийг тооцох шалтгаан юм.

Supabase Pro-ийн багц байгууллагад хамаардаг ч төсөл бүр өөрийн compute-той. Нэг Micro төслийн compute-г багцын кредит нөхөх нөхцөлд хөгжүүлэлт болон production-ийг тусад нь байнга ажиллуулахад нэмэлт төслийн төлбөр гарна. Firestore-ийн Blaze тарифт үүнтэй адил нэг суурь project fee тавиад шууд харьцуулах боломжгүй: ашигласан үйлчилгээ тус бүр өөрийн тооцох нэгжтэй. Олон орчинтой багийн хувьд энэ ялгаа анхны сарын төлбөрөөс эхлэн мэдэгдэнэ.

Контент апп: таталт давамгайлах үед

Нөхцөлт контент апп сард 40,000 нэвтэрсэн идэвхтэй хэрэглэгч, 2.4 сая уншилт, 150,000 бичилт, 0.8 GB өгөгдлийн сан, 60 GB гарах урсгалтай гэж авъя. Firestore-д жигд хуваавал өдөрт 80,000 уншилт болж, сарын 900,000 уншилт үнэгүй хэмжээнээс илүү гарна. Бичилт, хадгалалт багтах боловч гарах урсгалын илүүдэл илүү том асуудал болно. Supabase Free-д өгөгдлийн сан болон egress хоёулаа хүрэлцэхгүй, нэг Micro төсөлтэй Pro-ийн зарласан хэмжээнд эдгээр үзүүлэлт багтана.

Энэ хувилбарт хэрэглэгчийн тоо дангаараа төлбөрийг тайлбарлахгүй. Нэг хүн олон нийтлэл нээвэл баримтын уншилт өснө; том хариу эсвэл олон таталт урсгалыг өсгөнө. Зочид нэвтрэлгүй уншдаг бол нийт үзэгчийг Auth-ийн идэвхтэй хэрэглэгчтэй адилтгахгүй, харин уншилт ба урсгал хэвээр тооцогдоно. Зураг, видео ихтэй контент аппад файл хадгалах үйлчилгээ болон CDN-ийн хэрэглээг тусад нь нэмэх шаардлагатай; файлын egress сонголт тэр зардалд шууд нөлөөлнө.

Spend cap төлбөрийг хаана зогсоох вэ?

Supabase-ийн Spend Cap тайлбар Pro багцад хамрагдах хэрэглээ квотоо давбал дараагийн хэрэглээг хязгаарлаж, илүүдлийн төлбөрөөс хамгаалдаг гэж заадаг. Egress, хадгалалт, идэвхтэй хэрэглэгч, Realtime-ийн хэрэглээ хамрагдана; compute хамрагдахгүй. Үүний үнэ нь үйлчилгээ саатах боломж: урсгалын босго хүрсэн контент апп төлбөр нэмэгдэхийн оронд таталтаа хязгаарлуулж болно. Иймээс cap нь бүх зардлын хатуу дээд хэмжээ биш.

Firebase-ийн spend cap баримт бичиг Blaze дээрх боломжийг Preview гэж тэмдэглэж, зөвхөн жагсаасан зарим үйлчилгээнд хамааруулдаг; Cloud Firestore уг жагсаалтад байхгүй. Тэр боломж ч хэрэглээний мэдээлэл хоцорч ирдэг тул шууд хэрэгждэг хатуу хязгаар биш. Иймд Firestore-ийн уншилтад төлбөрийн дээд хязгаар тавьсан мэт төсөв зохиож болохгүй. Хоёр үйлчилгээний зардлын хамгаалалтыг ижил нэртэй тохиргоо мэт үзвэл чат аппын эрсдэлийг буруу тооцно.

Нүүх өртгийг сонголтод яаж оруулах вэ?

Үнэ ба хурдыг нэг сарын тооцоогоор шийдэхэд өгөгдлийн загварыг солих ажлыг орхигдуулна. Firestore-ийн баримтуудыг Postgres-ийн хүснэгт, холбоос, query болон эрхийн дүрэмд хөрвүүлэх шаардлагатай. Эсрэг чиглэлд хүснэгт хоорондын холбоог баримтын бүтэц, давхардсан өгөгдлийг шинэчлэх логик болгон дахин төлөвлөнө. Нэвтрэлт, realtime ажиллагаа, клиент код, өгөгдөл шилжүүлэх хугацаа ч тусдаа хөгжүүлэлтийн ажил болно; эдгээрт бүх аппад тохирох нэг үнэ байхгүй.

Иймээс жижиг SaaS-ийн холбоотой өгөгдөл, тусдаа орчны хэрэгцээ тодорхой бол Supabase-ийн загвар болон төслийн төлбөрийг хамтад нь сонгох үндэстэй. Чат аппад Firestore-ийн шууд шинэчлэлт тохирч болох ч сонсогчийн бодит уншилтыг төлбөрт ачаалал гэж үзнэ. Контент аппад өгөгдлийн сангийн сонголтоос гадна таталтын хэмжээ шийдвэрлэх нөлөөтэй. Эдгээр ачаалалд аль үйлчилгээ хурдан байхыг зөвхөн өөрийн query, индекс, кэш, байрлал, зэрэг хэрэглэгчийн нөхцөлөөр тогтооно.

Мөн уншаарай:

• Cloudflare R2 эсвэл Amazon S3: таталт ихсэхэд egress сонголтыг шийднэ
• SQLite эсвэл PostgreSQL: нэг writer хүрэлцэхгүй болох мөчид сонголт өөрчлөгдөнө
• OBS эсвэл Streamlabs: 1080p60 дээр CPU-ийн 11 пунктын зөрүү гарчээ