Neon ці Supabase: хуткая галінка прайграе поўнай backend-платформе

Neon зручнейшы, калі для кожнага pull request патрэбна галінка Postgres з данымі бацькоўскай базы, а нагрузка мае доўгія паўзы. Supabase лепш падыходзіць, калі ў preview і production разам з базай патрэбныя Auth, Storage і Realtime: галінка там уяўляе сабой асобнае асяроддзе для прыкладання. У такім сцэнары хутчэйшае стварэнне базы само па сабе не вырашае задачу.

Для выбару важныя тры розныя выдаткі: час да гатоўнасці галінкі, плата за яе жыццё паміж праверкамі і праца па падрыхтоўцы астатніх службаў. Калі production-база занятая амаль увесь час, эканомія Neon ад спынення вылічэнняў памяншаецца. Калі ж правяраюцца толькі SQL-запыты і міграцыі, поўнае асяроддзе Supabase можа аплачвацца за магчымасці, якія ў гэтай праверцы не выкарыстоўваюцца.

Што атрымлівае галінка ў кожным сэрвісе

Паводле інструкцыі Neon пра галінкаванне, ізаляваная галінка наследуе схему і даныя бацькоўскай базы, атрымлівае ўласны радок падключэння і ствараецца прыкладна за секунду незалежна ад памеру базы. Таму праверку міграцыі можна запускаць на стане даных, блізкім да асноўнай базы, без асобнага аднаўлення дампа перад кожным pull request. Змены ў галінцы не змяняюць бацькоўскую базу; пасля закрыцця запыту часовую галінку можна выдаліць.

Гатовая копія даных падыходзіць не для кожнай каманды. Калі ў асноўнай базе ёсць адчувальныя запісы, Neon дазваляе стварыць галінку толькі са схемай і напоўніць яе падрыхтаванымі тэставымі данымі. Гэта мяняе сэнс праверкі: міграцыя будзе працаваць на сапраўднай структуры табліц, але паводзіны запытаў на вялікім або нераўнамерным наборы даных давядзецца ацэньваць асобна. Для праверкі толькі SQL такі кампраміс можа быць прымальным; для поўнага карыстальніцкага сцэнарыя патрэбна яшчэ і асяроддзе астатніх службаў.

Дакументацыя Supabase па галінках апісвае іншы склад preview: асобны экземпляр з уласнымі API-дадзенымі, наладамі Auth, Data API, Realtime і Storage ды разгорнутымі Edge Functions. Схема базы аднаўляецца з міграцый, а даныя і файлы асноўнага праекта па змаўчанні не пераносяцца. Для даных пры інтэграцыі з GitHub служыць seed-файл; пры стварэнні галінкі праз панэль ёсць опцыя ўключыць даныя. Сакрэты Auth, у тым ліку параметры знешніх правайдараў, патрабуюць асобнай налады для галінкі.

Гэтая розніца важная пры праверцы ўваходу карыстальніка, правоў доступу да файлаў і падзей у рэальным часе. У Supabase патрэбныя службы ўваходзяць у склад preview-асяроддзя, але яго даныя і сакрэты трэба падрыхтаваць. Neon таксама прапануе Managed Better Auth, Object Storage і Functions, таму называць яго выключна базай даных было б недакладна. Перавага Supabase для такога сцэнарыя — у складзе звязанага асяроддзя з Realtime, а не ў адсутнасці backend-магчымасцяў у канкурэнта.

Хуткасць галінкі і межы тэсту

У апублікаваным тэставанні аднолькавы набор даных аб’ёмам каля 5,1 ГБ аднавілі ў абодвух сэрвісах; пры трох паралельных стварэннях галінкаў сярэдні час да паспяховага SELECT 1 склаў 1,84 с у Neon і 5,09 с у Supabase. Базы і тэставы працэс знаходзіліся ў адным рэгіёне AWS, падключэнні ішлі праз пулы злучэнняў абодвух сэрвісаў. Асобная серыя чытання Drizzle працягвалася каля 24 гадзін і чаргавала працу з паўзамі.

Метрыка SELECT 1 адказвае на вузкае пытанне: калі новае падключэнне да Postgres пачынае прымаць просты запыт. Яна не вымярае момант, калі ў Supabase будуць гатовыя Auth, Storage і Realtime, і не паказвае час падрыхтоўкі даных для праверкі прыкладання. Таму розніцу ў секундах карысна ўлічваць для частых аўтаматычных SQL-тэстаў, але яна не роўная розніцы ў часе да гатовага preview.

Серыя чытання не дала аднаго пераможцы па затрымцы: частка запытаў выконвалася хутчэй у Supabase, частка — у Neon. Сэрвісы ў тэсце працавалі з аднолькавымі лагічнымі данымі, але з рознымі памерамі і мадэлямі вылічальных рэсурсаў. Выснова пра хуткасць канкрэтнага прыкладання таму залежыць ад яго запытаў, патрабаванняў да памяці і таго, ці трапляе нагрузка на момант абуджэння неактыўнай базы.

Кошт у трох сцэнарыях

Невялікі праект з доўгімі паўзамі

Тарыфная табліца Neon дае бясплатнаму праекту 1 ГБ базы і 100 CU-гадзін за месяц; у платным Launch вылічэнні каштуюць $0,106 за CU-гадзіну, а захоўванне базы — $0,35 за ГБ у месяц. Калі вылічэнні спыняюцца паміж запытамі, гэтыя паўзы не расходуюць CU-гадзіны. Захоўванне даных, гісторыя змяненняў і выкарыстанне дадатковых службаў маюць асобныя ўмовы аплаты, таму нізкая плата за вылічэнні не азначае нулявы рахунак.

Умоўны праект з 1 ГБ даных, сярэдняй магутнасцю 0,25 CU і 60 гадзінамі працы за месяц выдаткуе на вылічэнні Launch $1,59, а на базавае захоўванне — $0,35. Разам гэта каля $1,94 да іншых складнікаў рахунку. Прыклад паказвае механізм аплаты за перарывістае выкарыстанне, а не прагназуе выдаткі рэальнага прыкладання: яго сярэдняя магутнасць, змены даных і працягласць працы могуць быць іншымі.

Preview на кожны pull request

Згодна з правіламі аплаты Supabase, кожная preview-галінка спажывае рэсурсы асобнага асяроддзя, уключаючы Compute, Disk Size, Egress і Storage; Micro Compute пачынаецца з $0,01344 за гадзіну, а крэдыты на вылічэнні не пакрываюць Branching Compute. Умоўныя пяць галінкаў, якія існуюць па 48 гадзін, дадуць каля $3,23 толькі за іх Micro Compute. Перадача даных, файлы і выкарыстанне дыска могуць дадаць выдаткі.

У Neon вылічэнні неактыўнай галінкі могуць спыняцца, а платны план уключае пэўную колькасць адначасовых галінкаў без асобнай платы за час іх існавання. Пасля перавышэння ліміту час дадатковых галінкаў аплачваецца; запісаныя ў іх змены і доўгая гісторыя таксама ўплываюць на кошт захоўвання. Таму для каманды з частымі pull request істотныя не толькі колькасць створаных галінкаў, але і тое, колькі з іх існуе адначасова, як доўга яны жывуць і колькі даных змяняюць тэсты.

Пастаянная production-нагрузка

Калі база адказвае на запыты амаль без паўз, Neon назапашвае CU-гадзіны на працягу ўсяго гэтага часу. У канфігурацыі Supabase з вылучаным Compute рэсурсы застаюцца даступнымі паміж запытамі, што прыбірае чаканне абуджэння і дазваляе трымаць буферную памяць прагрэўшай. Кошт тут залежыць ад абранага памеру рэсурсаў і астатняга выкарыстання платформы; перавага хуткай галінкі мала кажа пра рахунак або затрымку production-запытаў.

Нават пры аднолькавых лагічных запісах рахункі не становяцца непасрэдна параўнальнымі: сэрвісы па-рознаму ўлічваюць вылічэнні, месца пад гісторыю і службовыя даныя, перадачу трафіку ды файлы. Для прыкладання, дзе ўваход карыстальніка, сховішча і падзеі ў рэальным часе сапраўды патрэбныя ў production і preview, Supabase можа апраўдаць большы кошт асяроддзя меншай працай па звязванні службаў. Калі гэтыя службы ўжо арганізаваны асобна, Neon захоўвае свой галоўны аргумент — хуткія ізаляваныя базы і аплату вылічэнняў паводле фактычнай працы.

Чытайце таксама:

• Supabase ці Firebase: прадказальны рахунак сутыкаецца з аплатай за чытанні
• RPA ці ШІ-агент: гнуткасць прайграе на стабільных аперацыях
• Чарга на мяжы пераедзе ў праграму — але платформы яшчэ не названыя