Neon или Supabase: мирувањето штеди, постојаниот товар ја менува сметката

20 октомври 2026 г., во 05:00|Автор: Уредувачки тим на QUASA|6 мин. читање

За SaaS-база со долги мирни периоди, Neon може да ја намали сметката бидејќи го запира пресметковниот ресурс и не наплатува CU-часови додека тој е исклучен. Ценовникот на Neon наведува автоматско запирање по пет минути неактивност на планот Launch, со можност тоа да се исклучи, и цена од 0,106 долари за CU-час. Ако барањата пристигнуваат постојано, ресурсот останува активен и предноста од мирувањето се намалува.

Supabase има поинаква основа за пресметка. Ценовникот на Supabase го поставува Pro на 25 долари месечно, со пресметковен кредит што покрива еден Micro-проект и вклучени квоти за база, излезен сообраќај и месечно активни корисници. Затоа споредбата за постојан SaaS-товар зависи од потребниот капацитет и користењето на дополнителните услуги, а не само од цената на претплатата или од бесплатниот план.

Латентноста и студениот старт мерат различни работи

За едноставно SQL-барање, измерената разлика меѓу услугите била мала. Во независното мерење на DevOps Daily од јуни 2026 година, медијаната за ново поврзување, TLS, автентикација и едно барање била околу 32 ms кај двете услуги. Во истиот сет тестови, времето од создавање нов проект до првото успешно барање било 5,5 секунди за Neon и 111,9 секунди за Supabase; за будење на веќе создаден, суспендиран Neon-ресурс биле измерени медијана од 593 ms и p95 од 1,56 секунди.

Овие резултати одговараат на различни прашања. Создавањето проект влијае врз автоматското отворање околини, додека будењето на база може да го почувствува првиот корисник по пауза. Тестот користел проекти во ист AWS-регион и клиент во Франкфурт, што ја прави споредбата контролирана, но не го претставува целото време на одговор на апликација во Северна Македонија. Не ги вклучува нејзиниот API, вистинските SQL-прашања и патеката од крајниот корисник. За корисничка функција чувствителна на доцнење по мирување, опашката на времињата при будење е поважна од медијаната на едноставно барање до активна база.

Каде оди месечната сметка

Кај Neon, пресметувањето се добива со множење на просечната големина на активниот ресурс, изразена во CU, со часовите во кои работи. Просторот за база, задржаната историја за обновување, дополнителните гранки над вклучениот број и излезниот сообраќај се одделни ставки. Тоа му одговара на проект со ретки пристапи: долгата пауза не создава нови CU-часови, иако податоците остануваат складирани. Кај постојан товар, пресметковната ставка расте со големината на ресурсот во текот на целиот месец.

Кај Supabase Pro, основната претплата и пресметковниот кредит даваат почетна рамка за еден Micro-проект. Поголем ресурс, дополнителен проект или потрошувачка над вклучените квоти ја менуваат таа рамка. Во квотите влегуваат 8 GB простор за база по проект, 250 GB излезен сообраќај и 100.000 месечно активни корисници; над последната граница стапката е 0,00325 долари по корисник. Кредитот за пресметување и квотата за корисници покриваат различни ресурси, па едната ставка не го поништува растот на другата.

Гранките не создаваат иста тест-околина

Гранка на Neon може да ја наследи состојбата на податоците од родителската база преку заедничко складирање. Тоа е корисно за тест што зависи од постојни записи, но гранката сепак може да троши пресметковни ресурси кога работи и простор кога нејзините податоци се менуваат. Задржувањето на историјата за обновување исто така влегува во сметката. За тим што создава многу краткотрајни гранки, важни се истовремениот број гранки и времето во кое секоја останува активна.

Документацијата за гранките на Supabase наведува дека нова гранка стандардно започнува без продукциските податоци и складираните објекти, но со посебна околина и преземени поставки. Податоци може да се додадат со seed-датотека или со опцијата Include data при создавање преку контролната табла. Затоа тест со стандардна гранка на Supabase и тест со гранка на Neon што ги носи записите од родителската база не започнуваат со иста содржина. Ако тестот бара репрезентативни записи, начинот на нивно внесување е дел од оперативната споредба.

Разликата се гледа и во наплатата. Правилата за наплата на Supabase Preview-гранки наведуваат дека Micro-гранка почнува од 0,01344 долари на час, а може да троши и простор и излезен сообраќај; пресметковниот кредит од планот не важи за пресметувањето на гранката. Кратка тест-околина и гранка оставена да работи цел месец затоа носат различен трошок, дури и кога основниот проект не се менува.

Три профили на SaaS-проект

Повремен проект. Развојна алатка, демонстрација или мала апликација со ретки пристапи има најголема корист од можноста пресметувањето да запре меѓу налетите. За ваков профил Neon е разумна почетна економска процена, особено ако тестовите користат гранки со постојни податоци. Цената на таа заштеда е можноста првото барање по пауза да почека ресурсот да се разбуди. Supabase може да одговара кога проектот во истата околина ги користи неговите Auth, Storage и API-можности; изборот тогаш опфаќа повеќе од PostgreSQL.

Стабилен SaaS. Кога барањата пристигнуваат во текот на целиот ден, ресурсот ретко стигнува да мирува. Како условен пример, просечни 0,25 CU што работат 730 часа создаваат 182,5 CU-часови, односно околу 19,35 долари за пресметување на Neon Launch пред простор, историја и други услуги. Тоа е аритметика според објавената стапка, а не предвидување за конкретна апликација. Наспроти неа стои Supabase Pro со вклучен Micro-ресурс; ако на апликацијата ѝ треба поголем капацитет, и таа страна од пресметката расте. Двата најмали ресурси не треба да се сметаат за еднакви по перформанси само затоа што нивните месечни износи изгледаат блиски.

Апликација со многу auth-корисници. Кај производ со мала база и голем број најавувања, автентикацијата може да стане поголема ставка од самото пресметување на базата. Условно, 150.000 месечно активни корисници на Supabase Pro значат 50.000 над вклучената квота, или 162,50 долари дополнително според наведената стапка. Neon го вклучува Managed Better Auth без дополнителна наплата по активен корисник до прагот од еден милион на платените планови, додека базата, функциите и преносот имаат свои мерни единици. Функциите за автентикација не се целосно заменливи: потребниот начин на најавување, управувањето со сесии и интеграцијата со апликацијата остануваат дел од архитектонскиот избор.

За избор меѓу услугите, најкорисна е месечна пресметка со ист профил на товар: активни часови и потребна големина на базата, простор, излезен сообраќај, број и траење на гранките и активни корисници. Кај повремен проект мирувањето може да биде пресудно; кај постојан SaaS и производ со многу корисници, поголема тежина добиваат вклучените квоти и дополнителните ставки. Латентноста треба да се оцени за конкретната корисничка патека, особено ако првото барање по пауза е видливо за корисникот.

Прочитајте и:

Сподели: