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

The community reception is generally positive toward the article's analysis while being somewhat skeptical of the broader vector database market. Commenters appreciate the technical depth and balanced approach, especially the reverse-engineering work, but many push back with alternative solutions (pgvector, Turbopuffer, LanceDB) or note that the promotional undertones are still visible. There is broad agreement that S3 Vectors is a useful but limited primitive rather than a category-killer, largely aligning with the article's thesis.

In Agreement

• S3 Vectors occupies a valid niche as a low-cost, 'good enough' vector storage option for cold data and low-QPS scenarios, consistent with S3's design philosophy
• The future of vector infrastructure is tiered, with different solutions serving different performance and cost tiers rather than one tool replacing all others
• Vector retrieval costs can genuinely exceed LLM API costs, validating the article's framing of the cost problem that S3 Vectors partially addresses
• The article's analysis is praised as balanced and well-researched despite coming from a competitor, with the reverse-engineering of S3 Vectors' post-filtering behavior seen as valuable

Opposed

• The article's workload suitability judgments may be premature since S3 Vectors is still in Preview, and AWS has historically raised limits significantly between Preview and GA releases
• For most applications, Postgres with pgvector is sufficient and avoids the operational overhead of separate vector databases — the dedicated vector DB market may be overhyped
• S3 Vectors is not really competing with vector databases at all but is part of AWS's broader strategy to compete with Databricks by building data processing capabilities into S3
• The article remains promotional despite its balanced framing, with numerous hyperbolic marketing phrases pushing readers toward Milvus and Zilliz Cloud