Engineering leaders choosing a data stack for enterprise retrieval-augmented generation (RAG) must decide how database, document-processing, and operating choices fit together. Fast vector search alone cannot compensate for missing document structure, stale content, or an incomplete cost estimate. This guide explains how to compare database options, test parsing and updates, and estimate total cost using a representative workload.
Key takeaways
- Start with the workload: Query patterns, filters, update frequency, and operating capacity matter more than the database category.
- Evaluate parsing separately: A vector index cannot recover information omitted or misread by the document pipeline.
- Price the complete workflow: Include ingestion, embeddings, retrieval, model calls, infrastructure, and maintenance over a common period.
- Separate architecture from operations: An extension or dedicated database may be managed or self-managed; these choices can overlap.
Compare database approaches on the same task
An existing database extension can be attractive when the team wants to keep vectors near application data and already knows how to operate that database. For example, pgvector adds exact and approximate vector similarity search to PostgreSQL. Its suitability depends on the workload and configuration.
A dedicated vector database can be worth evaluating when retrieval needs its own scaling or operational boundary. Managed services may reduce some infrastructure work, while self-managed installations leave more responsibility with the team. Neither database category establishes a performance winner without testing.
For a database-only comparison, hold the source snapshot, document parsing and chunking configuration, embedding model, vector dimensions, query set, distance metric, filter conditions, and requested result count (top-k) constant. Record software versions, index type and search parameters, hardware or service tier, cache state, and concurrency. Tune each candidate to a common quality target rather than forcing identical internal settings.
Distinguish approximate nearest-neighbor (ANN) recall against exact nearest-neighbor results from relevance judged against labeled evidence and from final answer correctness. Exact vector search is different from exact identifier or text matching. Test lexical search, metadata filters, and hybrid retrieval on precise lookup tasks, and measure filtered search quality under the chosen index settings.
Data table · Scroll sideways to see all columns. Use arrow keys when focused.
| Workload question | Evidence to collect |
|---|---|
| How quickly do documents change? | Ingestion-to-searchable lag and update/delete visibility lag across indexes and caches, including retries and recovery from partial failures |
| How selective are filters? | Filtered relevance, ANN recall, and short-result rate: queries returning fewer than top-k results when enough eligible matches exist |
| Which queries need exact matches? | Identifier and exact-string retrieval accuracy using lexical, metadata, or hybrid approaches |
| How much concurrency is required? | p50/p95 retrieval latency and throughput at stated concurrency and quality targets, separate from end-to-end answer latency |
| How are permissions updated? | Access-revocation behavior across retrieval, cached answers, and downstream consumers |
| What happens during recovery? | Restore time, data integrity checks, and operator hours |
Test the parser before tuning retrieval
Prepare an annotated set of documents that reflects actual languages, scanned pages, digital PDFs, tables, multicolumn layouts, and repeated headers. Include difficult examples, not just clean demonstrations.
Unstructured's partitioning documentation describes turning documents into typed elements and provides format-specific processing options. Consult the selected format and strategy documentation; format support does not guarantee correct extraction from every file.
Inspect reading order, table row and column associations, identifiers, page references, and missing sections. On the annotated samples, record field and table-association accuracy, omissions, elapsed processing time, throughput in pages per minute, retry or reprocessing volume, and human correction time. Then test whether retrieved passages retain the table headings and surrounding context needed to support an answer. OCR text accuracy, structural parsing quality, and final answer correctness are separate evaluations.
Pin each candidate's parser version and strategy for repeat runs, keep the input set fixed, and record hardware differences. Store failed examples with their processing configuration and expected output so comparisons remain reproducible.
Plan for updates without rebuilding everything unnecessarily
Keep source documents, parsed text, chunks, embeddings, and indexes separately versioned with configuration metadata. A content change may require downstream reprocessing; a metadata or permission change may follow a different path. An embedding-model change does not by itself require reparsing valid source text. Reuse valid parsed text, regenerate the required embeddings, and rebuild or switch indexes as needed.
Use document and query encoders designed to produce compatible representations, following the model provider's recommended versions and task-specific settings. Verify vector dimensions, distance metrics, normalization, document chunking, and index cutover or rollback procedures. Avoid mixing incompatible old and new embeddings in the same search space, even when dimensions match.
Test deletion propagation separately from access revocation. After permissions change, verify that affected users cannot retrieve or receive restricted content through search, cached answers, or downstream consumers. This need not require deleting records still available to authorized users. Automatic synchronization does not establish immediate visibility, and previously delivered answers cannot be retroactively recalled. Measure update visibility and failure recovery across the configured pipeline against the application's freshness requirements.
Build a total-cost worksheet
Compare options over the same operating period, workload, quality target, and availability requirement. Combine one-time implementation and migration expenses with recurring operating costs. Request current pricing for the intended region, service tier, and support commitment; record quote dates, included usage, and overage rates.
Data table · Scroll sideways to see all columns. Use arrow keys when focused.
| Cost area | Inputs to estimate |
|---|---|
| Document processing | New and changed files, difficult pages, retries, and review labor |
| Embeddings | Initial corpus, updates, token volume, and planned re-embedding |
| Retrieval | Chunk/vector counts, dimensions, index build and storage overhead, query load, and optional reranking |
| Answer generation | Model token usage and tool calls for representative tasks |
| Infrastructure | Compute, replicas, backups, networking/egress, and monitoring |
| Operations | Setup, source integration, maintenance, upgrades, and incident response |
| Licensing and support | Subscription/license fees, support commitments, included usage, and overages |
| Migration and exit | Export, migration labor, reindexing, and temporary parallel operation |
Estimate labor as hours multiplied by a fully loaded hourly rate, including compensation, benefits, and allocated overhead. Estimate usage as measured volume multiplied by applicable quoted rates. Separate initial setup, recurring costs, and one-time events. Count each cost once: do not add infrastructure or storage already included in a service bundle, and retain the internal labor the customer still performs. Assign shared items such as egress to one cost line only.
Model ordinary usage and peak demand separately. Chunk count, vector dimensions, and index overhead affect storage and memory requirements. Dedicated capacity can offer a different billing structure, but it does not guarantee lower cost or eliminate performance limits.
Decide how much of the pipeline to integrate
Assembly, managed operation, and platform integration are overlapping choices. A custom or open-source stack needs an owner for its connections, whether an internal team or a provider. Managed services may reduce selected infrastructure tasks; an integrated platform may reduce repeated connection work within its supported scope.
Seahorse Cloud combines S3-compatible object storage, document parsing, semantic chunking, automatic vector database synchronization, and managed agents. Within supported workflows, this can reduce repeated custom code connecting parsing, chunking, and vector indexing. Confirm any custom ingestion work, permission enforcement, freshness requirements, and operational responsibilities in the selected deployment and service agreement.
Treat hosting location and operating responsibility separately. An on-premises installation can still depend on external model APIs, package repositories, or telemetry endpoints. Test the required network policy instead of assuming self-hosting guarantees an air-gapped system.
The strongest decision is supported by a reproducible workload, visible failure cases, and a complete cost model. Those records remain useful as the source collection or application grows.
FAQ
Does a dedicated vector database always outperform an extension?
No. Compare relevance, filtering, latency, throughput, and operating effort under the same workload and quality target, with each configuration documented.
Does changing an embedding model require parsing every document again?
Not necessarily. Reuse parsed text if it accurately represents the source and meets the new pipeline's input needs. Generate compatible document and query embeddings for the new model, and rebuild or switch indexes as needed. Matching dimensions alone do not make old and new embeddings compatible.
Is a managed platform always less expensive?
No. Compare both options over the same workload, service requirements, and operating period, including service fees, usage, integration, retained internal labor, infrastructure, and migration costs. Avoid double-counting costs already included in a service bundle.