Η εφαρμογή μου άρχισε να αργεί.Γιατί δεν άλλαξα βάση δεδομένων

Κάθε developer έχει νιώσει τον πειρασμό: η εφαρμογή αργεί, άρα «φταίει η βάση» και πρέπει να μεταφερθούμε σε κάτι μεγαλύτερο. Στο Orama Suite έφτασα ακριβώς σε αυτό το σημείο τον Σεπτέμβριο του 2026. Αντί να ξεκινήσω μετάβαση, κάθισα και μέτρησα.

D1 ή PostgreSQL;

Το Orama Suite τρέχει στο Cloudflare D1, μια βάση SQLite που ζει κοντά στον χρήστη. Η εύλογη εναλλακτική ήταν μια «κανονική» PostgreSQL. Αντί να αποφασίσω με το ένστικτο, έγραψα μια σύγκριση με κριτήρια: κόστος, ταχύτητα, ασφάλεια δεδομένων, πόση δουλειά χρειάζεται η μετάβαση και πόσος κίνδυνος υπάρχει.

Το αποτέλεσμα ήταν 91 μονάδες για την τρέχουσα αρχιτεκτονική έναντι 82 για τη μετάβαση. Η μετάβαση έχανε κυρίως επειδή θα απαιτούσε να ξαναγραφτούν δεκάδες αλλαγές βάσης. Το πιο σημαντικό όμως ήταν το συμπέρασμα:

Το πρόβλημα που μετρήθηκε ήταν τα ερωτήματα χωρίς ευρετήρια. Μια αλλαγή βάσης δεν θα το έλυνε.

Ένα ερώτημα διάβαζε χιλιάδες γραμμές

Οι μετρήσεις έδειξαν ότι το ερώτημα για τις ειδοποιήσεις διάβαζε 3.000 έως 12.000 γραμμές κάθε φορά που μια καρτέλα έλεγχε για νέα. Πολλαπλασιασμένο με κάθε ανοιχτή καρτέλα, κάθε λίγα δευτερόλεπτα, όλη την ημέρα.

Η λύση ήθελε δύο απλά βήματα. Πρώτα, σωστά ευρετήρια: μια νέα αλλαγή βάσης πρόσθεσε ευρετήρια ανά επιχείρηση και ανά χρόνο, ώστε κάθε ερώτημα να διαβάζει μόνο ό,τι χρειάζεται. Μετά, ένας «παλμός» αντί για τέσσερις ελέγχους. Η εφαρμογή έκανε τέσσερα ξεχωριστά αιτήματα για να μάθει αν υπάρχει κάτι νέο. Τα ένωσα σε ένα, και τα αιτήματα ανά καρτέλα έπεσαν από περίπου 190 σε περίπου 60 την ώρα.

Σήμερα ο διάμεσος χρόνος επεξεργασίας στον server είναι περίπου 3 ms και το κόστος φιλοξενίας μένει μερικά δολάρια τον μήνα. Χωρίς μετάβαση, χωρίς ρίσκο για τα δεδομένα των πελατών.

Το συμβάν με το Safari

Λίγες μέρες αργότερα, στις 9 Οκτωβρίου, έμαθα ένα δεύτερο μάθημα, αυτή τη φορά για τις εκδόσεις.

Κάποιοι χρήστες σε Safari έβλεπαν την εφαρμογή να κολλάει στην οθόνη φόρτωσης. Η αιτία ήταν ένας «αγώνας» ανάμεσα σε ένα αίτημα και σε μια νέα έκδοση που ανέβαινε εκείνη ακριβώς τη στιγμή.

1. Ανεβαίνει νέα έκδοσητη στιγμή που ένας browser ζητά αρχεία
2. Το αρχείο JavaScript δεν υπάρχει πιακαι το αίτημα παίρνει πίσω τη σελίδα HTML
3. Ο browser την κρατάστην cache για έναν χρόνο, και η εφαρμογή κολλάει στην οθόνη φόρτωσης

Τι έκανα:

1. Επέστρεψα στην προηγούμενη έκδοση, ώστε οι χρήστες να συνεχίσουν να δουλεύουν.
2. Τα αρχεία που λείπουν παίρνουν πλέον τη σωστή απάντηση, «δεν βρέθηκε», χωρίς αποθήκευση στην cache, αντί για τη σελίδα HTML.
3. Κάθε έκδοση δίνει μοναδικά ονόματα στα αρχεία της, ώστε μια παλιά σελίδα να μη ζητά ποτέ αρχείο που άλλαξε.

Πώς βγαίνει πλέον κάθε έκδοση

Από αυτά τα δύο επεισόδια προέκυψε μια ρουτίνα που ακολουθώ σε κάθε έκδοση:

• αντίγραφο ασφαλείας της βάσης και σημείο επαναφοράς πριν από οτιδήποτε,
• αλλαγές βάσης που μόνο προσθέτουν, εφαρμοσμένες πριν από τον νέο κώδικα,
• αυτόματα tests σε Chrome και Safari,
• καταγεγραμμένη έκδοση επαναφοράς, για να γυρίσω πίσω σε λίγα λεπτά αν χρειαστεί.

Πρώτα μετράω, μετά αλλάζω

Η πιο ακριβή λύση δεν είναι πάντα η σωστή. Τα ευρετήρια είναι βαρετά, αλλά λύνουν περισσότερα προβλήματα απόδοσης από κάθε μετάβαση. Και κάθε έκδοση χρειάζεται δρόμο επιστροφής: το συμβάν με το Safari δεν έγινε καταστροφή, επειδή μπορούσα να γυρίσω πίσω αμέσως.

---

Αν η εφαρμογή σας αργεί ή φοβάστε κάθε νέα έκδοση, μπορώ να μετρήσω πού χάνεται ο χρόνος και να σας πω τι αξίζει να αλλάξει. Η πρώτη κουβέντα είναι δωρεάν.