Supabase ці Firebase: прадказальны рахунак сутыкаецца з аплатай за чытанні

Калі праекту патрэбныя звязаныя табліцы і магчымасць размясціць бэкенд самастойна, выбар схіляецца да Supabase. Калі даныя натуральна ўкладваюцца ў дакументы, Firebase з Cloud Firestore можа падысці лепш, але кошт трэба прагназаваць па чытаннях дакументаў, а не па колькасці карыстальнікаў. У тарыфах Supabase API-запыты не маюць асобнай платы: бясплатны план уключае базу на 500 МБ і 5 ГБ зыходнага трафіку, а Pro пачынаецца ад $25 за месяц, уключае 250 ГБ такога трафіку і ацэньвае перавышэнне ў $0,09 за ГБ.

У правілах аплаты Cloud Firestore для адной базы праекта прадугледжаны бясплатныя 50 000 чытанняў і 20 000 запісаў дакументаў за дзень, 1 ГіБ сховішча і 10 ГіБ зыходнага трафіку за месяц. Дзённая квота абнаўляецца каля поўначы паводле ціхаакіянскага часу. На плане Blaze выкарыстанне звыш бясплатнай квоты аплачваецца паводле факту; гэта і ёсць галоўнае адрозненне ў прадказальнасці рахунку, калі чытанні растуць.

Сцэнар: 50 тысяч чытанняў за дзень

Умоўны праект штодня чытае роўна 50 000 дакументаў Firestore з адной базы і не выконвае іншых аплатных чытанняў. Ён укладваецца ў дзённую квоту па гэтай аперацыі. За ўмоўныя 30 дзён набярэцца 1,5 млн чытанняў, але месячная сума тут не вызначае плату: ліміт прымяняецца асобна да кожнага дня, а нявыкарыстаны запас не пераносіцца на наступны.

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

У Supabase гэтыя ж наведванні не ператвараюцца ў плату за лік API-запытаў. Аднак PostgreSQL усё роўна апрацоўвае нагрузку, а адказы ствараюць зыходны трафік. Пры невялікіх адказах вырашальнай можа стаць патрэбная магутнасць базы; пры вялікіх — аб’ём перададзеных даных. Таму надпіс «неабмежаваныя API-запыты» апісвае адзінку аплаты, а не неабмежаваныя вылічальныя рэсурсы.

Сцэнар: нагрузка выйшла за бясплатную квоту

Умоўна, праект на Blaze пачаў рабіць 80 000 чытанняў дакументаў Firestore штодня. Калі іншых чытанняў няма, перавышэнне складае 30 000 за дзень, або 900 000 за ўмоўныя 30 дзён роўнай нагрузкі. Грашовую суму толькі з гэтага ліку вызначыць нельга: цана залежыць ад размяшчэння базы, а агульны рахунак — таксама ад запісаў, сховішча і трафіку.

У Supabase аналагічны рост трэба перавесці ў патрэбную магутнасць PostgreSQL і аб’ём перадачы. Умоўны разлік для аднаго праекта Pro на ўключанай вылічальнай магутнасці: калі звычайны зыходны трафік складае 300 ГБ за месяц, перавышэнне ўключанага аб’ёму роўнае 50 ГБ. Пры выключаным абмежаванні дадатковых выдаткаў гэта $4,50 звыш падпіскі, разам $29,50, калі астатнія квоты не перавышаны. У Pro такое абмежаванне ўключана па змаўчанні, таму без яго выключэння гэты разлік не апісвае рэжым працы праекта.

Параўнанне гэтых прыкладаў не дае ўніверсальнага пераможцу па цане. Шмат дробных чытанняў павялічваюць улік Firestore, тады як менш частыя, але цяжкія запыты могуць запатрабаваць больш магутнай базы ў Supabase. Для прагнозу важныя рэальныя запыты, памер адказаў і тое, як нагрузка размяркоўваецца на працягу дня.

Сцэнар: даныя становяцца рэляцыйнымі

Калі заказы, пазіцыі заказаў і тавары павінны мець устойлівыя сувязі, PostgreSQL у Supabase дазваляе вынесці іх у асобныя табліцы, звязаць ключамі і сабраць патрэбную выбарку запытам. Такая схема дапамагае падтрымліваць цэласнасць даных, але патрабуе прадуманых табліц і індэксаў. Яе карысць расце, калі розныя часткі праграмы часта звяртаюцца да адных і тых жа звязаных сутнасцей.

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

Што каштуе пераезд з дакументаў у PostgreSQL

Умоўны перанос запушчанага праекта з Firestore у Supabase патрабуе больш працы, чым капіраванне запісаў. Каманда вызначае табліцы і ключы, ператварае ўкладзеныя аб’екты і падкалекцыі ў патрэбныя сувязі, захоўвае адпаведнасць ідэнтыфікатараў і правярае вынікі запытаў. Калі старая база працягвае прымаць змены, на час пераезду патрэбны яшчэ і спосаб не страціць гэтыя змены.

Змяняецца код доступу да даных, а правілы доступу трэба прыстасаваць да новай схемы. Асобнай працы могуць запатрабаваць аўтэнтыфікацыя і файлы, калі праект выкарыстоўвае іх разам з базай. Аб’ём міграцыі залежыць ад колькасці сувязяў і месцаў у праграме, дзе выкарыстоўваюцца дакументы; бясплатны тарыф на старце гэтых будучых выдаткаў не паказвае. Для выразна рэляцыйнага праекта ранні выбар PostgreSQL можа зэканоміць такую перабудову.

Калі патрабуецца самастойнае размяшчэнне

Калі праект павінен працаваць ва ўласнай інфраструктуры, Supabase мае афіцыйны шлях разгортвання на ўласным серверы або ў выбраным воблаку. Дакументацыя Supabase па самастойным размяшчэнні ускладае на каманду абнаўленні, бяспеку, абслугоўванне PostgreSQL, рэзервовыя копіі, маніторынг і аднаўленне пасля збояў. Кіраваныя рэзервовыя копіі і аднаўленне да зададзенага моманту ў такім разгортванні недаступныя.

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

Рызыка аўтаматычнага пераходу на Blaze

План Firebase можа змяніцца і пасля дзеяння па-за кансоллю Firebase. Правілы Firebase для Spark і Blaze прадугледжваюць аўтаматычны пераход на Blaze пры прывязцы Cloud Billing праз кансоль Google Cloud або выкарыстанні ў тым жа праекце сэрвісаў Google Cloud ці Google Maps API, якім патрэбны білінгавы рахунак. Бясплатныя квоты для платных прадуктаў на Blaze захоўваюцца, а перавышэнне аплачваецца паводле выкарыстання.

Гэтая сувязь істотная для праекта, які спалучае Firestore з іншымі сэрвісамі Google: падключэнне новага сэрвісу можа адначасова змяніць рэжым аплаты базы. Бюджэтныя папярэджанні паведамляюць пра выдаткі, але самі па сабе не спыняюць іх. Таму пры выбары Firebase варта лічыць чытанні на ўзроўні дакументаў і ўлічваць, якія іншыя магчымасці будуць уключаны ў тым самым праекце.

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

• Todoist ці TickTick: хуткі ўвод сутыкаецца з календаром і звычкамі
• Toggl ці Harvest: аднолькавыя $9, але рахунак ёсць толькі ў аднаго
• Stripe ці Paddle: таннейшая аплата пакідае падаткі заснавальніку