Μετάβαση στο περιεχόμενο
leeveel
← Ευρετήριο
Nº 004 · 24 Ιαν · 8 λεπτά ανάγνωσης#backend

Οι βαρετές βάσεις δεδομένων γερνάνε καλύτερα

Postgres το 2018, Postgres το 2026. Σημειώσεις από το ασέξυ ενδιάμεσο.

από Γιάννης Π.

++++

Η Postgres το 2018 ήταν ήδη βαρετή. Το 2026 είναι κατά κάποιο τρόπο πιο βαρετή, και κατά κάποιο τρόπο πιο ενδιαφέρουσα. Ξεκινάμε σχεδόν κάθε backend με αυτήν, και ποτέ δεν μετανιώσαμε για αυτή την επιλογή. Ούτε μία φορά.

Η εντυπωσιακή βάση κάθε χρόνου σχεδόν ποτέ δεν επιβιώνει τα επόμενα τέσσερα. Η εποχή των graph DB. Η εποχή των document DB. Η εποχή του "serverless-first." Καθεμία ήρθε με υποσχέσεις για queries που δεν θα χρειαζόταν ποτέ ξανά να γράψεις, και καθεμία τελείωσε με κάποιον — συχνά εμάς — να μεταφέρει επώδυνα δεδομένα πίσω σε κάτι που υποστηρίζει JOIN.

Τι χάνεις όντας βαρετός: τίποτα σημαντικό. JSON στήλες όταν τις χρειάζεσαι. Full-text search όταν το χρειάζεσαι. Listen/notify για φτηνό pubsub. Pgvector όταν το AI hype τελικά φτάσει στο codebase σου. Τα περισσότερα επιχειρήματα "πρέπει να χρησιμοποιήσουμε X" διαλύονται μόλις δοκιμάσεις πραγματικά το ίδιο πράγμα πρώτα σε Postgres.

Έχουμε έναν πελάτη που τρέχει σε Postgres 9 από το 2018, αμετάβλητο. Η μετάβαση στο 16 πήρε ένα Σαββατιάτικο απόγευμα και ένα προσεκτικό pg_dump/pg_restore. Η δική μας studio database είναι το ίδιο. Η βαρετή επιλογή αποπληρώθηκε πριν οκτώ χρόνια και συνεχίζει να αποπληρώνεται.

Οι καμπύλες παραπάνω είναι οι συζητήσεις που έχουμε κάνει με πελάτες την τελευταία δεκαετία — graph το 2014, document το 2017, serverless το 2020, vector το 2024. Καθεμία ήρθε ως "σκεφτόμαστε migration, τι λέτε;" Η ειλικρινής απάντηση ήταν σχεδόν πάντα "η Postgres μπορεί να το κάνει αυτό, θέλεις να σου δείξουμε;" ακολουθούμενη από ένα proof μιας εβδομάδας. Τρία από αυτά τα POCs έφτασαν σε production. Κανένα δεν χρειάστηκε νέα βάση.

Οι εξαιρέσεις είναι ειλικρινείς. Χρησιμοποιούμε Redis σε production για χρόνια — διαφορετικό πρόβλημα, συμπληρωματικό εργαλείο, ποτέ δεν αντικαθιστά την Postgres. Πήγαμε σε ClickHouse δύο φορές όταν το analytic query ήταν εκατό εκατομμύρια γραμμές πλατύ και ο στόχος latency ήταν σφιχτός. Θα πιάσουμε DuckDB την επόμενη φορά που η analytics πλευρά είναι single-tenant. Βαρετό δεν σημαίνει μόνο ένα εργαλείο. Σημαίνει ξεκίνημα από το εργαλείο που επιβιώνει.

Η Postgres-9-σε-16 μετάβαση αξίζει δεύτερη αναφορά λόγω του πόσο ασήμαντη ήταν. Πήραμε backup, σηκώσαμε μία 16, κάναμε restore, τρέξαμε smoke test, αλλάξαμε DNS. Το δυσκολότερο κομμάτι ήταν ο προγραμματισμός. Το δυσκολότερο κομμάτι είναι πάντα ο προγραμματισμός. Αυτή είναι η διαφήμιση για τις βαρετές βάσεις δεδομένων — το δυσκολότερο είναι ο προγραμματισμός, όχι το engineering.