Meridian Line must decide whether to build one Vector Search index containing charter clauses, customs filings, circulars and maintenance logs with a doc_type column, or four separate indexes. The four corpora have different metadata schemas, different update cadences, and are consumed by four different applications. What is the stronger design and why?
Select an answer to reveal the explanation.
Short Explanation
You can put all four corpora in one index and filter, but then they share a schema, sync cadence, and blast radius. Since each application uses a different corpus, separate indexes give you room to manage each one independently. Split when your corpora have genuinely different needs.
Full Explanation
Index boundaries should follow the boundaries of the data and its consumers. These four corpora have different metadata schemas, chunking needs, and update cadences, and each serves a different application. Separate indexes let you manage those choices independently, keep an unrelated corpus out of an application's candidate set without relying on every query to remember a filter, and limit a rebuild's impact to one corpus. The shared-index proposal offers consistent retrieval and simpler synchronization, but those benefits matter less when no application needs to search across all four corpora, and it does not resolve their differing schemas and update schedules. The claim that one index is always cheaper overstates the cost benefit: indexes and endpoints have costs, but multiple indexes can share an endpoint, so consolidation is not automatically cheaper. The claim that a combined index cannot filter on a doc_type column is incorrect; filtering works, but that alone does not justify combining the corpora. Exam caveat: one index per corpus and consumer is a sound default, not an absolute rule; combine corpora when applications genuinely need cross-corpus search. Practical check: compare schemas, chunking, sync cadence, and application query needs before choosing index boundaries.