Neon թե Supabase․ 23× արագ replica-ն դեռ ամբողջ ընտրությունը չի լուծում

Հրապարակված չափման մեջ Neon-ի ընթերցման կրկնօրինակի ստեղծումից մինչև առաջին SQL հարցումն ընկած ժամանակը 13 փորձի միջնարժեքով Supabase-ի համեմատ 23 անգամ կարճ էր։ Սա կրկնօրինակի գործարկման արդյունք է, ոչ թե արդեն աշխատող բազայի հարցումների արագության չափում։ Փորձարկման նախագծերը նույն AWS տարածաշրջանում էին, իսկ Supabase-ի ժամանակային վերականգնումը այդ փորձով չի չափվել։

Ընդհատվող բեռնվածությամբ բազայի և տվյալները ժառանգող բազմաթիվ փորձնական ճյուղերի համար Neon-ի կառուցվածքը հաճախ ավելի շահավետ է։ Մշտապես աշխատող API-ի դեպքում Supabase-ի փաթեթը կարող է ավելի հարմար լինել, եթե նախագծին միասին պետք են տվյալների բազա, պատրաստի API, նույնականացում և ֆայլերի պահեստ։ Կրկնօրինակի ստեղծման արագությունը վճռորոշ է այն թիմի համար, որն իրոք հաճախ է նոր ընթերցման հանգույցներ ավելացնում. մյուսների համար առավել կարևոր են աշխատած ժամերը, վերականգնման պատուհանը և ամբողջ backend-ի արժեքը։

Ճյուղավորումն ու անգործության վճարը

Neon-ի ճյուղը ժառանգում է ծնող բազայի տվյալները՝ առանց ամբողջ բազան նորից պատճենելու։ Ճյուղի գրած փոփոխությունները պահվում են առանձին, ուստի տվյալների մեծ հիմնական բազան ինքնին չի նշանակում նույն ծավալի պահեստի վճար յուրաքանչյուր preview միջավայրի համար։ Ընթերցման կրկնօրինակն էլ միանում է ընդհանուր պահեստին որպես առանձին հաշվարկային հանգույց։ Այս կառուցվածքը հատկապես տեղին է, երբ տարբեր փոփոխությունների համար պետք են մեկուսացված բազաներ՝ սկզբնական տվյալներով։

Neon-ի Launch գնացուցակում հաշվարկային հզորությունն արժե $0.106 մեկ CU-ժամի, պահեստը՝ $0.35 մեկ ԳԲ-ամսվա համար, իսկ նախագծում ներառված 10 ճյուղից ավելին՝ $0.002 յուրաքանչյուր լրացուցիչ ճյուղ-ժամի համար։ Անգործության ժամանակ բազայի compute-ը կարող է իջնել զրոյի, սակայն ճյուղի գոյության համար նախատեսված հավելավճարը կախված է նրա կյանքի տևողությունից։ Պահեստի հաշվարկում երեխա ճյուղի դեպքում մտնում են նրա փոփոխությունները, իսկ վերականգնման պատմությունը և այլ backend ծառայությունները կարող են առանձին ծախս ստեղծել։

Supabase-ի preview ճյուղը առանձին միջավայր է՝ իր բազայով և մյուս ծառայություններով։ Supabase-ի ճյուղավորման սակագինը լռելյայն Micro compute-ի համար սկսվում է $0.01344 մեկ ժամից. ճյուղի օգտագործած պահեստն ու տվյալների փոխանցումը նույնպես հաշվառվում են։ Այդ պատճառով կարճ ժամանակով ստեղծվող բազմաթիվ միջավայրերի դեպքում կարևոր են ոչ միայն դրանց աշխատանքի պահերը, այլև այն ժամերը, երբ դրանք շարունակում են գոյություն ունենալ։ Ճյուղերի միջև տվյալների տարբերությունն էլ էական է. հրապարակված փորձարկման Supabase ճյուղերը ստացել էին սխեման ու կարգավորումները, մինչ Neon-ի ճյուղերը ժառանգել էին ծնողի տվյալները։

Մշտապես աշխատող API-ն այլ հաշիվ ունի

Supabase-ի Pro առաջարկը սկսվում է ամսական $25-ից և ներառում է առանձնացված Postgres, միացումների կառավարում, ինքնաշխատ ստեղծվող REST ու GraphQL API-ներ և ամենօրյա պահուստավորում։ Նույն հարթակում հասանելի են Auth, Storage, Edge Functions և Realtime ծառայությունները։ Եթե հավելվածն այդ բաղադրիչներից մի քանիսի կարիքն ունի, թիմը կարող է դրանք կառավարել նույն նախագծում և առանձին ծառայությունների միացման ավելի քիչ աշխատանք ունենալ։

Neon-ն այժմ նույնպես առաջարկում է Managed Better Auth, Object Storage և Functions։ Հետևաբար տարբերությունը պարզապես «բազա ընդդեմ ամբողջ backend-ի» չէ. պետք է համեմատել հենց օգտագործվող հնարավորությունները, դրանց սահմանաչափերը և առանձին հաշվարկվող ռեսուրսները։ Neon-ի CU-ժամը չափում է Postgres-ի հաշվարկային հզորությունը, ոչ թե այդ բոլոր ծառայությունների օգտագործումը։ Supabase-ի ամսական մեկնարկային վճարն էլ վերջնական հաշիվ չէ, եթե պետք են լրացուցիչ compute, preview ճյուղեր կամ վճարովի հավելումներ։

Մշտական արտադրական բեռնվածության դեպքում Neon-ի զրոյի իջնելու առավելությունը կարող է հազվադեպ գործել. միացումները կամ շարունակական հարցումները բազան ակտիվ են պահում։ Supabase Pro-ի միշտ հասանելի բազան այդպիսի աշխատանքի համար կանխատեսելի ելակետ է, բայց նույն ամսական գինը տարբեր հզորության բազաների հավասար արժեք չի նշանակում։ Ընտրության համար պետք է համադրել պահանջվող բազայի չափը և այն ծառայությունները, որոնք հավելվածն իսկապես օգտագործելու է։

Վերականգնումը չի չափվում replica-ի արագությամբ

Neon-ում անցյալ պահի վիճակը կարելի է ստանալ ճյուղի միջոցով և ուսումնասիրել՝ առանց գործող ճյուղի տվյալները անմիջապես փոխելու։ Վերականգնման հասանելի պատմությունը կախված է ընտրված պատուհանից, իսկ դրա պահեստային ծախսը՝ այդ ընթացքում գրանցված փոփոխությունների ծավալից։ Շատ գրառումներով բազայի համար նույն տևողությամբ պատուհանը կարող է այլ արժեք ունենալ, քան հազվադեպ փոփոխվող բազայի համար։

Supabase-ի PITR սակագնով յոթօրյա վերականգնման պատուհանը վճարովի հավելում է՝ մոտ $100, եթե միացված է ամբողջ ամիս, և հաշվարկվում է ակտիվ ժամերով։ Pro պլանի ամենօրյա պահուստավորումը նույն հնարավորությունը չէ. PITR-ը թույլ է տալիս վերադառնալ ընտրված պահի։ Եթե սխալ միգրացիայից կամ տվյալների պատահական փոփոխությունից հետո կարևոր է վերականգնել կոնկրետ պահը, այդ հավելումը պետք է մտնի Supabase-ի ընդհանուր արժեքի մեջ։

Կրկնօրինակի գործարկումը և անցյալ վիճակի վերականգնումը տարբեր գործողություններ են։ Առաջինը նոր ընթերցման հզորություն է տալիս գործող տվյալների համար, երկրորդը վերադարձնում է նախկին վիճակը։ Հրապարակված չափումը Neon-ի restore-ի գործողություն ունի, բայց Supabase-ի PITR-ի տևողությունը չի չափում, ուստի դրանից երկու հարթակների վերականգնման արագության ընդհանուր հաղթող չի ստացվում։

Երեք պայմանական ծանրաբեռնվածության հաշիվ

Հանգիստ prototype. Ենթադրենք՝ վճարովի Neon Launch բազան ամսվա ընթացքում ընդհանուր աշխատում է 60 ժամ՝ միջինը 0.25 CU հզորությամբ, և պահում է մեկ ԳԲ տվյալ։ Դա կազմում է 15 CU-ժամ կամ մոտ $1.59 compute-ի վճար. պահեստի $0.35-ի հետ բազայի ամսական արժեքը մոտ $1.94 է։ Ենթադրության մեջ աշխատանքային ժամերն արդեն ներառում են այն ժամանակը, մինչև անգործության պատճառով compute-ը դադարում է աշխատել։ Անվճար պլանի սահմաններում տեղավորվող նախագիծը կարող է ընդհանրապես չհասնել այս վճարովի հաշվարկին։

Մշտական production API. Ենթադրենք՝ Neon-ի բազան 730-ժամանոց ամսվա ամբողջ ընթացքում միջինը մեկ CU է օգտագործում և պահում է հինգ ԳԲ տվյալ։ Այդ դեպքում compute-ը մոտ $77.38 է, պահեստը՝ $1.75, միասին՝ մոտ $79.13 ամսական՝ առանց այլ ծառայությունների։ Supabase Pro-ի $25 մեկնարկը փոքր է թվում, հատկապես եթե պատրաստի API-ն ու Auth-ը նույնպես պետք են։ Սակայն սա հավասար հզորության մեքենաների գների համեմատություն չէ. Supabase-ի անհրաժեշտ compute-ը, հավելումների սպառումը և Neon-ի մյուս ծառայությունները պետք է հաշվվեն ըստ նույն հավելվածի պահանջների։

Բազմաթիվ preview ճյուղեր. Ենթադրենք՝ հիմնական բազայի կողքին միաժամանակ բացվում են 12 փորձնական ճյուղեր, յուրաքանչյուրը գոյություն ունի 72 ժամ, բայց նրա compute-ը հաշվառվում է ընդամենը երկու ժամ՝ միջինը 0.25 CU հզորությամբ։ Neon Launch-ում դրանց compute-ը մոտ $0.64 է։ Հիմնական ճյուղի հետ միասին ներառված քանակը գերազանցում են երեք ճյուղեր, որոնց 72-ժամյա հավելավճարը մոտ $0.43 է. ստացվում է մոտ $1.07՝ առանց պահեստի, հիմնական բազայի և այլ ծառայությունների։ Նույն 12 միջավայրի համար Supabase-ի լռելյայն Micro compute-ի 72-ժամյա վճարը մոտ $11.61 կլինի՝ Pro պլանից ու մյուս օգտագործված ռեսուրսներից բացի։

Այս պայմանական թվերը ցույց են տալիս ծախսի տարբեր շարժիչները։ Neon-ի preview ճյուղի compute-ի վճարը մեծանում է նրա փաստացի աշխատած ժամերով, իսկ ներառված քանակից ավել ճյուղի հավելավճարը՝ գոյության ժամերով։ Supabase-ի առանձին preview միջավայրը կարող է նաև Auth ու Storage ունենալ, ինչը արժեք է, եթե հենց այդ ծառայություններն են պետք փորձարկմանը։ Եթե թիմը ճյուղերը շուտ է ջնջում կամ դրանցում մշտական աշխատանք է կատարում, հաշվարկի հարաբերությունը փոխվում է։

Որ տարբերակն է համապատասխանում նախագծին

Հաճախ ստեղծվող, տվյալները ժառանգող ճյուղերով և երկար հանգիստ շրջաններով նախագծի համար Neon-ը լավ է համընկնում աշխատանքի ռիթմին։ Մշտապես գործող հավելվածի համար Supabase-ը կարող է պարզեցնել ընտրությունը, երբ Postgres-ի հետ միասին պետք են պատրաստի API, Auth և Storage։ Վերականգնումը պարտադիր պահանջ լինելու դեպքում առանձին գնահատման արժանի են պատմության տևողությունն ու PITR-ի վճարը։ Նույն նախագծի համար որոշիչ հաշիվը կազմվում է բազայի ակտիվ ժամերից, ճյուղերի կյանքի տևողությունից, տվյալների փոփոխության ծավալից և օգտագործվող backend ծառայություններից։

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

• Fathom թե Fireflies․ անվճար գրառումը չի լուծում լեզվի ու որոնման ընտրությունը
• Supabase թե Firebase․ իրական ժամանակը, offline-ը և հաշիվը տարբեր հաղթողներ ունեն
• DeepL թե Google Translate․ 94% հաղթանակը չի լուծում ձևաչափերի ընտրությունը