ScyllaDB Adds Native Vector Search to Its DynamoDB‑Compatible API

![Featured image]()

The problem: Vector search is still a plumbing nightmare

Modern applications—from recommendation engines to semantic search—rely on vector similarity queries. Today most teams build this capability by stitching together three moving parts:

1. A primary data store (often DynamoDB or another NoSQL database) for metadata and transactional writes.
2. A dedicated vector index such as OpenSearch, Pinecone, or Milvus.
3. Custom glue code that keeps the two in sync, handles batch updates, and translates query formats.

The result is operational overhead, latency spikes during sync, and a larger attack surface. For startups that need to ship quickly, the extra infrastructure can become a blocker, while larger enterprises spend months tuning pipelines for reliability.

ScyllaDB’s answer – native vector search on the DynamoDB API

ScyllaDB, the high‑performance, Cassandra‑compatible database that recently raised $200 million in a Series C round led by Accel (see the press release), announced a new feature set that embeds vector search directly into its DynamoDB‑compatible API.

How it works

• Unified storage – Vectors are stored alongside regular attributes in the same table. No separate index service is required.
• API compatibility – Developers continue to use the familiar Query, Scan, and BatchGetItem calls, adding a VectorSearch parameter that accepts a query vector and a distance metric (cosine, Euclidean, or inner product).
• Hybrid indexing – Under the hood ScyllaDB builds an HNSW (Hierarchical Navigable Small World) graph on the vector column while keeping the traditional LSM‑tree for key‑value data. The two indexes share the same on‑disk structures, which reduces I/O and memory pressure.
• Performance – Benchmarks released by ScyllaDB show 12 K queries per second (QPS) at 99th‑percentile latency of 3 ms on a 4‑node cluster (c4.8xlarge instances), a figure that rivals purpose‑built services while avoiding the network hop to a separate search cluster.

Trade‑offs to consider

Aspect	ScyllaDB native vector search	OpenSearch + DynamoDB combo
Operational complexity	Single service, single backup/restore pipeline	Two services, separate scaling policies
Latency	In‑process, sub‑5 ms typical	Network hop adds 5‑15 ms overhead
Feature richness	Core similarity metrics, filter on non‑vector attributes	Full text search, aggregations, advanced scoring
Ecosystem support	Growing SDKs (Python, Go, Java)	Mature plugins, broader community

If your use case is pure similarity search with occasional attribute filters, ScyllaDB’s offering is compelling. If you need full‑text search, faceted aggregations, or complex relevance tuning, you may still prefer a dedicated search engine.

Market positioning and traction

ScyllaDB’s move is a clear attempt to capture a slice of the rapidly expanding vector‑search market, which analysts estimate will exceed $5 billion by 2028. By removing the OpenSearch layer, ScyllaDB reduces both cost and operational risk, a proposition that resonates with late‑stage startups and enterprises looking to consolidate their stack.

Since the announcement, the company has reported:

• 30 % increase in trial sign‑ups for the new feature within the first two weeks.
• Early adopters such as a content‑recommendation platform (which processed 8 K QPS in production) and a biotech data‑analysis startup (using the service for protein‑embedding similarity).
• Partnership talks with AWS Marketplace and Azure Marketplace teams, aiming to list ScyllaDB as a managed service that can be provisioned with a single click.

The funding round that preceded the launch gave ScyllaDB the runway to hire additional vector‑search engineers and expand its global data‑center footprint, ensuring low‑latency access for customers across Europe and APAC.

What this means for developers

1. Simpler codebases – One SDK, one connection string, one set of IAM policies.
2. Cost savings – No need to run a separate OpenSearch cluster; storage and compute are billed together.
3. Scalability – Because ScyllaDB already supports linear scaling of writes, vector inserts can keep up with high‑velocity data streams (e.g., real‑time embeddings from LLMs).
4. Future‑proofing – The company has hinted at upcoming support for quantized vectors (8‑bit) and GPU‑accelerated indexing, which could push throughput even higher.

Bottom line

ScyllaDB’s native vector search is not a silver bullet, but it offers a pragmatic path for teams that are already on the DynamoDB API and want to add similarity search without the overhead of a separate search stack. The combination of a strong funding base, clear performance numbers, and a growing ecosystem of SDKs makes it a development you should keep on your radar, especially if you are wrestling with the operational friction of current vector‑search pipelines.

---

For more details, check the official ScyllaDB announcement blog post and the GitHub repository where the vector‑search extensions are open‑sourced.