Σχεδόν κάθε σύστημα ανάκτησης πρέπει να ξεκινά με το pgvector μέσα στην Postgres που ήδη λειτουργείτε, και το ερώτημα της επιλογής δεν είναι «ποια vector database είναι ταχύτερη» αλλά «ποια αστοχία θα με βρει πρώτη». Τα δημοσιευμένα νούμερα recall και QPS συγκλίνουν μεταξύ των μηχανών στις κλίμακες όπου πραγματικά λειτουργούν οι περισσότερες ομάδες. Αυτό που δεν συγκλίνει είναι το τι συμβαίνει όταν προσθέτετε ένα φίλτρο tenant σε κάθε ερώτημα, όταν το ευρετήριο χρειάζεται rebuild μέσα στο ωράριο εργασίας, ή όταν ο γράφος HNSW παύει να χωράει στη RAM. Αυτά είναι τα γεγονότα που επιβάλλουν μια μετάβαση, και κάθε μηχανή αποτυγχάνει σε διαφορετικό από αυτά.

Ο ειλικρινής τρόπος να συγκρίνετε vector stores, λοιπόν, είναι να δουλέψετε ανάποδα από το σημείο θραύσης. Διαλέξτε την αστοχία που θα χτυπήσετε πρώτη, και μετά διαλέξτε τη μηχανή που δεν την έχει. Όλα τα υπόλοιπα είναι ένας πίνακας χαρακτηριστικών.

Τα τέσσερα πράγματα που όντως σπάνε

Σε παραγωγικά συστήματα RAG και μνήμης agents, τέσσερα συμπτώματα εξηγούν σχεδόν κάθε μετάβαση μακριά από την αρχική επιλογή:

  • Χρόνος κατασκευής και rebuild του ευρετηρίου. Αλλάζετε το μοντέλο embeddings, ή τη διάσταση, ή τον τελεστή απόστασης, και τώρα πρέπει να ξαναχτίσετε ένα ευρετήριο προσεγγιστικού πλησιέστερου γείτονα πάνω σε κάθε γραμμή. Στο ένα εκατομμύριο διανύσματα αυτό είναι ένας καφές. Στα πενήντα εκατομμύρια είναι παράθυρο συντήρησης, και πρέπει να αποφασίσετε αν το παλιό ευρετήριο θα εξυπηρετεί κίνηση όσο χτίζεται το νέο.
  • Recall σε φιλτραρισμένη αναζήτηση. Σχεδόν κανείς δεν τρέχει αφιλτράριστο διανυσματικό ερώτημα στην παραγωγή. Τα πραγματικά ερωτήματα είναι «πλησιέστεροι γείτονες where tenant_id = X and status = active and updated_at > Y». Τα ευρετήρια γράφου είναι χτισμένα για την αφιλτράριστη περίπτωση, και ένα επιλεκτικό φίλτρο μπορεί να κάνει μια αναζήτηση ANN να επιστρέψει λιγότερες από τις k γραμμές που ζητήσατε, σιωπηλά. Αυτό είναι πρόβλημα ορθότητας μεταμφιεσμένο σε πρόβλημα συνάφειας.
  • Μνήμη γράφου έναντι RAM. Το HNSW είναι γράφος, και θέλει να ζει στη μνήμη. Όταν ο γράφος συν το working set σας ξεπεράσουν αυτά που έχει το instance, η καθυστέρηση δεν υποβαθμίζεται ομαλά, πέφτει από γκρεμό καθώς η μηχανή αρχίζει να διαβάζει σελίδες ευρετηρίου από τον δίσκο σε κάθε probe.
  • Καθυστέρηση φρεσκάδας υπό φορτίο εγγραφών. Η μνήμη agents και τα εργαλεία υποστήριξης γράφουν συνεχώς. Κάθε insert μεταλλάσσει τον γράφο, η συντήρηση του ευρετηρίου ανταγωνίζεται την κίνηση των ερωτημάτων, και το κενό ανάμεσα στο «αποθηκεύσαμε το γεγονός» και στο «το γεγονός είναι ανακτήσιμο» αρχίζει να μετράει για την ορθότητα και όχι για την αίσθηση.

Προσέξτε τι δεν υπάρχει σε αυτή τη λίστα: τα ωμά ερωτήματα ανά δευτερόλεπτο. Αν σερβίρετε ανάκτηση σε ένα μοντέλο που μετά ξοδεύει δύο δευτερόλεπτα σε παραγωγή κειμένου, μια διαφορά δέκα χιλιοστών του δευτερολέπτου στην καθυστέρηση αναζήτησης είναι θόρυβος. The latency that hurts in RAG lives in the number of round trips, όχι στο probe του ANN.

pgvector: η σωστή προεπιλογή, και τα πραγματικά της ταβάνια

Το επιχείρημα υπέρ του pgvector δεν είναι ότι κερδίζει σε benchmarks. Είναι ότι τα embeddings σας ζουν στην ίδια συναλλαγή με τη γραμμή που περιγράφουν, τα φίλτρα σας είναι συνηθισμένη SQL πάνω σε στήλες που έχουν ήδη ευρετήρια, η ιστορία backup και point-in-time recovery είναι αυτή που ήδη λειτουργείτε, και η ομάδα on-call ξέρει ήδη να διαβάζει EXPLAIN. Αυτός ο συνδυασμός αξίζει πολύ p99.

Τα ταβάνια είναι συγκεκριμένα και αξίζει να τα απομνημονεύσετε, γιατί ο αόριστος φόβος γι' αυτά προκαλεί περισσότερες πρόωρες μεταβάσεις απ' ό,τι προκάλεσαν ποτέ τα ίδια τα ταβάνια:

  • Τα όρια διαστάσεων είναι όρια ευρετηρίου, όχι όρια στήλης. Μια στήλη vector δέχεται μέχρι 16.000 διαστάσεις, αλλά τα HNSW και IVFFlat ευρετηριάζουν μόνο μέχρι 2.000. Με halfvec (floats 16 bit) ευρετηριάζετε μέχρι 4.000 διαστάσεις με περίπου τη μισή αποθήκευση. Το bit ευρετηριάζει μέχρι 64.000 διαστάσεις για binary quantization, και το sparsevec χειρίζεται μέχρι 1.000 μη μηδενικά στοιχεία. Ένα embedding 3.072 διαστάσεων δεν είναι λόγος να φύγετε από την Postgres, είναι λόγος να κάνετε cast σε halfvec στην έκφραση του ευρετηρίου.
  • Τα φιλτραρισμένα ερωτήματα έπαψαν να είναι γκρεμός στην 0.8.0. Η παλιά αστοχία ήταν πραγματική: ένα σάρωμα HNSW επέστρεφε τους ef_search υποψηφίους του, η ρήτρα WHERE διέγραφε τους περισσότερους, και παίρνατε πίσω τρεις γραμμές ενώ ζητήσατε δέκα. Το pgvector 0.8.0 πρόσθεσε iterative index scans, που συνεχίζουν το σάρωμα μέχρι να έχουν αρκετές επιζώσες γραμμές. Το hnsw.iterative_scan = strict_order διατηρεί ακριβή διάταξη αποστάσεων, το relaxed_order ανταλλάσσει λίγη διάταξη για καλύτερο recall. Αν το νοητικό σας μοντέλο για το φιλτράρισμα του pgvector είναι από το 2024, είναι ξεπερασμένο.
  • Η μνήμη κατασκευής είναι αυτό που πραγματικά δαγκώνει. Το HNSW χτίζεται στη μνήμη όταν ο γράφος χωράει μέσα στο maintenance_work_mem, και πέφτει σε ένα πολύ πιο αργό μονοπάτι στον δίσκο όταν δεν χωράει. Η λύση είναι να το αυξήσετε για την κατασκευή και να χρησιμοποιήσετε parallel workers, αλλά υπάρχει ένα μέγεθος πέρα από το οποίο σχεδιάζετε ένα rebuild αντί να το τρέχετε.
  • Οι θορυβώδεις γείτονες είναι αρχιτεκτονικό ζήτημα. Μια κατασκευή ANN που φέρνει σε κορεσμό τη CPU στο instance που εξυπηρετεί τη ροή checkout σας είναι η αστοχία που δεν έχει καμία σχέση με διανύσματα. Ένα read replica ή ένα ξεχωριστό instance το λύνει, που είναι και η στιγμή που το pgvector παύει να είναι δωρεάν.

Ειδικά στο AWS, η Aurora PostgreSQL με pgvector είναι πρώτης κατηγορίας vector store για Bedrock Knowledge Bases, οπότε η επιλογή της δεν σας κοστίζει κανένα χαρακτηριστικό managed RAG. Έγραψα την πλευρά του κόστους στο the OpenSearch Serverless to Aurora migration post, με μία επιφύλαξη παρακάτω: η πλευρά OpenSearch αυτής της σύγκρισης άλλαξε τον Μάιο του 2026.

OpenSearch: αγοράζετε μηχανή αναζήτησης, οπότε χρησιμοποιήστε την ως τέτοια

Το να επιλέξετε OpenSearch αποκλειστικά ως vector store είναι ο ακριβός τρόπος να αποκτήσετε διανυσματική αναζήτηση. Το να το επιλέξετε επειδή χρειάζεστε αναζήτηση, και τα διανύσματα είναι ένα από τα πράγματα με τα οποία ψάχνετε, είναι μια διαφορετική και πολύ καλύτερη απόφαση.

Τι σας δίνει που ένα καθαρό vector store δεν δίνει: πραγματική λεξιλογική αναζήτηση δίπλα στο ANN, ώστε η υβριδική ανάκτηση που συνδυάζει BM25 με διανυσματική ομοιότητα να είναι ένα ερώτημα, όχι μια αρχιτεκτονική. Ακριβές ταίριασμα λέξεων-κλειδιών για τους κωδικούς εξαρτημάτων, τους κωδικούς σφαλμάτων και τα αναγνωριστικά στα οποία τα embeddings είναι διαβόητα κακά. Aggregations, faceting και μια μηχανή φιλτραρίσματος χτισμένη για χαρακτηριστικά υψηλής πληθικότητας αντί για προσθήκη εκ των υστέρων. Και δυαδικά διανύσματα, τα οποία στα Bedrock Knowledge Bases υποστηρίζουν μόνο οι δύο επιλογές OpenSearch.

Το επιχείρημα εναντίον του ήταν ιστορικά το κατώφλι κόστους: το OpenSearch Serverless χρέωνε σε OCUs με ένα ελάχιστο παραγωγής που κόστιζε πραγματικά χρήματα πριν ευρετηριάσετε έστω και ένα έγγραφο. Πάνω σε αυτό το επιχείρημα ήταν χτισμένο το post μου για τη μετάβαση, και χρειάζεται διόρθωση. Η επόμενη γενιά του OpenSearch Serverless έγινε γενικά διαθέσιμη στις 28 Μαΐου 2026 με υπολογιστική ισχύ και αποθήκευση πλήρως αποσυζευγμένες, scale-to-zero, και autoscaling που το AWS περιγράφει ως είκοσι φορές ταχύτερο από την προηγούμενη γενιά. Το AWS ισχυρίζεται εξοικονόμηση έως 60 τοις εκατό σε σχέση με την πρόβλεψη cluster για φορτίο αιχμής. Αν το φορτίο σας είναι εκρηκτικό, και η agentic ανάκτηση είναι εξαιρετικά εκρηκτική, το παλιό επιχείρημα του κατωφλιού δεν ισχύει πια με τη μορφή που το διατύπωσα.

Τι εξακολουθεί να σπάει: είναι ένα κατανεμημένο σύστημα με shards, replicas και cluster state, και κάποια στιγμή θα σας ζητήσει να σκεφτείτε και τα τρία. Η διαστασιολόγηση shards για διανυσματικά φορτία δεν είναι ίδια με αυτή για logs. Και ένα rebuild είναι reindex, που σημαίνει σχεδιασμό χωρητικότητας για δύο αντίγραφα του ευρετηρίου.

S3 Vectors: βαθμίδα αποθήκευσης που απαντά σε ερωτήματα, όχι βαθμίδα εξυπηρέτησης

Το S3 Vectors έφτασε σε γενική διαθεσιμότητα στις 2 Δεκεμβρίου 2025 με σαράντα φορές την κλίμακα του preview: έως δύο δισεκατομμύρια διανύσματα ανά ευρετήριο και δέκα χιλιάδες ευρετήρια ανά vector bucket, με δεκαεπτά επιπλέον regions τον Μάρτιο του 2026. Το AWS τοποθετεί τη μείωση κόστους σε σχέση με τη λειτουργία μιας vector database στο έως 90 τοις εκατό, και ο λόγος είναι δομικός και όχι διαφημιστικός: δεν υπάρχει cluster, δεν υπάρχει προβλεπόμενη υπολογιστική ισχύς, δεν υπάρχει χρέωση αδράνειας.

Το νούμερο που κρίνει αν ταιριάζει είναι το προφίλ καθυστέρησης. Το AWS τεκμηριώνει ότι τα σπάνια ερωτήματα επιστρέφουν σε κάτω από ένα δευτερόλεπτο, και τα συχνότερα σε περίπου 100 χιλιοστά του δευτερολέπτου ή λιγότερο. Διαβάστε το ως φαινόμενο ζεστής cache, και μετά γίνετε ειλικρινείς για την κίνησή σας: ένας βοηθός υποστήριξης που δέχεται σαράντα ερωτήσεις την ώρα δεν κρατάει τίποτα ζεστό. Το κάτω από ένα δευτερόλεπτο είναι μια χαρά για μια νυχτερινή εργασία σύνοψης και λάθος για ένα διαδραστικό chat όπου το μοντέλο χρειάζεται μετά τα δικά του δύο δευτερόλεπτα.

Πού είναι πραγματικά η σωστή απάντηση: κρύες ή αρχειακές διανυσματικές βαθμίδες, ευρετήρια ανά tenant όπου ο αριθμός των tenants είναι μεγάλος και η κίνηση καθενός αραιή, Bedrock Knowledge Bases με προτεραιότητα στο κόστος και ανεκτικά περιθώρια καθυστέρησης, και οτιδήποτε όπου η εναλλακτική ήταν να πληρώνετε ένα αδρανές cluster. Συντίθεται καλά ως δεύτερη βαθμίδα κάτω από ένα ζεστό store, που είναι και ο τρόπος με τον οποίο θα το χρησιμοποιούσα, αντί για ολική αντικατάσταση.

Qdrant, Milvus, Pinecone: όταν κερδίζει το payload

Φεύγετε από την Postgres για μια εξειδικευμένη μηχανή όταν το διανυσματικό φορτίο έχει πάψει να είναι χαρακτηριστικό της εφαρμογής σας και έχει γίνει η εφαρμογή. Τρεις μορφές αυτού:

Το Qdrant είναι αυτό στο οποίο απλώνετε το χέρι όταν το πρόβλημα είναι το φιλτράρισμα. Τα payload indexes και το filterable HNSW του είναι σχεδιασμένα για την περίπτωση που το iterative scan του pgvector απλώς επιβιώνει: πολύ επιλεκτικά φίλτρα σε κάθε ερώτημα, σε υψηλούς ρυθμούς. Παρέχει επίσης scalar, product και binary quantization, που είναι ο πρακτικός τρόπος να κρατήσετε ένα μεγάλο ευρετήριο μόνιμα στη μνήμη. Για ένα multi-tenant store μνήμης agents με φίλτρα ανά tenant σε κάθε ανάγνωση, αυτός είναι ένας υπερασπίσιμος λόγος να τρέχετε άλλη μια βάση δεδομένων.

Το Milvus είναι η απάντηση της κλίμακας δισεκατομμυρίων. Η ευρετηρίαση στον δίσκο (DiskANN) σημαίνει ότι το working set δεν χρειάζεται να χωράει στη RAM, και αυτό είναι που αλλάζει τον λογαριασμό υλικού σε εκείνο το μέγεθος. Το αντάλλαγμα είναι λειτουργικό: είναι ένα κατανεμημένο σύστημα με ξεχωριστούς ρόλους coordinator, query, data και index, και η λειτουργία του στην παραγωγή είναι απόφαση στελέχωσης πριν γίνει τεχνική. Κάτω από μερικές εκατοντάδες εκατομμύρια διανύσματα, αυτή η πολυπλοκότητα σας αγοράζει ελάχιστα.

Το Pinecone είναι η επιλογή «αγόρασε αντί να χτίσεις», και πρέπει να αξιολογείται όπως αξιολογείτε κάθε SaaS: με βάση το λειτουργικό βάρος που αφαιρεί και όχι την καθυστέρηση. Η serverless τιμολόγηση αποσυζευγνύει την αποθήκευση από τις αναγνώσεις και τις εγγραφές χωρίς κόστος αδράνειας, κάτι που ταιριάζει σε φορτία με αιχμές και κάνει τις μικρές εγκαταστάσεις πραγματικά φθηνές. Αυτό που παραχωρείτε είναι ο έλεγχος πάνω στις αστοχίες, και αναλαμβάνετε egress και δέσιμο με τον προμηθευτή. Είναι επίσης υποστηριζόμενο store για Bedrock Knowledge Bases, οπότε δεν αποτελεί έξοδο από το μονοπάτι του AWS-managed RAG.

Η μακριά ουρά, εν συντομία

Το Weaviate είναι το πλησιέστερο σε ένα RAG store με τις μπαταρίες μέσα: ενσωματωμένα modules διανυσματοποίησης, υβριδική αναζήτηση και μοντέλο schema-first. Ελκυστικό αν θέλετε έτοιμες απόψεις, λιγότερο αν έχετε ήδη pipeline για embeddings. Το Chroma είναι εργαλείο πρωτοτυποποίησης που είναι ειλικρινές γι' αυτό, και κάθε σοβαρή εγκατάσταση που έχω δει τελικά μετακόμισε αλλού. Το Redis με διανυσματική ομοιότητα είναι εξαιρετικό όταν τα διανύσματα είναι εφήμερα, sessions, βραχυπρόθεσμη μνήμη agents, σημασιολογικές caches, και απαίσιο ως σύστημα καταγραφής. Το MongoDB Atlas Vector Search είναι για τη Mongo ό,τι το pgvector για την Postgres: σωστό αν τα έγγραφά σας ζουν ήδη εκεί, και κακός λόγος να υιοθετήσετε Mongo αν δεν ζουν. Τόσο το Redis Enterprise Cloud όσο και το MongoDB Atlas είναι υποστηριζόμενα stores για Bedrock Knowledge Bases.

Ο πίνακας απόφασης

ΜηχανήΙδανικό σημείοΤι σπάει πρώτοΠοιος τη λειτουργεί
pgvectorΚάτω από ~50M διανύσματα, φίλτρα σε SQL, δεδομένα ήδη στην PostgresΜνήμη κατασκευής ευρετηρίου και παράθυρα rebuild, ANN που ανταγωνίζεται το OLTPΟ υπάρχων DBA και το on-call σας
OpenSearchΥβριδικό λεξιλογικό συν διανυσματικό, faceting, δυαδικά διανύσματαΔιαχείριση shards και cluster state, χωρητικότητα reindexΚάποιος που ξέρει clusters αναζήτησης
S3 VectorsΚρύες βαθμίδες, αραιά ευρετήρια ανά tenant, Knowledge Bases με προτεραιότητα στο κόστοςΔιαδραστική καθυστέρηση σε σπάνια ερωτώμενα ευρετήριαΚανείς, και αυτό είναι το ζητούμενο
QdrantΕπιλεκτικά φίλτρα σε κάθε ερώτημα, quantized ευρετήρια στη μνήμηΤρέχετε πλέον ένα δεύτερο stateful σύστημαΕσείς, ή το Qdrant Cloud
MilvusΠέρα από ~500M διανύσματα, ευρετηρίαση στον δίσκοΛειτουργική επιφάνεια ενός κατανεμημένου συστήματος πολλών ρόλωνΈνας αφοσιωμένος platform engineer
PineconeΚίνηση με αιχμές, καμία όρεξη για stateful λειτουργίεςΚαμπύλη κόστους σε συνεχή υψηλό όγκο, δέσιμο με τον προμηθευτήΗ Pinecone

Τα σήματα που πραγματικά σημαίνουν «φύγε από το pgvector τώρα»

Όχι η κλίμακα στα αφηρημένα. Αυτά:

  • Το rebuild του HNSW δεν χωράει πια σε αποδεκτό παράθυρο συντήρησης, και έχετε ήδη αυξήσει το maintenance_work_mem και χρησιμοποιήσει parallel workers.
  • Το recall με φίλτρα παραμένει ελλιπές μετά την ενεργοποίηση των iterative scans και το tuning του ef_search, επειδή τα φίλτρα σας είναι τόσο επιλεκτικά που ο γράφος είναι λάθος δομή.
  • Το working set του ευρετηρίου ξεπερνά τη μνήμη του instance και το επόμενο μέγεθος instance κοστίζει περισσότερο απ' ό,τι θα κόστιζε μια εξειδικευμένη μηχανή.
  • Η διανυσματική αναζήτηση στραγγαλίζει το συναλλακτικό σας φορτίο, και ένα read replica δεν αρκεί ως διαχωρισμός.
  • Χρειάζεστε υβριδική κατάταξη, λεξιλογική συν διανυσματική, ως ερώτημα πρώτης κατηγορίας και όχι ως δύο αναζητήσεις που συγχωνεύετε σε κώδικα εφαρμογής. Αυτό δείχνει συγκεκριμένα προς το OpenSearch.

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

Το συμπέρασμα

Ξεκινήστε με pgvector, και μάθετε τα τέσσερα ταβάνια του με αρκετή ακρίβεια ώστε να ξεχωρίζετε ένα πραγματικό όριο από τη λαογραφία. Μετακινηθείτε στο OpenSearch όταν χρειάζεστε αναζήτηση και όχι ομοιότητα, και ξανατρέξτε τη σύγκριση κόστους απέναντι στην επόμενη γενιά serverless και όχι στο παλιό κατώφλι OCU. Χρησιμοποιήστε το S3 Vectors ως κρύα βαθμίδα και για αραιά ευρετήρια ανά tenant, όχι ως διαδραστικό μονοπάτι εξυπηρέτησης. Απλώστε το χέρι στο Qdrant όταν κυριαρχεί το φιλτράρισμα, στο Milvus πέρα από το σημείο όπου η RAM ορίζει τον λογαριασμό, και στο Pinecone όταν προτιμάτε να αγοράσετε τις λειτουργίες παρά να τις τρέχετε. Επιλέξτε με βάση το σημείο θραύσης που θα χτυπήσετε πρώτο, γιατί αυτή είναι η μόνη μεταβλητή σε αυτή τη σύγκριση που διαφέρει ουσιαστικά μεταξύ των μηχανών.

Διαβάστε στη συνέχεια

Για την πλευρά της υποδομής, τη λειτουργία Postgres και clusters αναζήτησης στην παραγωγή, οι σημειώσεις πεδίου για το cloud ζουν στο ercan.cloud, και ο κόμβος είναι στο ercanermis.com.

Αναφορές