When engineering leaders and platform teams move document search systems into production, they must simultaneously evaluate document parsing, storage, retrieval, permissions, and operating models. This guide outlines a five-step process to choose and validate each layer of the search architecture. Because authorization policies and deployment constraints shape every phase, teams should incorporate them into initial system design rather than postponing them to final review.
Key takeaways
- Inspect parsing before tuning retrieval. Lost table headers or section boundaries can undermine an otherwise capable search system. Test the source formats that matter to the application.
- Choose storage using measured contention and capacity. A PostgreSQL extension can colocate vectors with relational data; a separate vector or search service can isolate workloads. Vector count alone does not establish a migration threshold.
- Evaluate lexical and semantic retrieval together. Hybrid search can help with exact identifiers and paraphrases, but tokenization, filtering, fusion and reranking still affect the result. Measure whether the expected evidence appears in the returned candidates.
- Verify permissions through the full workflow. A source-aware connector may simplify permission mapping, while a custom pipeline must explicitly implement its chosen authorization design. Test revocation and denied queries in either case.
- Separate deployment dimensions. SaaS terms, hosting location, cluster operations and offline support are distinct. Record who operates each component in the proposed Seahorse deployment.
Step 1. Document Parsing & Chunking
Retrieval failures can originate in ingestion before a query reaches the index. A text-only extraction may lose layout metadata, merge columns or flatten tables, depending on the extractor and input. A lost table boundary can separate a value from its row label or column header. The resulting chunk may no longer contain enough context to answer a question correctly.
A representative document-ingestion pipeline includes these stages:
- Raw File Ingestion: Input multi-format files including PDFs, Office documents, and scanned images.
- Layout Analysis and OCR: Detect layout hierarchies and optical characters using layout parsers such as Google Cloud Document AI or LlamaParse.
- Structured Extraction: Isolate structured elements, including tables, section headers, figures, and body text.
- Chunking: Partition contextual elements, then verify that the chosen boundaries preserve required table and header relationships.
- Vector and lexical indexing: Generate the embeddings and lexical indexes used by the selected retrieval design.
Document layout preservation affects whether table headers remain associated with their cells during retrieval. Google Cloud Document AI layout parsing documentation describes layout-aware processing and chunking. Have document owners check representative files for correct header-to-cell relationships, page references and retained meaning.
Comparison table Scroll to view every column ↔
| Parsing candidate | What to evaluate | Evidence to retain from the test |
|---|---|---|
| Google Cloud Document AI | Layout parsing and chunking for supported formats | Header/cell associations, page references and extraction failures |
| LlamaParse | Parsing output appropriate for the downstream workflow | Output structure, preserved context and handling of difficult pages |
| Seahorse Cloud | Integrated document parsing, semantic chunking and vector synchronization | Extracted text/structure, resulting chunks and retrieved evidence after an update |
For an integrated option such as Seahorse, inspect both parser output and the chunks delivered to retrieval. Evaluate representative scans, merged headers, multi-page tables and charts directly, with document owners checking the extracted meaning. An integrated flow connecting S3-compatible object storage, autonomous parsing, semantic chunking, and automatic vector database synchronization can reduce repetitive integration code; teams should verify which source connectors, ACL mappings, and custom pipeline steps are provided versus built in-house.
When selecting an ingestion tier, platform teams must isolate their primary document profile:
- Multilingual scanned archives: Verify language support, OCR quality and failure handling on the actual scan quality.
- Technical documentation and multimodal RAG: Test whether the selected parser retains the relationships needed to answer table, chart and cross-section questions.
- Integrated storage architectures: Check which parser-to-index interfaces are included and which still require integration work.
Once parsing and chunking boundaries preserve document context, teams can evaluate where and how to store the resulting vector and lexical representations.
Step 2. Vector Storage Selection
Once documents are parsed and chunked, engineering teams face an architectural choice: store embeddings inside existing operational databases using extensions, adopt dedicated vector databases, or leverage distributed search engines.
The primary storage archetypes break down as follows:
- Relational Extensions: Co-locate application data and vector embeddings within PostgreSQL using pgvector.
- Dedicated Vector Stores: Separate relational application data from high-scale vector embeddings stored in Pinecone or Qdrant.
- Hybrid Search Engines: Combine full-text BM25 indexes with vector k-NN search across distributed shards in Elasticsearch or OpenSearch.
Relational Extensions: PostgreSQL with pgvector
For organizations already running PostgreSQL, pgvector can avoid adding a separate database when the workload fits the existing PostgreSQL deployment. It enables developers to store embeddings in standard relational tables, query vectors alongside transactional columns, and apply relational filters within a single SQL transaction.
However, indexing mechanics introduce clear trade-offs:
- HNSW (Hierarchical Navigable Small World): The pgvector documentation describes a speed/recall trade-off against IVFFlat, with greater memory use and build-time considerations. Tune and measure for the workload.
- IVFFlat (Inverted File Flat): Compare build cost, memory and query recall with HNSW using representative data and selected index parameters.
- Index construction: PostgreSQL supports concurrent index builds to avoid blocking ordinary writes, but the operation still consumes resources and has restrictions. Measure build and query behavior together. The pgvector documentation discusses indexing and bulk loading.
Dedicated Vector Databases: Pinecone and Qdrant
A separate vector service can isolate retrieval resources from an application database. Compare that option when indexing or query load creates contention. Measure its latency, capacity and operating cost against the current database.
Pinecone and Qdrant are candidates to compare for the intended storage, filtering and query workload. Verify write acknowledgement separately from search visibility, and test updates and deletes under load. Record the service's consistency behavior, capacity limits and failure responses for the selected version or plan. Do not assume all writes are immediately searchable.
Distributed hybrid engines: Elasticsearch and OpenSearch
Elasticsearch's hybrid search explanation describes combining lexical and semantic retrieval. A distributed search engine can be appropriate when the application also needs full-text search, filters and related search functions. Its indexing and query workloads still compete for finite resources; measure ingestion, refresh and retrieval together.
Comparison table Scroll to view every column ↔
| Storage approach | Useful architectural property | Workload test |
|---|---|---|
| PostgreSQL with pgvector | Vectors and relational data can share a database | Query recall/latency, index build impact, memory and transactional contention |
| Dedicated vector service | Retrieval storage and compute can be separated from the application database | Search visibility after writes, filtering behavior, capacity and update/delete handling |
| Distributed hybrid search engine | Lexical and vector retrieval can share a search system | Refresh behavior, shard/index configuration and concurrent indexing/query load |
Compare backup, recovery and operator responsibilities alongside speed. A self-hosted engine, a managed service and a cloud database extension can each have different operational boundaries even when they expose similar search functions.
Measure all storage options under identical document, chunking, embedding, query, filter, and top-k parameters while maintaining the same target for candidate recall. Note that ANN recall measures vector candidate retrieval accuracy, whereas end-user relevance measures whether the retrieved context answers the query. Apply each performance metric—p95/p99 latency (ms), concurrent QPS, index build time, hardware resources, update lag, monthly operating hours, and total cost—across every candidate rather than treating them as vendor-specific tests. Tune each candidate to the same measured retrieval-quality target before comparing latency and cost; record index/search settings and test concurrency.
With storage candidates established, the next step is to evaluate retrieval quality on the application's actual queries.
Step 3. Retrieval Quality: Hybrid Search & Reranking
Dense retrieval can miss a required identifier or prefer a conceptually related passage depending on the embedding model, indexed content, and query configuration. Include error codes, part numbers and short terms in the evaluation set alongside paraphrased questions.
Hybrid search combines dense retrieval for semantic similarity with lexical retrieval for terms. It can address some missed matches, but analyzers, filters and ranking still determine which candidates are returned.
One hybrid retrieval design with reranking proceeds through four operations:
- Parallel Query Execution: The incoming user query routes simultaneously to sparse lexical retrieval (such as BM25) and dense semantic vector search.
- Result Fusion: Candidate lists from both retrieval paths merge using Reciprocal Rank Fusion (RRF) or linear score combination.
- Cross-Encoder Reranking: A secondary reranker evaluates the fused candidate pool to re-score context relevance.
- Top-K Selection: The final ranked top candidates are returned to the application or language model context window.
According to Elastic, hybrid search combines full-text lexical scoring and semantic nearest-neighbor retrieval into a unified ranked list using Reciprocal Rank Fusion (RRF) or linear score combinations. Elasticsearch allows teams to configure lexical BM25 and vector queries within a single request, subsequently applying secondary cross-encoder rerankers to score top candidates.
The implementation can live in the database, search engine or application, depending on the selected interfaces. In PostgreSQL, a design can combine full-text search with pgvector candidates and perform fusion in application code. For Qdrant, Pinecone or another service, verify the supported dense/sparse query path for the selected version and configuration before adopting an example.
Test each stage separately:
- Lexical candidates: Verify tokenization of punctuation, identifiers and acronyms; check that filters do not remove authorized relevant material.
- Dense candidates: Measure retrieval for paraphrases and context-dependent questions.
- Fusion: RRF combines ranks rather than requiring scores from different retrievers to be directly comparable. Candidate counts and fusion settings still need evaluation.
- Reranking: Measure whether reranking improves the chosen relevance metric and its latency cost. It cannot recover a passage excluded from the candidate pool and does not guarantee the answer at rank one.
Retain expected relevant passages and actual results for regression testing. Search quality and generated-answer correctness are related but separate evaluation targets.
Retrieval quality must be evaluated alongside authorization enforcement so that restricted content does not reach an unauthorized user or model context.
Step 4. Permissions & Connectors
Building an internal search layer requires balancing custom pipeline development against turnkey enterprise search platforms. The primary architectural boundary between these approaches lies in connector depth and access control governance.
For either architecture, map source identities and permissions to the application's authorization model. A custom pipeline does not inherently discard ACLs; it must deliberately preserve or implement the required controls. A connector that imports permissions also needs testing for supported source types, synchronization delay and revocation behavior.
Glean's explanation of indexing external support databases discusses source permissions and document-level access. The security team should test the proposed connectors and identity mapping. Measure how quickly an access revocation affects retrieval for each required source.
Database filters, namespaces and service-level roles are different from end-user document authorization. Verify that the application cannot bypass the intended filter, that direct API access is appropriately restricted and that retrieved context does not leak across users or tenants.
Comparison table Scroll to view every column ↔
| Access governance area | Question for either a packaged or custom proposal |
|---|---|
| Permission mapping | Which source permissions and identity types are supported? |
| Enforcement | Where is the caller authorized, and can an alternative query path bypass it? |
| Revocation | How quickly do permission changes affect retrieval and saved context? |
| Connectors | Who handles source API changes and unsupported permission semantics? |
| Investigation | Which allowed/denied events are recorded, exported and retained? |
Test with two users who have different permissions, then revoke one user's access and repeat the query. Inspect both retrieved passages and generated answers. A correct document filter does not establish the behavior of a separate memory or cached-answer path.
Organizations must decide whether their search problem is primarily application-specific (e.g., retrieving context for a single customer support agent workflow) or workplace-wide (e.g., searching across all company documentation and collaboration tools). For an application-specific workflow, prioritize the required retrieval interface and integration. For workplace-wide discovery, pay particular attention to connector coverage and permission mapping. Either scope can use an integrated or assembled implementation.
Once authorization policies and connectors are established, platform teams must define the operational boundaries and deployment model.
Step 5. Deployment & Operating Responsibility
Deployment model, hosting location, operating responsibility, and network dependencies should be evaluated separately. On-premises deployment does not by itself establish disconnected operation.
Managed capacity and customer-operated infrastructure
A managed service can transfer capacity and infrastructure tasks to a provider. Confirm minimum capacity, scaling limits, recovery responsibilities and how the service behaves during a traffic spike. Reserved capacity or a customer-operated database may fit other workloads, but neither guarantees stable latency without measurement.
When comparing a serverless service with reserved or self-managed capacity, measure steady and burst traffic, update volume, recovery behavior and total cost over the same period. Include the maintenance hours that remain with the platform team.
On-premises and network-restricted deployment
A requirement for local processing must cover parsing, embeddings, inference, retrieval, logs and tools as well as source storage. Self-hosted software can still depend on external APIs. Verify package distribution, updates, licensing and support access when disconnected operation is required.
Seahorse Cloud documents Kubernetes-native architecture combining S3-compatible object storage, a vector database, document parsing and managed agents, available as on-premises installation or SaaS subscription. Integrating storage, parsing, vector indexing, and managed agents can reduce the number of component interfaces a team must connect in supported workflows; the actual integration work and operating responsibilities still depend on the selected configuration. For the selected Seahorse Cloud offering, confirm the scope of cluster provisioning and ongoing maintenance responsibilities in the deployment and service agreement.
Seahorse Cloud documents managed agents with MCP-standard tool calling support. Confirm which action tools, authentication handshakes, and execution boundaries are configured in your deployment.
AgentOps responsibilities should also be evaluated separately. Test action execution permissions, audit logging scope, duplicate execution prevention, failure handling, and retry safety in your operational environment. Protocol-level authorization mechanisms do not by themselves define application-specific action permissions, approval policies, or retry safety.
Bring the five decisions together in an acceptance plan covering parsing fidelity, retrieval quality and latency, permission enforcement, and operating ownership. Validate that plan on representative documents and workloads before production deployment.
Frequently asked questions (FAQ)
When should we move from PostgreSQL with pgvector to a dedicated vector database?
Consider a separate service when measured retrieval or index-build load creates unacceptable contention, capacity limits or operational constraints. Compare tuning and isolation options in the current database with a representative test of the proposed service. Vector count alone is not a sufficient migration rule.
Why do users fail to find documents when searching for single words or exact part numbers?
Depending on the embedding model, indexed content, and query configuration, dense retrieval can miss exact identifiers or short terms. Hybrid search can add lexical candidates, but tokenization, authorization filters, and ranking still affect the results. Inspect the candidate sets and evaluate fusion and reranking; exact matches are not guaranteed.
How does document parsing degrade retrieval quality on technical data sheets?
If extraction loses the relationship between a value, its row label and its column header, the indexed passage may no longer support the intended answer. Test layout-aware parsing on the actual documents, inspect the resulting chunks and retrieve known facts. No parser can be assumed to preserve every table correctly.
Can dedicated vector databases handle document-level permissions automatically?
A database's filtering or role controls do not by themselves synchronize permissions from enterprise repositories. Determine whether a supported connector supplies that mapping or the application must implement it. In either case, test allowed and denied queries, direct API access and source permission changes.
Does deploying a Kubernetes-native unified RAG platform eliminate infrastructure management?
Kubernetes-native describes an architecture, not an operating agreement. Seahorse documents integrated storage, parsing, a vector database and managed agents with on-premises or SaaS delivery. Confirm who owns cluster provisioning, scaling, patching, network security and recovery in the selected offering; those duties should not be assigned automatically to the customer across all deployments.