
Firebase ή Supabase: το δωρεάν backend μπορεί να γεννήσει απρόβλεπτο λογαριασμό

Το Firebase μπορεί να είναι η φθηνότερη επιλογή για μια εφαρμογή με περιορισμένη χρήση, αλλά ο λογαριασμός του Firestore μεγαλώνει μαζί με τις αναγνώσεις και την εξερχόμενη κίνηση. Τα όρια του Firebase για το Cloud Firestore Standard περιλαμβάνουν 50.000 δωρεάν αναγνώσεις και 20.000 εγγραφές την ημέρα, 1 GiB δεδομένων και 10 GiB εξερχόμενης κίνησης τον μήνα· στο πρόγραμμα Blaze, η χρήση πέρα από τα όρια χρεώνεται. Έτσι, ίδιος αριθμός χρηστών μπορεί να δώσει πολύ διαφορετικό κόστος αν αλλάξει ο τρόπος που χρησιμοποιούν την εφαρμογή.
Το Supabase ταιριάζει συχνότερα σε SaaS που χρειάζεται PostgreSQL και θέλει μια γνωστή μηνιαία αφετηρία, χωρίς όμως να έχει αμετάβλητο πάγιο. Ο τιμοκατάλογος του Supabase δίνει στο Free βάση 500 MB ανά έργο και 5 GB εξερχόμενης κίνησης, ενώ το Pro ξεκινά από $25 τον μήνα, με 8 GB δίσκου ανά έργο, 250 GB εξερχόμενης κίνησης και πίστωση $10 για compute. Ο αριθμός των ενεργών έργων και το μέγεθος compute μπορούν επομένως να αλλάξουν τη σύγκριση όσο και η κίνηση.
Το δωρεάν όριο μετρά διαφορετικά στις δύο υπηρεσίες
Στο Firestore, οι δωρεάν αναγνώσεις και εγγραφές υπολογίζονται ανά ημέρα. Μια ήσυχη ημέρα δεν προσθέτει αχρησιμοποίητες αναγνώσεις στο όριο της επόμενης, γι’ αυτό ένας μηνιαίος μέσος όρος μπορεί να κρύβει ημέρες με χρέωση. Η αποθήκευση και η εξερχόμενη κίνηση έχουν διαφορετικό χρονικό ορίζοντα. Για την πρόβλεψη κόστους χρειάζονται, συνεπώς, ημερήσιες πράξεις και μηνιαίος όγκος δεδομένων, όχι μόνο ο αριθμός εγγεγραμμένων χρηστών.
Στο Supabase, το Free έχει περιορισμούς που επηρεάζουν μια εφαρμογή παραγωγής ακόμη κι αν η βάση της είναι μικρή: τα ανενεργά δωρεάν έργα παύουν έπειτα από μία εβδομάδα και ο αριθμός ενεργών δωρεάν έργων είναι περιορισμένος. Στο Pro, ο περιλαμβανόμενος δίσκος αναφέρεται ανά έργο, ενώ η εξερχόμενη κίνηση και η πίστωση compute πρέπει να αντιμετωπίζονται ως όρια του οργανισμού. Δεν αρκεί επομένως να πολλαπλασιαστεί η τιμή της συνδρομής με τον αριθμό των βάσεων.
Εφαρμογή με πολλές αναγνώσεις: πού αλλάζει η τιμή
Μια οθόνη Firestore μπορεί να διαβάσει πολλά έγγραφα για έναν μόνο χρήστη. Οι ενημερώσεις σε πραγματικό χρόνο χρεώνουν νέα ανάγνωση όταν προστίθεται ή ενημερώνεται έγγραφο στο αποτέλεσμα. Με ενεργή τοπική αποθήκευση, επανασύνδεση μετά από παρατεταμένη αποσύνδεση μπορεί να ξαναχρεώσει το αποτέλεσμα σαν νέο ερώτημα· χωρίς αυτήν, η επανασύνδεση μπορεί να το κάνει κάθε φορά. Ορισμένες αναγνώσεις ευρετηρίων και έγγραφα που απαιτούν οι κανόνες πρόσβασης προσθέτουν επίσης πράξεις.
Για ένα διαφανές αριθμητικό παράδειγμα, ο πίνακας Firestore Standard δίνει για την περιοχή us-central1 $0,03 ανά 100.000 αναγνώσεις και $0,09 ανά 100.000 εγγραφές πέρα από το δωρεάν όριο, ενώ η εξερχόμενη κίνηση προς ευρωπαϊκούς προορισμούς χρεώνεται $0,12 ανά GiB στο πρώτο κλιμάκιο μετά τα 10 GiB. Η θέση της βάσης επηρεάζει τις τιμές των πράξεων. Το παράδειγμα χρησιμοποιεί την us-central1 για να είναι ελέγξιμη η αριθμητική, όχι ως σύσταση τοποθεσίας για εφαρμογή στην Ελλάδα ή την Κύπρο.
Ας υποθέσουμε 10.000 ενεργούς χρήστες, με 100 αναγνώσεις και δύο εγγραφές ο καθένας ημερησίως, επί 30 ημέρες. Αυτό δίνει 30 εκατομμύρια αναγνώσεις και 600.000 εγγραφές. Αν η βάση καταλαμβάνει 0,8 GiB και στέλνει 15 GiB προς τους χρήστες, οι εγγραφές και η αποθήκευση μένουν εντός των δωρεάν ορίων. Με ομοιόμορφη ημερήσια χρήση, 1,5 εκατομμύριο αναγνώσεις καλύπτονται δωρεάν· οι υπόλοιπες κοστίζουν $8,55. Η επιπλέον κίνηση κοστίζει $0,60, άρα το υποθετικό σύνολο γι’ αυτά τα στοιχεία είναι $9,15.
Αν οι ίδιοι χρήστες κάνουν 300 αναγνώσεις την ημέρα και η μηνιαία κίνηση φθάσει τα 45 GiB, οι 90 εκατομμύρια αναγνώσεις αφήνουν 88,5 εκατομμύρια χρεώσιμες. Το κόστος αναγνώσεων γίνεται $26,55 και της επιπλέον κίνησης $4,20: συνολικά $30,75. Αυτή είναι η συνέπεια που μπορεί να φέρουν περισσότερα έγγραφα ανά οθόνη, συχνότερες αλλαγές σε ζωντανά αποτελέσματα ή επανασυνδέσεις, χωρίς αύξηση χρηστών. Με τα ίδια δεδομένα αποθήκευσης, το Supabase Pro θα ξεκινούσε από $25 για ένα έργο Micro, εφόσον το έργο επαρκεί σε απόδοση και η υπόλοιπη χρήση μένει στα περιλαμβανόμενα όρια. Οι αναγνώσεις εγγράφων Firestore δεν ισοδυναμούν αυτομάτως με ερωτήματα ή γραμμές PostgreSQL, οπότε τα ποσά συγκρίνουν μοντέλα χρέωσης, όχι ίδια απόδοση.
SaaS με PostgreSQL: το πρόσθετο έργο έχει δικό του compute
Ας εξετάσουμε ξεχωριστά ένα υποθετικό SaaS με 3.000 ενεργούς χρήστες, 30 αναγνώσεις και πέντε εγγραφές ανά χρήστη την ημέρα, για 30 ημέρες. Αν αυτές ήταν πράξεις Firestore κατανεμημένες ομοιόμορφα, οι χρεώσιμες αναγνώσεις θα κόστιζαν $0,36 και οι εγγραφές θα έμεναν στο δωρεάν ημερήσιο όριο. Η πράξη αυτή αφήνει έξω αποθήκευση και μεταφορά δεδομένων. Κυρίως, δεν αποτιμά το έργο που θα απαιτούσε η μετατροπή ενός σχεσιακού SaaS σε βάση εγγράφων.
Υποθέτουμε τώρα ότι το ίδιο SaaS χρειάζεται δύο ανεξάρτητα έργα παραγωγής PostgreSQL, με 6 GB δίσκου στο καθένα και 20 GB συνολικής εξερχόμενης κίνησης. Τα μεγέθη αυτά χωρούν αριθμητικά στα αντίστοιχα όρια του Pro, αλλά κάθε έργο έχει ξεχωριστό Postgres και compute. Η χρέωση compute του Supabase γίνεται ανά ώρα ενεργού έργου: το Micro αντιστοιχεί περίπου σε $10 και το Small σε $15 για έναν πλήρη μήνα, ενώ η μηνιαία πίστωση $10 δίνεται μία φορά στον οργανισμό. Έτσι, δύο Micro οδηγούν σε ενδεικτικό σύνολο περίπου $35 μαζί με τη συνδρομή· ένα Micro και ένα Small σε περίπου $40. Τα ποσά προϋποθέτουν πλήρη μήνα λειτουργίας και καμία άλλη υπέρβαση.
Το δεύτερο έργο μπορεί να εξυπηρετεί χωριστό προϊόν, πελάτη ή περιβάλλον παραγωγής, αλλά η αιτία δημιουργίας του δεν αλλάζει τη χρέωση compute. Αντίστοιχα, η αναβάθμιση ενός έργου δεν σημαίνει νέα συνδρομή Pro: αυξάνει τις ώρες compute που απομένουν αφού εφαρμοστεί η κοινή πίστωση. Το μέγεθος Micro είναι αφετηρία τιμής, όχι υπόσχεση ότι σύνθετα ερωτήματα, πολλές ταυτόχρονες συνδέσεις ή απαιτητική επεξεργασία θα χωρέσουν σε αυτό.
Ο τύπος βάσης επηρεάζει το κόστος μετεγκατάστασης
Το Firestore αποθηκεύει έγγραφα και ευνοεί σχεδιασμό γύρω από τα δεδομένα που διαβάζει κάθε οθόνη. Η PostgreSQL του Supabase εξυπηρετεί σχέσεις πινάκων και ερωτήματα SQL. Αν το SaaS βασίζεται ήδη σε τέτοιες σχέσεις, μια χαμηλή εκτίμηση για πράξεις Firestore δεν περιλαμβάνει τη μεταφορά της δομής, την αναδιατύπωση ερωτημάτων και τις αλλαγές στον κώδικα πρόσβασης. Αντίστροφα, μια εφαρμογή που στηρίζεται στους ακροατές του Firestore θα χρειαστεί να ξανασχεδιάσει τη λογική ζωντανού συγχρονισμού σε άλλο backend.
Η PostgreSQL δίνει περισσότερες επιλογές για μελλοντική μεταφορά της ίδιας της βάσης, όμως η βάση είναι μόνο μέρος της εφαρμογής. Η ταυτοποίηση χρηστών, τα αρχεία, οι κανόνες πρόσβασης και οι συναρτήσεις μπορεί να χρειαστούν χωριστή μεταφορά σε κάθε κατεύθυνση. Για απόφαση με ορίζοντα πέρα από τον πρώτο λογαριασμό, ο χρόνος αυτής της εργασίας έχει σημασία δίπλα στη μηνιαία διαφορά λίγων δολαρίων.
Ποια προστασία περιορίζει την υπέρβαση
Στο Firestore, ένας μηνιαίος προϋπολογισμός μπορεί να στείλει ειδοποιήσεις καθώς ανεβαίνει η δαπάνη, αλλά η υπέρβασή του δεν σταματά τα αιτήματα. Για εφαρμογή με ζωντανά αποτελέσματα, η χρήσιμη μέτρηση είναι οι πραγματικές ημερήσιες αναγνώσεις ανά χρήστη, μαζί με την εξερχόμενη κίνηση. Όρια στο πλήθος εγγράφων ενός ερωτήματος, σε συνδυασμό με κατάλληλη σελιδοποίηση, μπορούν να μειώσουν τις περιττές αναγνώσεις. Η ειδοποίηση κόστους δίνει χρόνο αντίδρασης· ο περιορισμός των αιτημάτων μέσα στην εφαρμογή ελέγχει τη χρήση που τη δημιουργεί.
Στο Supabase Pro, το Spend Cap καλύπτει μεταξύ άλλων εξερχόμενη κίνηση και μέγεθος δίσκου: όταν εξαντληθεί σχετικό όριο, η επιπλέον χρήση περιορίζεται αντί να χρεώνεται ως υπέρβαση. Δεν καλύπτει το compute, οπότε πρόσθετα ενεργά έργα και μεγαλύτερα μεγέθη χρειάζονται ξεχωριστή παρακολούθηση. Η επιλογή είναι οικονομικά προβλέψιμη μόνο όταν η εκτίμηση περιλαμβάνει τόσο τις αναγνώσεις που παράγει πραγματικά η εφαρμογή όσο και όλες τις βάσεις που πρέπει να παραμείνουν ενεργές.
Διαβάστε επίσης:
Σχετικά άρθρα


Cosmos Business Systems: backlog €120 εκατ., αλλά το 2027 φέρνει φρένο

Cohere Embed 5: δύο μοντέλα μοιράζονται το ίδιο ευρετήριο

Κωδικός WhatsApp αντί για PIN: βάλε email πριν χρειαστεί ανάκτηση

Το RCP-nDCG βρίσκει σχετικά έγγραφα που τα κλασικά benchmarks χάνουν

Pomodoro ή time blocking: το χρονόμετρο δεν λύνει τον λάθος προγραμματισμό
Εγγραφείτε στο newsletter μας
Λάβετε τα τελευταία νέα για Web3, AI και κρυπτονομίσματα απευθείας στα εισερχόμενά σας.