Object storage is the durable layer

Amazon S3, Google Cloud Storage, and Azure Blob Storage all solve the same underlying problem: durable objects with high availability, lifecycle controls, encryption, regional placement, and an API that can be called from any compute runtime. They are not interchangeable products at the protocol level, but they share an architectural property that matters for retrieval: the durable bytes do not need to live on an always-on search node.

Talqora uses that property to separate the source of truth from the hot execution path. Dense vector records and filterable metadata are persisted through the regional vector storage layer. Sparse text retrieval is represented as immutable Quickwit splits in object storage. PostgreSQL remains the control plane for organizations, index settings, credentials, usage history, idempotency, and version ledgers; it is not used as a vector or document store.

This separation gives an index a long-lived home even when traffic is uneven. A team can upload a large corpus, pause retrieval for a week, and return to the same index without paying for a dedicated memory footprint that was doing nothing during the pause.

  • Durable vectors and search artifacts live outside the request process
  • Object storage provides regional placement and lifecycle policies
  • PostgreSQL stores control-plane state, never embeddings or document bodies
  • Compute can scale around reads, writes, and compaction instead of idle capacity

Why AWS is our primary production foundation

Talqora's current production vector runtime is AWS-first. Index creation records one immutable AWS region, and dense operations are routed to the regional object-storage vector layer for that index. This gives the API a straightforward contract: the index chooses its region once, and every write, query, and delete uses the same regional data plane.

AWS also gives us the surrounding primitives needed to operate a retrieval product: IAM policies scoped to regional buckets, CloudWatch and service metrics, managed networking, and compute close to the storage layer. The small Vector runtime runs the public API and the private Quickwit service. The dense layer handles vector operations, while Quickwit stores immutable BM25 splits in S3 and uses local disk as cache and working state.

The result is not a claim that every byte is in one generic bucket. Dense vectors use the regional dense storage API, sparse postings use Quickwit's S3-backed splits, and the control plane uses PostgreSQL. Each layer has a clear responsibility and an observable usage trail.

  • AWS region is selected when an index is created
  • Dense retrieval uses regional object-storage operations
  • Sparse BM25 retrieval uses Quickwit with S3-backed immutable splits
  • The API is the only public search surface; Quickwit is private
  • The runtime keeps only cache and working data on local disk

Where NVMe fits

Object storage is durable, but a search engine should not download the same hot posting lists or metadata blocks on every request. Talqora therefore treats fast local storage, including NVMe where the selected runtime provides it, as a cache and working layer. It can hold hot Quickwit files, temporary compaction data, request-local state, and other artifacts that improve locality.

NVMe is not the canonical copy of an index. If a runtime is replaced, the cache can be rebuilt from object storage. That distinction is important for both cost and reliability: local disks make the common path faster without turning a single machine into the only place where the corpus exists.

This is also why the architecture can remain small during early iteration. We do not provision enough local memory or NVMe to hold every possible customer corpus. We keep the working set close to compute and leave the complete durable dataset in the regional storage layer.

  • NVMe improves locality; it is not the source of truth
  • Quickwit can rebuild cache and compaction state from S3 splits
  • Hot data stays close to the API and private search process
  • Cold data does not force an oversized always-on cluster

How Google Cloud Storage and Azure Blob map to the model

Many customers already keep their source files, exports, or backup copies in Google Cloud Storage or Azure Blob Storage. The storage contract is deliberately familiar: objects have stable keys, metadata, versions, lifecycle rules, and a regional location. A customer can keep the authoritative source corpus in its existing cloud and send only the records needed for indexing to Talqora through the ingestion API.

For a future regional adapter, GCS and Blob Storage provide the same primitives we need from S3: ranged reads, conditional writes, object versioning, server-side encryption, and lifecycle management. The adapter boundary is around object access and manifests, not around the public vector API. Applications still create an index, write vectors, attach metadata, and query dense, sparse, or hybrid retrieval in the same way.

Today, Talqora's managed dense data plane is provisioned in AWS regions. GCS and Azure Blob should therefore be understood as supported source-storage patterns and portability targets, not as a promise that every Talqora index can already be created in every cloud region. We prefer that explicit boundary to a marketing checkbox that hides a different operational path.

  • GCS and Blob Storage can remain the customer's source-of-record layer
  • Stable object keys and versions make re-indexing repeatable
  • The ingestion API keeps the application contract cloud-neutral
  • Managed Talqora vector regions are currently AWS-backed

Why this can cost less than a cluster-first design

A cluster-first vector product prices the resources that must remain reserved: memory, CPU, replicas, attached disks, and a minimum service tier. That can be the right choice for a workload that is continuously hot and needs a permanently pinned working set. It is a poor default for a new product, a long-tail corpus, or traffic that arrives in bursts.

Talqora starts from the opposite cost model. Durable storage is separated from active compute, and the console reports documents, storage, rows written, data written, queries, and queried transfer independently. A customer can see which part of the workload is growing rather than translating a node class into an opaque monthly bill.

The cheapest architecture is not automatically the one with the lowest storage line item. It is the one that avoids paying for idle capacity while still returning predictable results. That means measuring cache hit behavior, query volume, write churn, metadata size, and transfer for the actual workload instead of comparing a single advertised number.

For a concrete example, imagine one million 1,536-dimensional vectors with a small metadata envelope and a monthly indexing burst. A cluster-first design may reserve memory and replicas for the entire month even if the corpus is written in one afternoon and queried sporadically. Talqora keeps the durable vector records in the regional storage layer, runs indexing work close to that layer, and keeps only active files and hot search structures in the small runtime cache. The bill follows stored bytes and actual retrieval work instead of the maximum shape of the cluster.

Indexing is cheaper for the same reason. A write is accepted in an idempotent batch, persisted to the durable vector layer, and recorded in the usage ledger only after the data-plane operation succeeds. Sparse text is committed as immutable Quickwit segments and compacted in the background. There is no requirement to keep a large resident posting list or a permanently idle embedding fleet online just because a customer might upload another file next week.

This design also reduces the cost of change. Updating or deleting a source touches the records that belong to that source and leaves unrelated vectors alone. Retries do not silently double-count successful writes, and a failed indexing batch can be retried without reconstructing the entire index. Lower infrastructure cost comes from making the unit of work small, durable, and observable, not from cutting away the controls a production system needs.

  • Storage remains durable when traffic is quiet
  • Compute and cache are sized around the active working set
  • Writes, queries, and transfer are visible as separate usage dimensions
  • A free Developer plan makes the model testable before a commitment

How low-cost indexing reaches production retrieval

The path from an uploaded document to a searchable vector is intentionally split into stages. The application submits a batch with stable IDs and an idempotency key. The indexing path validates dimensions and metadata, writes dense vectors to the regional object-storage index, and sends sparse text and metadata to the private Quickwit service. Each stage can acknowledge only the work it has actually completed.

That makes the expensive parts proportional to the input. A corpus with ten thousand records does not require a ten-thousand-record resident memory reservation after indexing finishes. The durable layers hold the full corpus, while the runtime warms only the blocks and posting lists that real queries touch. As query patterns change, the cache changes with them instead of forcing a manual re-shard or a larger node.

The result is a retrieval API that can start at zero cost for a Developer workload, remain inexpensive for a quiet production index, and still expose the same search contract when traffic grows. Teams pay for the data they keep and the work they request, then use usage history to decide when a more heavily provisioned performance profile is justified.

  • Validate dimensions and metadata before any side effect
  • Write dense vectors once with idempotent batches
  • Build sparse Quickwit segments without a database-resident posting list
  • Warm only active search data in local cache
  • Scale from real query and indexing measurements

How Talqora differs from Chroma, Qdrant, and Turbopuffer

Chroma and Qdrant can be operated in several ways, but their common deployment patterns often put more of the active database state on provisioned compute, attached disk, or a managed cluster. That can be a strong fit when an application needs a predictable resident working set, local development parity, or the operational controls of a conventional database service. It also means the customer should price CPU, memory, disk, replicas, and minimums together.

Turbopuffer is the closest architectural comparison because it also makes object storage central to a high-performance search service. The similarity is not accidental: both products recognize that immutable data, range reads, manifests, caching, and background compaction can produce a different cost/performance curve than a database that keeps every index page resident. Turbopuffer offers a broad namespace and query model; Talqora focuses on indexes, explicit regions, scoped API keys, dense vectors, BM25 sparse_text, hybrid search, and a simple console for usage-aware retrieval.

The right comparison is a workload test. Put the same number of vectors, dimensions, metadata bytes, writes, queries, result sizes, and freshness requirements into each product. Then compare p50 and p99 latency, recall, operational work, and the bill after the cache has reached a steady state.

  • Chroma: flexible application and deployment patterns, often compute-resident
  • Qdrant: powerful vector engine with resource-based cloud sizing options
  • Turbopuffer: closest object-storage-oriented comparison
  • Talqora: focused API, regional indexes, hybrid retrieval, and usage visibility

MacroDiskANN: round-trip-aware ANN for object storage

Plain DiskANN is excellent when the graph and vectors live on a fast local SSD. Its search loop follows neighbors, reads the next pages, and expands the candidate frontier. That pattern assumes random block reads with microsecond-scale access. S3 is different: it is an HTTP object service where a small request can cost more latency than a larger sequential transfer, and independent requests can be issued concurrently while dependent requests cannot.

Talqora's production indexing path is implementing a proprietary storage-aware design inspired by DiskANN, SPANN, SPFresh, and recent object-storage ANN work. We call the design MacroDiskANN. It keeps the local geometry of a DiskANN-style micrograph, but moves global navigation into a compact in-memory centroid router. The router selects object-sized macro-pages before any remote read. Those pages are fetched concurrently, then local graph traversal and high-precision reranking happen after the bytes arrive.

The optimization target is the number of dependent request rounds, not merely bytes in one object. A remote graph walk can require R sequential decisions and roughly R latency intervals. MacroDiskANN turns that chain into W waves of independent macro-page requests, bounded by concurrency. This makes the index compatible with S3 Standard for cost-sensitive storage and S3 Express One Zone when lower first-byte latency justifies its placement trade-off.

MacroDiskANN is now being rolled into the production indexing and retrieval path. Its latency target is parity with the managed dense vector path it replaces: the same query contract, the same regional placement, and the same warm-cache latency profile, without naming or depending on that provider-specific implementation. The prototype measurements still should not be confused with a published cloud benchmark; production p50, p95, p99, throttling, cache hit rate, and dollars per million queries remain workload-dependent and are tracked separately.

  • RAM router selects regions, not final neighbors
  • Boundary vectors are replicated into nearby regions to protect recall
  • Macro-pages are immutable, checksummed, and published through a manifest
  • Independent object fetches are bounded by concurrency and a byte budget
  • Local micrographs search only after the remote page is available

Product Quantization keeps pages small

A 1,536-dimensional float32 vector occupies roughly 6 KB before metadata, graph edges, and alignment. Shipping full-precision vectors in every remote page increases transfer and reduces the number of useful candidates per request. Product Quantization (PQ) compresses vectors into compact codes that can be compared quickly against precomputed sub-quantizers, while full-precision values remain available for the final rerank of a small candidate set.

In the MacroDiskANN layout, each macro-page can carry a PQ code block, vector IDs, filter metadata, local graph adjacency, and optional full-precision residuals. The query first scores PQ codes to build a candidate heap, then reads higher-precision payloads only for candidates that can change the top-k boundary. This creates a two-stage path: inexpensive broad selection followed by precise local verification.

PQ is not used to hide a recall regression. The index builder evaluates codebook quality, stores the codebook identity in the manifest, and keeps a configurable rerank depth. Workloads that prioritize recall can increase the candidate multiplier or use full vectors in hot pages. Workloads that prioritize cost can use smaller codes and rely on the local cache for frequently accessed regions.

  • PQ codes reduce bytes transferred per candidate
  • Codebooks and generation IDs are versioned with the manifest
  • Full precision is reserved for a focused final rerank
  • Rerank depth is a recall, latency, and cost control knob

Immutable macro-pages make updates cheaper

Indexing should not rewrite a multi-terabyte graph because one source changed. MacroDiskANN treats macro-pages as immutable generations. A write or delete appends the change to a durable update log, rebuilds only affected pages, writes new objects, and advances a compact manifest atomically. Readers continue using the previous generation until the new manifest is complete.

The same generation model protects retries. If an indexing task is delivered twice, its idempotency record and source version identify the already-committed generation. If a task fails after uploading an object but before publication, the orphan remains unreachable and can be reclaimed by lifecycle cleanup. This makes the expensive operation the smallest durable unit instead of a full index rebuild.

Compaction runs asynchronously. Boundary replication and tombstones are periodically folded into new pages, while hot pages can be admitted to local NVMe based on query frequency and byte cost. Index freshness, write amplification, cache residency, and object count remain visible operational variables rather than hidden side effects of a node restart.

  • Only affected pages are rebuilt for updates
  • Manifest publication is the visibility boundary
  • Failed uploads remain unreachable until lifecycle cleanup
  • Compaction reduces stale replicas and tombstones asynchronously

One API across the storage boundary

The application should not need to know whether a result came from a regional dense vector operation, a Quickwit posting list, or a cache hit. It writes vectors with an idempotency key, sends sparse_text when lexical retrieval is needed, and chooses dense, sparse, or hybrid search at query time. Metadata filters remain part of the same request contract.

This boundary lets a team change the storage implementation without rewriting its agent, search UI, or RAG orchestration. It also makes tests repeatable: write a known corpus, query it with known vectors and filters, inspect the returned IDs and scores, then measure latency and usage counters. Infrastructure can evolve behind the contract while application behavior remains stable.

For enterprise workloads, the same separation supports stricter data controls. Region is an index property, credentials are scoped to indexes, and the durable layers can be governed with cloud-native encryption, IAM, retention, and audit policies.

A practical decision checklist

Choose an object-storage-oriented retrieval layer when your corpus is large, your traffic is uneven, or you want the storage bill to remain proportional to actual usage. Choose a resident cluster when the workload is continuously hot, latency budgets are extremely tight, and paying for pinned memory is justified by that traffic.

Before moving production data, run a representative benchmark in the target region. Include cold and warm queries, bulk writes, updates, deletes, metadata filters, exact identifiers, long-tail documents, and realistic result payloads. Record p50, p95, p99, recall, query transfer, storage growth, and operational steps.

Talqora's goal is not to pretend the trade-off disappears. It is to make the trade-off visible and give teams a lower-cost default: durable object storage, a small active retrieval runtime, regional placement, and an API that stays useful as the workload grows.

  • Define the vector count, dimensions, and metadata footprint
  • Measure cold and warm retrieval in the region your users need
  • Test updates, deletes, filters, BM25, and hybrid ranking
  • Compare total monthly cost, not only storage price
  • Keep the source corpus and retrieval index independently governable