PATTERN Cited by 1 source

Vendor-to-internal graph migration

A structured approach to replacing a third-party managed graph database with an internally operated solution, using shared query language compatibility (both support Gremlin) to enable side-by-side benchmarking on shadow traffic before production cutover.

Pattern shape

1. Shared query language gate: Both old (vendor) and new (internal) engines must support the same query language so queries can run against both without rewriting.
2. Shadow traffic benchmarking: Route production read traffic to both engines in parallel; compare latency, correctness, resource utilization.
3. Read/write isolation: Both solutions isolate read and write traffic at the engine layer, enabling independent benchmarking.
4. Client-side query optimization pass: Even with the same query language, different engines optimize differently — expect a round of patterns/client-side-query-rewriting to compensate for planner differences.
5. Production cutover: After shadow benchmarks confirm parity or improvement, switch production traffic; deprecate vendor.

Trade-offs

• Pro: Data-driven migration decision; no blind cutover.
• Pro: Shared query language minimizes application-layer changes.
• Con: Requires dual-running infrastructure during migration period.
• Con: Query planner differences surface only under real workload — can't be fully caught by unit tests.

Seen in

• sources/2026-05-19-airbnb-scaling-identity-graph-unified-knowledge-graph-infrastructure — Airbnb migrated their identity graph from a third-party SaaS graph DB to internal JanusGraph + DynamoDB. Both supported Gremlin, enabling side-by-side benchmarking. Migration gains: significant P99 reduction, elimination of periodic manual reboots, 10× write QPS via auto-scaling, faster incident investigation.

Related

• patterns/client-side-query-rewriting — often needed during migration
• systems/janusgraph — Airbnb's target engine
• concepts/identity-graph — the workload migrated