Supabase թե Firebase․ ընթերցումների հաշվարկը կարող է շրջել գինը

Վճարովի Supabase Pro-ի և Firebase-ի Cloud Firestore-ի միջև ընտրությունը կախված է հավելվածի հարցումների կառուցվածքից։ Պայմանական փոքր MVP-ում Firestore-ը կարող է տեղավորվել անվճար շեմում, մինչդեռ հաճախ ընթերցվող feed-ում անվտանգության կանոնի հավելյալ ընթերցումները կարող են նրա հաշիվը բարձրացնել Supabase Pro-ի հաշվից։ Այդ շրջադարձը հնարավոր է միայն եթե ընտրված Postgres հզորությունը բավարարի նույն ծանրաբեռնվածությանը։

Supabase-ի հրապարակային սակագինը Pro-ի մեկնարկը սահմանում է ամսական $25՝ առաջին նախագծով և $10 compute վարկով, ինչպես նաև ներառում է 100,000 ամսական ակտիվ օգտատեր և 250 ԳԲ ելքային տրաֆիկ։ Google Cloud-ի Firestore Standard-ի սակագնացույցում Այովայի us-central1 տարածաշրջանի համար օրական անվճար են 50,000 փաստաթղթային ընթերցում և 20,000 գրառում, դրանցից հետո դրույքները համապատասխանաբար $0.03 և $0.09 են յուրաքանչյուր 100,000 գործողության դիմաց, իսկ համաշխարհային սովորական ուղղություններով առաջին 10 GiB ամսական ելքային տրաֆիկից հետո դրույքը $0.12 է մեկ GiB-ի համար։

Ինչի համար է վճարվում

Supabase-ում յուրաքանչյուր նախագիծ ունի իր Postgres օրինակը, իսկ compute-ի չափը ընտրվում է առանձին։ Supabase-ի հաշվարկի կանոններով compute-ի վճարը կախված է այդ ռեսուրսից և գանձվում է անկախ բազայի ընթերցումների քանակից, մինչդեռ MAU-ի ու ելքային տրաֆիկի ներառված ծավալները գերազանցելը առանձին վճար է առաջացնում։ Սա ընթերցումների համար անսահմանափակ արտադրողականության խոստում չէ. ծանր հարցումը կամ միաժամանակյա մեծ հոսքը կարող է ավելի հզոր compute պահանջել։

Micro չափի նախագծի Postgres օրինակը առանձին է, սակայն դրա հաշվարկային ռեսուրսը բաժանվող է։ Այդ տարբերությունը կարևոր է feed-ի օրինակում. ամսական $25 հաշվարկը վերաբերում է Micro-ի բավարար լինելու պայմանին, ոչ թե հաստատված բեռնունակությանը։ Firestore-ում, հակառակը, փաստաթղթերի ընթերցումները, գրառումները, պահեստավորումն ու ելքային տրաֆիկը առանձին հաշվարկային միավորներ են։

Բջջային և վեբ հաճախորդների դեպքում Firebase-ի Firestore-ի վճարման կանոնները հավելյալ ընթերցում են հաշվում, երբ security rules-ի get(), exists() կամ getAfter() կանչը պետք է կարդա կախյալ փաստաթուղթ։ Նույն հարցման ընթացքում նույն կախյալ փաստաթղթին կրկնակի դիմելը կրկնակի վճար չի ստեղծում, իսկ կանոնի գնահատումը կատարվում է յուրաքանչյուր հարցման համար։ Հետևաբար նույն բովանդակությունը բազմաթիվ առանձին հարցումներով ստանալը կարող է ավելի թանկ լինել, քան ավելի քիչ հարցումներով ստանալը։

Երեք հաշվարկի ընդհանուր պայմանները

Ստորև երեք ծանրաբեռնվածությունն էլ պայմանական է՝ 30 օր հավասարաչափ օգտագործմամբ։ Supabase-ի կողմում կա մեկ Pro նախագիծ՝ Micro compute-ով. Firestore-ի կողմում՝ Standard edition-ի մեկ անվճար շեմին իրավասու բազա us-central1-ում, որի պատասխանները գնում են Հայաստան։ Ենթադրվում է, որ Postgres-ի կատարողականությունը բավարար է, Supabase-ի պահեստի ներառված ծավալը և Firestore-ի անվճար պահեստային շեմը չեն գերազանցվում։

Համեմատությունը ներառում է նշված բազայի գործողությունները, Supabase-ի փաթեթը, առաքված realtime հաղորդագրությունները և ելքային տրաֆիկը։ Այլ վճարովի ծառայություններ, Firestore-ի ինդեքսային ընթերցումներ ու պահեստի հավելավճարներ այս պայմանական դեպքերում չկան։ Օգտատերերի թվերը Supabase-ի MAU շեմը գնահատելու համար են. դրանք ինքնուրույն չեն որոշում Firestore-ի ընթերցումների քանակը։

Փոքր MVP․ Firestore-ի անվճար շեմը

Ենթադրենք՝ հավելվածն ունի ամսական 1,000 ակտիվ օգտատեր, օրական 10,000 փաստաթղթային ընթերցում և 1,000 գրառում, իսկ ամսական ելքային տրաֆիկը 1 ԳԲ է։ Ընթերցումները, գրառումները և տրաֆիկը տեղավորվում են Firestore-ի նշված անվճար շեմերում։ Այս պայմաններով հաշվարկվող Firestore ծախսը $0 է, մինչդեռ մեկ Micro նախագծով Supabase Pro-ի ամսական հիմքը $25 է։

Համեմատության այդ եզրը կախված է ընտրված փաթեթից։ Supabase-ն ունի նաև Free տարբերակ, որը կարող է բավարարել նման փոքր նախագծի՝ իր առանձին սահմանների շրջանակում։ Եթե նախագծին հենց Pro-ի պայմաններն են պետք, դրա հաստատուն վճարը սկսում է գործել մինչև ընթերցումների ծավալը մեծանալը։ MVP-ի այս օրինակը, հետևաբար, ցույց է տալիս վճարովի փաթեթի մեկնարկի և Firestore-ի անվճար շեմի տարբերությունը։

Հաճախ ընթերցվող feed․ կանոնը փոխում է հաշիվը

Ենթադրենք՝ 20,000 ակտիվ օգտատերերից յուրաքանչյուրը օրական 100 անգամ առանձին հարցմամբ ստանում է մեկ փոքր feed փաստաթուղթ։ Դա օրական 2 միլիոն հիմնական ընթերցում է։ Հավելվածը կատարում է նաև օրական 10,000 գրառում և ամսական փոխանցում 30 ԳԲ տվյալ։ Supabase-ում օգտատերերն ու տրաֆիկը տեղավորվում են Pro-ի ներառված չափերի մեջ, ուստի Micro-ի բավարար լինելու դեպքում այս սահմանված մասի հաշիվը մնում է $25։

Հիմա ենթադրենք՝ յուրաքանչյուր առանձին Firestore հարցման անվտանգության կանոնը կարդում է ևս մեկ կախյալ փաստաթուղթ։ Օրական 2 միլիոն հիմնական ընթերցմանը ավելանում է նույնքան կանոնային ընթերցում՝ ընդհանուր 4 միլիոն։ Սա չի նշանակում, որ յուրաքանչյուր կանոն միշտ վճարովի ընթերցում է ստեղծում. արդյունքը կախված է նրանից, թե տվյալ հարցումը գնահատելու համար կանոնն իրականում ինչ փաստաթուղթ է կարդում։

Օրական անվճար 50,000 ընթերցումը հանելուց հետո 30 օրում վճարվող ծավալը 118.5 միլիոն ընթերցում է, կամ $35.55։ Պայմանական 30 ԳԲ տրաֆիկը մոտ 27.94 GiB է. անվճար 10 GiB-ից հետո տրաֆիկն ավելացնում է մոտ $2.15։ Ընդհանուր հաշվարկը մոտ $37.70 է՝ $25 Supabase Pro-ի դիմաց։ Օրական գրառումները մնում են անվճար շեմում։

Եթե նույն feed-ի կանոնը կախյալ փաստաթուղթ չկարդա, Firestore-ի վճարվող ընթերցումները կարժենան $17.55, իսկ նույն տրաֆիկով ընդհանուր գումարը կլինի մոտ $19.70։ Այստեղ հավելյալ կանոնային ընթերցման առկայությունը փոխում է ավելի էժան տարբերակը։ Հարցումների խմբավորումն էլ կարող է ազդել արդյունքի վրա, քանի որ կախյալ փաստաթղթի ընթերցումը հաշվվում է հարցման գնահատման ընթացքում։

Realtime հավելված․ թարմացումն էլ ունի հաշվարկային միավոր

Երրորդ պայմանական հավելվածում 10,000 օգտատեր ամսվա ընթացքում սկզբում ստանում է ընդհանուր 200,000 փաստաթուղթ, ապա լսող հաճախորդներին հասնում է 8 միլիոն փաստաթղթային թարմացում։ Ենթադրենք՝ այդ ընթերցումները հավասարաչափ են բաշխված, գրառումները օրական անվճար շեմից ցածր են, ելքային տրաֆիկը 8 ԳԲ է, և Firestore-ի կանոնները կախյալ փաստաթուղթ չեն կարդում։ Սկզբնական ստացումները և թարմացումները միասին կազմում են 8.2 միլիոն Firestore ընթերցում։

Ամսվա օրական անվճար ընթերցումները հանելուց հետո վճարվողը 6.7 միլիոն է՝ մոտ $2.01։ Supabase-ում բազայի փոփոխության առաքումը յուրաքանչյուր լսող հաճախորդին առանձին realtime հաղորդագրություն է. նրա Realtime-ի հաշվարկում Pro-ն ներառում է ամսական 5 միլիոն հաղորդագրություն, իսկ ավելցուկը վճարվում է $2.50-ով յուրաքանչյուր սկսված միլիոնանոց փաթեթի համար։

Եթե պայմանական 8 միլիոն թարմացումից յուրաքանչյուրը մեկ առաքված Supabase հաղորդագրություն է, ներառված ծավալից դուրս են մնում 3 միլիոնը։ Դրանք ավելացնում են $7.50, և Pro-ի հաշիվը դառնում է $32.50՝ Micro-ի բավարար լինելու պայմանով։ Այս ծանրաբեռնվածությունում Firestore-ի նշված ծախսը ցածր է։ Իրական լսումների դեպքում վերամիացումները կարող են նորից վճարվող փաստաթղթեր կարդալ, իսկ կանոնի կախյալ ընթերցումներն ավելացնել Firestore-ի հաշիվը։

Որ տվյալների մոդելին որ գինն է համապատասխանում

Աղյուսակների միջև կապերով տվյալների համար Supabase-ի Postgres-ը տալիս է ընտրված compute-ի շուրջ կառուցված ծախսային հիմք։ Փաստաթղթերի ձևով բնականորեն ներկայացվող տվյալների դեպքում Firestore-ի գինը կարող է փոքր մնալ, եթե յուրաքանչյուր ցուցադրում քիչ փաստաթուղթ է կարդում և հարցումները տեղավորվում են անվճար օրական շեմում։ Երկու համակարգերի գինը նույն MAU թվով համեմատելը թաքցնում է ամենաազդեցիկ տարբերությունը՝ մեկ ցուցադրման համար կատարվող առանձին ընթերցումների թիվը։

Հաճախ կարդացվող feed-ի համար որոշիչ են նաև կանոնի կախյալ փաստաթղթերը և փոխանցվող բայթերը. realtime հավելվածում՝ առաքված թարմացումների ու վերամիացումների քանակը։ Supabase-ի կողմում գնի կանխատեսելիությունը պայմանավորված է ընտրված compute-ի բավարարությամբ և ներառված տրաֆիկով։ Այս սահմաններով փոքր MVP-ի, feed-ի ու realtime հավելվածի հաշվարկները տարբեր ընտրություն են տալիս՝ հենց այն պատճառով, որ նույն օգտագործումը երկու հարթակներում տարբեր միավորներով է վճարվում։

Կարդացեք նաև:

• Backblaze B2 թե Wasabi․ ջնջվող պահուստը կարող է շրջել ցածր գինը
• Supabase թե Firebase․ իրական ժամանակը, offline-ը և հաշիվը տարբեր հաղթողներ ունեն
• Clerk թե Auth0․ MRU-ն ու MAU-ն կարող են փոխել նույն լսարանի հաշիվը