In-memory hot tier

Pinecone-class latency for the hot working set — without a paid cluster.

Amazon S3 Vectors is cheap and serverless, but it is an object-backed ANN: its per-query server time is hundreds of milliseconds. For the hot working set, dynavec can keep vectors in RAM (via the built-in SPFreshHotIndex) so a warmed namespace is served entirely from memory — no S3 Vectors query and no DynamoDB hydration, since the hot index already holds text and metadata. That collapses p50 from hundreds of ms to sub-millisecond, and it costs nothing extra: the index lives in the compute you already run.

Enable it

from dynavec import Dynavec, DynavecConfig

cfg = DynavecConfig(
    vector_bucket="my-vectors", index="docs", table="dynavec_docs",
    dimension=1536, region="us-east-1", auto_provision=True,
    hot_tier=True,                 # keep a hot working set in RAM
    hot_tier_max_vectors=200_000,  # global RAM safety cap across namespaces
)
db = Dynavec(cfg, embedder=my_embedder)

db.warm(namespace="default")       # load from S3 Vectors -> RAM (authoritative)
hits = db.search("query", top_k=5) # served from memory: no S3, no DynamoDB
print(db.hot_stats())              # {'authoritative_namespaces': ['default'], ...}

How it works

• warm(namespace) scans the namespace from S3 Vectors, hydrates text from DynamoDB, and holds it in RAM. If it fits under hot_tier_max_vectors the namespace becomes authoritative; otherwise it stays on the S3 path.
• Write-through: upsert, update, and delete keep warmed namespaces current, so you rarely need to re-warm.
• Full query semantics on the hot path: metadata filters (the same MongoDB-style dialect), rescoring, and MMR reranking all run in-process. A filter the in-memory matcher can't express falls back to S3 rather than returning a wrong result.
• Reconcile after out-of-band writes by calling warm() again.