06-reference/research

caf fabric neptune vs snowflake native backend

2026-07-30·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
phdatacaffabricknowledge-graphsnowflakeneptune

Neptune vs. a Snowflake-Native Typed-VARIANT + Cortex Search Spine for CAF's Fabric

The question

"What are the tradeoffs between Neptune (or another dedicated graph DB) and a Snowflake-native typed-VARIANT + Cortex Search spine for CAF's Fabric backend, and which established mid-size deployments have made this call?"

Context: [[caf-die-roadmap-v1]] names this as a live fork (Lane A: Snowflake-native backend in NEXT, Neptune/AWS backend formalized in LATER) for the Fabric, which is the wedge of the whole CAF bet.

What we already know (from the vault)

What the web says

Convergences and contradictions

Synthesis for RDCO

The technology decision is already made, and this research does not overturn it - it changes what has to go inside the decision. Everything load-bearing points the same way: the funding gate is a Snowflake-native artifact, the consumption layer already runs Snowflake-native via App Runtime, the catalog data model already ratified typed spine + VARIANT with a portability DAL, Cortex Search inherits RBAC inside the governance perimeter, and Snowflake's own benchmark says the precomputed-structure design outperforms traversal-heavy agent architectures for exactly this class of retrieval. Neptune's genuine advantages (mature managed traversal, IAM-native, RDF + property graph in one service) buy capabilities the Fabric's provenance workload probably does not need, at the cost of splitting producer and consumer across two governance domains. The honest framing for ticket 1.4 stays what [[roadmap-v1-founder-notes]] already set: Neptune is the AWS adapter and the best-positioned reader of the provenance model, not a rival hub.

What changes is the confidence basis, and this is the actionable part. There is no external precedent to stand on. No named mid-size deployment has publicly made this call, and the closest named deployments are a different architecture (RelationalAI coprocessor) at a different scale, cited secondhand. So 1.3 must be written as a falsifiable design note rather than an appeal to industry practice. Two concrete acceptance-criteria additions worth making before the note circulates: (1) enumerate the Fabric's actual query set from §4's provenance model and state a maximum hop depth the Snowflake backend commits to serving, with a recursive-CTE latency budget attached; (2) name the falsification trigger in advance - if the required query set turns out to need unbounded traversal, shortest-path, or graph algorithms like community detection, that is the signal to promote a graph engine from index-adapter to index-of-record. Writing the trigger down before the Neptune session is what keeps 1.4 from becoming a re-litigation.

The second thing to carry into 1.3 is the RDCO lived lesson, because it predicts the CAF failure mode. The DuckDB prototype ([[prototype-results]]) got all its queries under 10ms on the first try and still fell short, because cites could not distinguish agreement from dissent and free-text authors broke entity resolution. The Fabric will hit the identical wall one layer up: produced_by and supersedes are cheap on any backend, but the edges that make the Fabric worth owning (which artifact informed a decision, which eval validates a capability, which approval gates what) are semantic modelling work that neither Neptune nor Snowflake gives you. That is also the Fluree observation about entity resolution and business-context encoding staying application-level. Concretely: the backend choice is roughly a wash on the things a buyer would compare, and decisive on nothing that determines whether the Fabric works. Saying that plainly in 1.3 is a stronger PM move than a feature matrix, because it reframes the fork as low-stakes and puts the spec back at the center.

Two watch items and one calibration note. Watch item one: RelationalAI as a graph coprocessor over Snowflake tables is a real third option that has not been named in any CAF artifact I can find, and it is the one path that gets traversal without leaving the Snowflake governance perimeter; worth a single line in 1.3's open-questions list so it is on the record, not a workstream. Watch item two: the App Runtime dependency in Epic 3 is public preview per [[caf-die-roadmap-v1]] ticket 3.1, so "Snowflake-native" currently rests on a preview surface, which is a fair thing for a sponsor to ask about. Calibration: this brief reads polished vault artifacts, not the room. The founder sits inside the DIE org and knows the Murray and Troy dynamics firsthand; if his read is that 1.4 needs to be a genuine bake-off rather than an adapter mapping, that read outranks this analysis.

Why this is in the vault

It determines how CAF/DIE Epic 1 ticket 1.3 (Snowflake backend design note) is written - specifically whether it carries a bounded query set, a hop-depth commitment, and a pre-registered falsification trigger - and whether ticket 1.4's Neptune working session is scoped as adapter mapping or as a backend bake-off. That scoping is what decides whether the founder's Fabric spec or Murray's already-running Neptune graph becomes the de facto hub of phData's DIE program.

Open follow-ups

Related

Sources

Vault

Web — fetched and read in this run

Web — search results only, not individually fetched (treat as directional)

Paywalled / skipped: none encountered.

Not found: no named mid-size deployment publicly documenting a Neptune-vs-Snowflake-native-KG backend decision. Stated as an absence of evidence, not as evidence of absence.