S3 Vectors Won’t Kill Vector Databases—They Enable a Tiered Future

S3 Vectors makes vector storage and retrieval dramatically cheaper by leveraging S3, but with clear constraints on latency, throughput, recall, and features. It fits cold data, low-QPS RAG, and prototyping, while dedicated vector databases remain essential for hot, high-performance, and complex workloads. The future is a tiered architecture, and Milvus/Zilliz is building toward that with tiered storage, a vector data lake, and AI-native capabilities.

Key Points

S3 Vectors is an ultra-low-cost vector storage/query layer on S3 (≈$0.06/GB) that can cut bills by ~10x for low-QPS, latency-tolerant workloads (e.g., ~$1,217/month for 400M vectors + 10M queries).
Its limits are significant: ~50M vectors per table (up to ~10,000 tables), cold latency ~500–700ms, hot queries <200ms only up to ~200 QPS, write throughput <2 MB/s, capped TopK (30), tight metadata, and no hybrid/advanced filtering or multi-tenancy.
Observed recall is ~85–90% with few/no tuning knobs; filters can drop recall below 50%, indicating a cost-first design likely using deep quantization, post-filtering, and multi-tier caching.
Best-fit scenarios are cold archiving, low-QPS RAG, and prototyping; it is not suited for high-performance search/recommendation, high-churn datasets, complex queries, or large multi-tenant apps.
The industry is moving to tiered vector storage (hot/warm/cold). Milvus/Zilliz’s roadmap aligns with this via tiered instances, a vector data lake in Milvus 3.0, and AI-native features—positioning S3 Vectors as a complementary cold/warm tier, not a database killer.

Sentiment

Generally agreeable to the article’s thesis: S3 Vectors is a cost-effective, limited, warm/cold complement rather than a Vector DB killer. Mixed but constructive on alternatives, with notable frustration about AWS’s lack of detailed documentation.

In Agreement

S3 Vectors is ‘good enough’ as a low-cost, warm/cold tier and won’t replace high-performance vector databases.
The service’s constraints (TopK=30, degraded recall with filters, limited throughput, lack of advanced filtering/hybrid search) align with the article’s findings.
AWS documentation is too opaque on internal behavior; clearer docs would save engineering time and aid architecture decisions.
Tiered architectures (hot/warm/cold) are the practical direction for vector infrastructure, with S3-backed systems filling the warm/cold role.
Vector retrieval can dominate costs in real systems, validating the push toward cheaper, object-storage-backed approaches.

Opposed

For many applications, Postgres/pgvector is sufficient and operationally simpler; specialized vector stores add unnecessary complexity and vendor risk.
Joining results from an external vector store back to transactional data can be slower than keeping vectors inside the primary database.
Concerns (contested by others) that AWS hosting vectors could facilitate internal meta-optimization or censorship pressures.
Some customers don’t need SOTA embeddings or advanced features, implying simpler, approved solutions are acceptable without specialized systems.