Choose Database-Native Search vs Dedicated Search/Vector Infrastructure

Learning outcomes

Compare database-native secondary/search features with dedicated search/vector infrastructure by query richness, freshness, scale, ranking quality, vector needs, failure isolation, operational duplication, and synchronization cost.

1. The boundary is an architecture choice, not a product popularity contest

AtlasMart can satisfy some alternate queries with database-native indexes or built-in text/vector features. A dedicated search service becomes attractive when the workload needs rich analyzers, relevance tuning, faceting, many alternate fields, high query concurrency, large vector ANN structures, independent scaling, or specialized search operations. The decision should start from access patterns and invariants. If the only need is exact lookup by email or status with immediate transactional visibility, a native index may be simpler and safer. If customer discovery needs typo tolerance, lexical relevance, facets, semantic retrieval, ranking experiments, and independent search capacity, dedicated infrastructure may justify the synchronization burden.

2. Compare the systems across the whole lifecycle

Evaluate query richness, freshness, data scale, ranking quality, vector workload, write amplification, failure isolation, security model, backup/rebuild, operator skill, and cost. Native search can reduce duplicated infrastructure and synchronization paths, but may couple heavy search to transactional resources or provide fewer ranking/vector controls. Dedicated search can isolate query load and evolve independently, but every indexed fact becomes duplicated state whose freshness and lifecycle must be governed.

3. AtlasMart lab: make the mechanism observable

Save the following as lesson5_search_boundary.py and run it with python lesson5_search_boundary.py. It uses only deterministic in-memory data and mutates no external service.

from collections import deque

workloads = {
 "admin_exact_lookup": {"rich_text":0,"vector":0,"freshness":5,"scale":2,"ranking":0,"ops_tolerance":1},
 "storefront_discovery": {"rich_text":5,"vector":2,"freshness":3,"scale":5,"ranking":5,"ops_tolerance":4},
 "semantic_related": {"rich_text":2,"vector":5,"freshness":2,"scale":4,"ranking":4,"ops_tolerance":4},
}

def choose(w):
    # Transparent teaching heuristic, not a vendor benchmark.
    dedicated = 2*w["rich_text"] + 3*w["vector"] + w["scale"] + 2*w["ranking"] + w["ops_tolerance"]
    native = 3*w["freshness"] + 2*(5-w["rich_text"]) + 2*(5-w["vector"])
    return ("dedicated-derived" if dedicated > native else "database-native"), dedicated, native

for name,w in workloads.items():
    print(name, "->", choose(w))

# AtlasMart source of truth and a dedicated derived search document.
source = {"p1":{"version":1,"title":"Trail Runner","price":120,"stock":8}}
search = {"p1":{"version":1,"title":"Trail Runner","price":120,"stock":8}}
outbox = deque()

# Authority commits version 2; projection event is durable but not applied yet.
source["p1"] = {"version":2,"title":"Trail Runner","price":99,"stock":8}
outbox.append(("p1", dict(source["p1"])))
print("source version/price:", source["p1"]["version"], source["p1"]["price"])
print("search stale version/price:", search["p1"]["version"], search["p1"]["price"])
print("freshness gap versions:", source["p1"]["version"] - search["p1"]["version"])

# Replay projection idempotently.
while outbox:
    pid,event = outbox.popleft()
    if event["version"] >= search.get(pid,{}).get("version",0):
        search[pid] = event
print("after replay search version/price:", search["p1"]["version"], search["p1"]["price"])

# Deliberately damage the derived index; source remains authoritative.
del search["p1"]
print("derived search missing p1:", "p1" not in search)
print("source still has p1:", "p1" in source)

# Full deterministic reconciliation/rebuild.
for pid,doc in source.items(): search[pid] = dict(doc)
extra = set(search) - set(source)
missing = set(source) - set(search)
wrong_version = {pid for pid in source if search[pid]["version"] != source[pid]["version"]}
print("rebuild missing/extra/wrong_version:", sorted(missing), sorted(extra), sorted(wrong_version))

4. Make authority and synchronization explicit

A robust polyglot boundary says “the catalog database owns product price and stock; the search index is a derived retrieval view.” A transaction commits the source fact and a durable change stream/outbox/CDC mechanism makes that change replayable. The projector writes idempotently using a monotonic source version or equivalent ordering token. Search responses can carry that version for diagnostics. If the index is stale, a correctness-sensitive checkout hydrates authoritative price/stock from the source rather than trusting an old search document. This preserves the retrieval benefit without silently transferring business authority.

5. Reconciliation is what turns eventual synchronization into an operable system

Retries do not prove every change was applied exactly once or in order. AtlasMart needs a reconciliation process that compares source and derived state using counts, keys, versions, checksums, sampled field comparisons, or domain invariants. Full rebuild should be rehearsed from a known source snapshot plus catch-up stream. Measure source-to-index lag, oldest pending event age, projection error rate, missing/stale document count, refresh/segment/merge pressure, vector build backlog, and query success/latency. A derived index that cannot be rebuilt safely is closer to a hidden system of record than the architecture diagram admits.

6. Security and tenant isolation cross the boundary too

Search copies often contain denormalized customer, product, entitlement, or behavioral fields. Authorization must not rely on the source database protecting data that has already been copied into another system. Enforce tenant/visibility filters inside search requests, minimize indexed sensitive fields, secure ingestion and administrative APIs, encrypt transport/storage as appropriate, and test facet/aggregation leakage. For vector search, embeddings may encode sensitive information or enable inference, so retention and access rules apply to vectors as data—not merely to the original text.

7. Migration, rollback, and cost

Introduce a dedicated index through shadow ingestion, backfill, dual-read comparison, freshness/error dashboards, and gradual traffic cutover. Keep a rollback path to native/database queries while the source remains authoritative. Cost modeling includes search nodes, replicas, hot/warm storage, vector memory, ingest/merge CPU, network/egress, backup snapshots, observability, operator time, and duplicate retained data. Elasticsearch 9.5.2 and OpenSearch 3.8.0 are current examples with different licensing and operational ecosystems; neither is automatically the right answer. The correct boundary is the one whose measured retrieval benefit exceeds synchronization and operating cost while preserving business invariants.

8. Bridge to access-pattern-driven modeling

This chapter treated secondary indexes, inverted search, global index structures, and ANN as alternate representations created to make specific reads cheaper. Chapter 15 generalizes that idea: denormalization and materialized views are precomputed work. The same questions return—who owns the fact, which query is being optimized, how many copies change on a write, what staleness is acceptable, how are projections rebuilt, and what evidence proves the copies have converged? Search is therefore not a separate design universe; it is one specialized case of access-pattern-driven data modeling.

Wrong approach: let the dedicated search index quietly become the source of truth

Verification, cleanup, and production checklist

Verification is the deterministic program output plus the conceptual checks below. Cleanup is deleting the local lesson5_search_boundary.py file; the lab creates no sockets, databases, containers, credentials, indexes, or cloud resources. In production, additionally record authoritative-versus-derived ownership, source/index versions, refresh or projection lag, p95/p99 read/write latency, index size and write amplification, shard/index-key skew, rebuild throughput, ANN recall where applicable, tenant/authorization tests, backup/rebuild evidence, current security advisories, and edition/license constraints before relying on a product-specific feature.

References

Foundational statements use primary research or standards where appropriate. Version-sensitive implementation examples use current official documentation and remain explicitly scoped to the cited product/version.

• Elasticsearch 9.5.2 — Current distribution snapshot: 9.5.2, released 2026-08-20; default distribution under Elastic License 2.0.
• Elastic licensing FAQ — Current distribution/source licensing context, including ELv2 and source licensing options.
• OpenSearch 3.8.0 — Current release snapshot: 3.8.0, released 2026-08-04, Apache License 2.0.
• Elasticsearch — Near real-time search — Current visibility/refresh example for a dedicated search index.
• Elasticsearch — kNN search — Current vector/hybrid retrieval implementation reference.