# Neo4j Features and Practical Usage 🚪 Pick the wrong data-import method up front and every downstream step pays for it. Neo4j's "Import your data" hub helps you choose the right entry point based on scale and frequency. 🏷️ Title: Import method selection guide 🔗 URL: 📘 Overview Neo4j offers several ways to load data, each with different strengths in terms of scale, execution mode (online vs offline), and permission requirements. This page is not a step-by-step tutorial but a decision hub for choosing the right method before you start. ⚙️ How It Works The main options are: ・Data Importer: a browser-based GUI where you drag and drop CSVs and visually map columns to nodes and relationships. No Cypher required; ideal for testing and prototyping. ・`LOAD CSV`: a general-purpose Cypher-based loader. Runs online (database stays up) and is usable by non-admin users. Good up to hundreds of thousands or low millions of rows. ・`neo4j-admin database import`: an offline bulk loader that writes directly to the native store format, making it the fastest path for initial loading of very large datasets (billions of entities). ・Connectors / APOC: continuous sync via Apache Spark, Kafka, and CDC, plus support for diverse formats like JSON, XML, and XLS. 🛠️ Practical Usage Decide the entry point by scale and frequency: ・A few thousand master records, fast → Data Importer (GUI) ・Millions of rows on a schedule / incremental → `LOAD CSV` (made idempotent with `MERGE`) ・Billions of entities, one-shot initial build → `neo4j-admin database import` (offline) ・Always-on continuous sync → Kafka / CDC / Spark connectors Whatever the path, a shared best practice is to create a uniqueness constraint on the key column before importing. ```cypher CREATE CONSTRAINT person_id IF NOT EXISTS FOR (p:Person) REQUIRE IS UNIQUE; ``` 💡 Use Cases Early in a project, split the paths: Data Importer for the PoC, `neo4j-admin import` for the production initial build, and `LOAD CSV` for daily incrementals. This keeps validation light and fast while making the bulk load as fast as possible. ⚠️ Caveats ・`neo4j-admin import` targets an empty database and runs offline, so it cannot be used against a live database. ・`LOAD CSV` tends to hit memory issues as row counts approach hundreds of thousands to millions; split work with `CALL { } IN TRANSACTIONS`. ・Continuous sync (Kafka/CDC) is distinct from initial loading and should be designed alongside it. ・This page is just the entry point; confirm the details of each method in its dedicated docs. #Neo4j# #DataImport#

# Neo4j Features and Practical Usage 🔒 Create one uniqueness constraint before importing—and you get duplicate-proof MERGE plus fast lookups at the same time. The official docs list it as a prerequisite step for imports. 🏷️ Title: Uniqueness / Property existence / Node key constraints 🔗 URL: 📘 Overview Constraints enforce rules that nodes and relationships must satisfy, at the database layer. They guarantee key uniqueness and required properties, keeping entities consistent even when multiple pipelines write to the graph. Uniqueness constraints also create a backing range index, so lookups get faster too. ⚙️ How It Works ・Property uniqueness: guarantees a property value (or combination) is unique per label/type. Available in Community Edition, with a backing range index that optimizes MERGE and imports. ・Property existence: guarantees a given property is always present (Enterprise only). ・Property type: guarantees a property has the required type, preventing schema drift (Enterprise only). ・Key constraints (Node key / Relationship key): combine uniqueness and existence—equivalent to a composite primary key (Enterprise only). 🛠️ Practical Usage The uniqueness constraint to always create before importing: ```cypher CREATE CONSTRAINT person_id IF NOT EXISTS FOR (p:Person) REQUIRE IS UNIQUE; ``` A node key (composite key) and an existence constraint: ```cypher CREATE CONSTRAINT order_key IF NOT EXISTS FOR (o:Order) REQUIRE (o.tenantId, o.orderId) IS NODE KEY; CREATE CONSTRAINT user_email_exists IF NOT EXISTS FOR (u:User) REQUIRE IS NOT NULL; ``` Inspect and drop them: ```cypher SHOW CONSTRAINTS; DROP CONSTRAINT person_id IF EXISTS; ``` 💡 Use Cases ・Create a uniqueness constraint before a bulk import to get duplicate prevention and speedup in one move. ・Enforce key integrity for master-data nodes at the DB layer, preventing doubling even with multiple writing pipelines. ⚠️ Caveats ・Everything except uniqueness (existence, type, key) is Enterprise Edition only; Community supports uniqueness alone. ・Creating a constraint on data that already violates it fails. Clean the data first. ・Bulk imports are validated against active constraints and can fail on violations. ・For more sophisticated or centralized schema management, defining a schema via a graph type is recommended. #Neo4j# #Cypher#

# Neo4j Features and Practical Usage ⚡ "Even in a graph DB, index design is 80% of performance." Put the right index on your MATCH anchor property and lookups go from O(n) to O(log n). 🏷️ Title: Range / Text / Point / Composite index 🔗 URL: 📘 Overview An index is a copy of nodes, relationships, or properties that provides a fast access path to the primary data. Once created, the DBMS keeps it updated automatically. It speeds up the anchor (starting point) of a MATCH, and the Cypher planner selects it automatically based on the predicate. ⚙️ How It Works ・Range (default): solves the most predicates—equality, range comparisons, `IN`, and `STARTS WITH`. This is the first index to reach for. ・Text: `STRING`-only, optimized for `CONTAINS` and `ENDS WITH`—ideal for substring search screens. ・Point: for spatial `POINT` values, optimized for distance queries and bounding-box searches. ・Composite: indexes several properties together, solving multi-condition filters in one go. ・Token lookup: a foundational index that speeds up label / relationship-type lookups. ・Beyond these, full-text indexes and vector indexes (similarity search / GenAI) are also available. 🛠️ Practical Usage Creating range / composite / text / point indexes on anchor properties: ```cypher CREATE INDEX user_email IF NOT EXISTS FOR (u:User) ON ( CREATE INDEX order_composite IF NOT EXISTS FOR (o:Order) ON (o.customerId, o.status); CREATE TEXT INDEX product_name_text IF NOT EXISTS FOR (p:Product) ON ( CREATE POINT INDEX store_loc IF NOT EXISTS FOR (s:Store) ON (s.location); ``` Inspect and drop them: ```cypher SHOW INDEXES; DROP INDEX user_email IF EXISTS; ``` 💡 Use Cases ・Apps that anchor MATCH on ` `Order.orderId`, or `Product.sku`, making lookups O(log n). ・Search screens that pick range for `STARTS WITH`, text for `CONTAINS`/`ENDS WITH`, and point for geo queries. ⚠️ Caveats ・Which index applies depends on the predicate. `CONTAINS` is not served by a range index—it needs a text index. ・Indexes add write cost and storage. Confirm they are actually used with `PROFILE` before relying on them. ・Composite indexes apply from the leading property onward, so column order affects performance. #Neo4j# #Cypher#

# Neo4j Features and Practical Usage ♻️ "Create it if missing, update it if present." Idempotent writes that never produce duplicate nodes—no matter how many times you replay an event stream—come down to a single `MERGE`. 🏷️ Title: CREATE / MERGE / SET / DELETE 🔗 URL: 📘 Overview `MERGE` is an upsert clause: it matches and binds an existing pattern, or creates and binds it if absent. It fuses `MATCH` and `CREATE` so you can branch on whether the data existed beforehand. It is essential for making daily batches and stream ingestion idempotent. ⚙️ How It Works ・All-or-nothing: `MERGE` operates on the whole pattern—either everything matches or everything is created. It never partially reuses an existing pattern. To mix matching and creating, decompose into multiple `MERGE` clauses. ・`ON CREATE SET` / `ON MATCH SET`: property assignments that run only on create or only on match—handy for creation timestamps or access counters. Both can coexist. ・Merging relationships: at least one endpoint node must already be bound. An undirected `-[r:KNOWS]-` is tried both ways before creating left-to-right. ・Constraints: a uniqueness constraint gives `MERGE` conflict detection and prevents duplicates. For performance, creating an index on the label/property is strongly recommended (without it, every merge scans all nodes). 🛠️ Practical Usage Idempotent upsert over an event stream: ```cypher MERGE (u:User {id: row.userId}) MERGE (p:Page {url: row.url}) MERGE (u)-[v:VIEWED]->(p) ON CREATE SET v.count = 1 ON MATCH SET v.count = v.count + 1 ``` A standard pattern for creating derived nodes without duplicates: ```cypher MATCH (person:Person) MERGE (loc:Location {name: person.bornIn}) MERGE (person)-[r:BORN_IN]->(loc) ON CREATE SET r.createdAt = timestamp() ``` 💡 Use Cases ・Ingesting clickstream/IoT events, deduplicating the same user and page while accumulating counts. ・An ingestion layer where multiple pipelines write master data without ever doubling up entities. ⚠️ Caveats ・Always pair `MERGE` keys with a uniqueness constraint. Without one, concurrent runs can briefly create duplicates (constraints guarantee only eventual consistency). ・`MERGE` rejects `null` property values. Do conditional assignment with a later `SET`. ・You cannot cross-reference a node being created within the same `MERGE`. Match it first, or split into a `SET`. ・`DELETE` fails on a node that still has relationships; use `DETACH DELETE`. #Neo4j# #Cypher#

# Neo4j Features and Practical Usage 🕸️ "If this server goes down, what chain of things stops with it?" Cypher's variable-length patterns answer that by traversing relationships across any number of hops. 🏷️ Title: Variable-length patterns (`*1..5`) / SHORTEST / Quantified Path Patterns 🔗 URL: 📘 Overview Variable-length patterns let you express paths whose hop count is not fixed, all in a single declarative pattern. Questions like "trace suppliers up to 5 levels deep" or "find one shortest path" become natural one-liners. Shortest-path finding and Quantified Path Patterns (QPP) belong to the same family. ⚙️ How It Works ・Quantified relationships (legacy syntax): `[:REL*1..5]` matches 1 to 5 repetitions. `*2` is exactly 2, `*3..` is 3 or more, `*..10` is up to 10, `+` is one or more, and `*` is zero or more. ・Quantified Path Patterns (QPP): wrap a whole pattern in parentheses and quantify it, e.g. `((a)-[r:NEXT]->(b)){1,3}`. It is GQL-conformant and supports inline `WHERE` predicates inside the repetition. ・Group variables: variables declared inside a QPP become lists when referenced outside (e.g. `r` becomes an array of relationships). Combine with `reduce()` to compute, say, total distance along a path. ・Shortest paths: `SHORTEST k` returns k shortest paths, `ALL SHORTEST` returns every tied-shortest path, and `ANY` returns any one. The legacy `shortestPath()` / `allShortestPaths()` functions still work but the keyword syntax is faster. 🛠️ Practical Usage Trace a part's suppliers up to 5 levels deep: ```cypher MATCH (p:Part {sku: $sku})-[:SUPPLIED_BY*1..5]->(supplier:Company) RETURN DISTINCT ``` Find the single shortest introduction chain between two people: ```cypher MATCH path = SHORTEST 1 (a:Person {id:$a})-[:KNOWS]-+(b:Person {id:$b}) RETURN [n IN nodes(path) | AS intro_chain ``` 💡 Use Cases ・Impact analysis: how far a server failure cascades. ・Money-laundering detection: tracing fund-movement paths between accounts. ・Org charts and social graphs: boss-of-boss lookups, friend-of-friend shortest reach. ⚠️ Caveats ・Unbounded `*` or `[:REL*]` causes path explosion and can stall on millions of matches. Always set an upper bound such as `*1..5`. ・Pruning early with labels, relationship types, and inline predicates makes queries dramatically faster. QPP is built for this kind of pruning. ・By default Cypher does not allow re-traversing the same relationship; be aware that this behavior can be modified. #Neo4j# #Cypher#

# Neo4j Features and Practical Usage 🔍 A query that becomes a five-way JOIN in SQL can be written in a single line of arrow-drawing — Cypher is the declarative query language for graphs. 🏷️ Title: Cypher (Declarative Graph Query Language) 🔗 URL: 📘 Overview Cypher is a declarative graph query language designed for Neo4j. Instead of specifying "how to retrieve," you express "what data you want" using ASCII-art-like patterns. It is the common language of graphs, shared across application, analytics, and operations. ⚙️ How It Works The core of Cypher is pattern matching. ・Nodes are written in parentheses `(node)` ・Relationships use square brackets and arrows `-[rel]->`, with direction shown by the arrow ・Labels, types, and properties can be written directly inside the pattern (`(:User {id: $id})`) The main clauses are: ・`MATCH`: search for patterns within the graph ・`RETURN`: project the results to return ・`WHERE`: filter with conditions ・`CREATE` / `MERGE`: create / create-if-not-exists-else-match ・`WITH`: compose multi-step pipelines Cypher aligns with GQL (the ISO graph query language standard) while keeping Neo4j extensions. As of Neo4j 2025.06, new features are added exclusively to Cypher 25, while Cypher 5 is frozen. 🛠️ Practical Usage A query that becomes multiple JOINs in SQL can be written as a single pattern. ```cypher MATCH (c:Customer {id: $id})-[:ORDERED]->(o:Order)-[:CONTAINS]->(p:Product) RETURN count(*) AS times ORDER BY times DESC ``` Always use parameters (`$id`) in queries. This helps with both injection prevention and execution-plan caching. 💡 Use Cases It is the foundation for any domain that asks questions about connections: aggregating customer purchase history, recommendations, tracing paths in fraud detection, and walking org charts. It is highly readable and expresses complex traversals in fewer lines than SQL. ⚠️ Caveats ・Do not build queries by string concatenation; always parameterize. ・Watch for version differences. New features center on Cypher 25, and Cypher 5 is frozen. Verify compatibility. ・Because it is declarative, how you write a query can change the execution plan significantly. Check heavy queries with PROFILE/EXPLAIN. #Neo4j# #Cypher#

# Neo4j Features and Practical Usage 🎨 The picture of your business that you draw on a whiteboard becomes almost directly the database schema — that is the joy of graph modeling. 🏷️ Title: Graph Modeling Methodology (Whiteboard Model to Physical Model) 🔗 URL: 📘 Overview Graph data modeling is the practice of mapping the "picture" of your business domain step by step into a physical graph model. Neo4j's official guide systematically presents the flow of conceptual model to implementation to refactoring, migration from a relational model, and design options that improve performance. It answers the questions that come up in every design review. ⚙️ How It Works Modeling generally proceeds through these stages: ・Conceptual design: enumerate the entities in the domain and decide the nodes and the relationships (verbs) that connect them ・Implementation: map the whiteboard picture directly onto nodes, labels, types, and properties ・Refactoring: iteratively improve the model to fit your query patterns The biggest decision point is whether to "reify an event as an intermediate node" or use a "direct edge." ・Direct edge (`(:User)-[:ORDERED]->(:Product)`): when the relationship is simple with few attributes ・Intermediate node (`(:User)-[:PLACED]->(:Order)-[:CONTAINS]->(:Product)`): when a single event involves multiple participants, line items, states, or timestamps For naming, use "label = singular noun" and "relationship type = upper snake-case verb" as the baseline. 🛠️ Practical Usage If an order needs quantity, price, and status, reify it as an intermediate node rather than a relationship. ```cypher CREATE (u:User {id: 'u1'})-[:PLACED]->(o:Order {id: 'o1', status: 'shipped', at: datetime()}) CREATE (o)-[li:CONTAINS {qty: 2, price: 9.99}]->(p:Product {sku: 'sku1'}) ``` In fraud detection, turn account, device, phone, and address into nodes and connect shared relationships as edges. ```cypher MATCH (a1:Account)-[:USED]->(d:Device)<-[:USED]-(a2:Account) WHERE a1 <> a2 RETURN a1, a2, d ``` 💡 Use Cases This connects directly to "the business picture is the schema" design: discovering fraud rings via shared devices and addresses, or reifying orders into intermediate nodes in e-commerce to track line items, shipping, and returns. ⚠️ Caveats ・Both "everything as intermediate nodes" and "everything as direct edges" are extremes. Decide by working backward from your query patterns (how you will traverse). ・Refactoring large datasets later is expensive. Anticipate your main queries first and firm up the model. ・Carrying over relational normalization habits and creating too many table-like nodes makes traversals verbose. #Neo4j# #DataModeling#

📄 Upload your documents, get a knowledge graph — Neo4j's new "Document Intelligence" feature in Aura makes it that simple! Title: Introducing Document Intelligence: From documents to a knowledge graph, right inside Aura URL: 📦 Overview Neo4j has added "Document Intelligence" to its fully managed graph database service Aura. Upload unstructured documents like PDFs, contracts, or technical docs, and the platform automatically extracts entities, resolves duplicates, and constructs a knowledge graph — all without writing a single line of code. ❓ Challenges Solved Most enterprise data is trapped in unstructured documents. Building knowledge graphs from this data previously required complex NLP pipelines, LLM-based entity extraction, entity resolution, and graph schema design — limiting knowledge graph adoption to specialized technical teams. 💡 Methodology & Proposed Approach The feature uses LLM-based entity extraction to identify people, organizations, concepts, and their relationships. Entity resolution merges duplicate references across documents into unified graph nodes. The system infers graph schemas from extracted relationships and stores everything in AuraDB, ready for immediate use with Aura Agent, GenAI Copilot, and GraphRAG pipelines. 🛠 Use Cases - Legal teams automating compliance checks by extracting obligation networks from contract collections - Pharmaceutical companies structuring molecule-disease relationships from clinical trial reports - Enhancing RAG accuracy by supplementing vector search with structural relationships that graphs uniquely capture #KnowledgeGraph# #Neo4j#

For an AI agent to answer "why did we make that decision?", you need connected memory — not flat chat logs 🕸️ This tool spins the whole thing up in one command. Title: Introducing Create Context Graph URL: 🕸️ Overview Create Context Graph is a Neo4j Labs CLI scaffolding tool that generates a full-stack AI agent app with graph-based memory in a single command. The generated app bundles a FastAPI backend, a Next.js frontend, an AI agent framework, and a Neo4j graph database. ❓ Challenges Solved AI agents are easy to build but still struggle with relationships and causality. ・Flat chat logs and vector stores can't answer structural questions like "why did we decide this?" or "what's blocking this work?" ・In short, agents lacked the sophisticated memory needed to capture relational context 💡 Methodology & How It Works ・It turns data into a "context graph" (a connected knowledge structure), organizing three memory types: chat history, vector content, and reasoning traces ・It uses the POLE+O entity model (Person, Organization, Location, Event, Object) layered with domain-specific types ・When agents decide, the reasoning chain is captured as DecisionTrace nodes with linked TraceStep components, creating queryable provenance ・It supports multiple frameworks (PydanticAI, LangGraph, Claude Agent SDK), 22 built-in domains, Linear/Claude Code/GitHub connectors, real-time reasoning-path visualization, and automatic secret redaction 🌍 Use Cases ・Developers querying issue dependencies and team workflows ・Personal development analytics from Claude Code session history ・Multi-tool correlation combining decisions, commits, and work items Making decision provenance queryable helps with agent explainability, debugging, and cross-team knowledge integration. #GraphRAG# #Neo4j#

"Who's the strongest wrestler?" can't be answered by win counts alone. Chaining graph algorithms to surface true dominance is a fun read 🥋 Title: SumoDB in Neo4j: Chaining Multiple Graph Algorithms in Snowflake — Part 3 URL: 🥋 Overview This post combines Neo4j Graph Analytics with Snowflake SQL to measure "dominance you can't see from win counts" in professional sumo data. It chains multiple graph algorithms into a composite "Chaos Score." ❓ Challenges Solved Ranking by raw wins overrates wrestlers who just beat weak opponents. By pairing Neo4j and Snowflake, the post surfaces competitive structure that neither tool alone could reveal. 💡 Methodology & Proposed Approach It builds weighted directed "winner → loser" edges and chains three algorithms. ・PageRank: weights wins over stronger opponents higher, measuring victory quality ・Betweenness centrality: finds bridge wrestlers connecting elite and mid-tier ・3-cycle detection: visualizes rock-paper-scissors (non-transitive) rivalries A damping factor of 0.85 and reversed edge orientation direct prestige toward winners, converging in ~20 iterations. 🌍 Use Cases ・Talent assessment: separate inflated win records from genuine dominance ・Structural analysis: find key wrestlers whose removal fragments the hierarchy ・Competitive balance: gauge ecosystem health via non-transitive rivalry density #GraphDataScience# #Neo4j#