Turning unstructured data into a graph database is a deceptively complex problem. You need to extract entities, understand relationships, define schemas, and maintain data quality whilst managing costs and supporting new data sources. The challenge isn’t choosing whether to use a graph database; it’s choosing how to populate it.
This guide walks through seven different approaches to ingesting data into graph databases, covering the architecture, tradeoffs, and when each makes sense. Whether you’re processing SharePoint documents, streaming structured data, or building a knowledge graph from PDFs, there’s an option that fits your constraints.
1. Neo4j LLM Graph Builder: The No-Code Approach
Best for: Document-to-graph pipelines, quick prototyping, non-technical users, SharePoint/PDF ingestion.
Neo4j’s LLM Graph Builder is a managed platform that turns documents into knowledge graphs without writing code. You upload PDFs, Word documents, web pages, or YouTube transcripts; define a schema in the UI; and the LLM extracts entities and relationships matching that schema. Results flow directly into Neo4j.
How it works:
The tool uses LangChain under the hood and supports multiple LLM providers (OpenAI, Claude, Gemini, Llama, Qwen). You define node types and relationship labels in a browser-based configuration. The LLM extracts entities and creates structured JSON output that maps to your graph schema. You can then refine the graph with de-duplication, orphan node removal, and custom cleanup jobs.
Ingest method: Schema-driven JSON extraction. Not Pydantic, but functionally similar—you specify allowed node and relationship types, and the LLM respects them.
LLM usage: Required. The LLM is the extraction engine. You choose which provider and model to use. Supports any OpenAI-compatible API endpoint.
Orchestration: None. The UI guides you through upload → schema definition → extraction → refinement → results in Neo4j. No pipeline orchestration required but if hardening the service consider using an Orchestrator for any pre-extraction and automation processes. See next option.
Supporting new datasets: High flexibility. Change the schema definition and re-run extraction. The LLM adapts to new document types without code changes.
Tradeoffs:
- Limited programmatic control. You’re constrained by the UI and LLM extraction capabilities.
- Schema must be extractable by the LLM. Complex ontologies or domain-specific schemas may confuse the model. This is very important when dealing with competing ontologies in healthcare.
- No cost pre-estimation. You pay for tokens after extraction; budgeting is reactive, not predictive.
- Extraction quality depends on the LLM’s understanding of your domain. Ambiguous schemas lead to poor results.
- If your data includes images or complex layouts, results vary by provider.
Tools: Neo4j LLM Graph Builder, LangChain, Docker (for local deployment), your LLM provider’s API.
When to use it: You have mostly documents (PDFs, web pages, images) and want results fast without development overhead. Ideal for knowledge discovery projects, proof-of-concepts, and teams without dedicated data engineers.
2. LangChain + LangGraph + Neo4j: The Full-Control Approach
Best for: Production pipelines, complex transformations, reusable workflows, multi-source integration.
If you need programmatic control over extraction, validation, and graph construction, this is the production-grade stack. LangChain provides LLM integration and entity extraction; LangGraph adds stateful orchestration; and you manage the entire workflow in Python.
How it works:
Define your graph schema using Pydantic models. These become your contract—specify node types, properties, and validation rules. LangChain’s LLMGraphTransformer extracts entities and relationships using the LLM, constrained by your schema. LangGraph orchestrates the workflow: load document → extract entities → validate with Pydantic → deduplicate → store in Neo4j.
LangGraph tracks state across the pipeline, supports conditional branching (retry on extraction failure), and provides checkpointing—if a batch of 10,000 documents fails at document 7,500, you resume from there instead of restarting.
Ingest method: Pydantic models. You define TypedDict or BaseModel classes specifying node properties, validation rules, and constraints. The LLM extracts data matching this schema.
LLM usage: Optional but recommended. You control when and how the LLM is used. Can be extraction-only, quality-checking, or intent classification. Multiple LLM calls per document are fine.
Orchestration: Required. Dagster, Airflow, or a custom LangGraph workflow. This is an investment but buys flexibility and production reliability.
Supporting new datasets: Very high. Code-based means you control everything. New data source? Add a loader. New validation? Update Pydantic model. New extraction logic? Change the LLM prompt.
Tradeoffs:
- Development overhead. You’re building infrastructure, not using a product.
- Orchestration complexity. Dagster and Airflow have learning curves.
- Error handling is your responsibility. Edge cases and data quality issues require custom logic.
- Cost tracking isn’t automatic. You need to instrument your code or use Langfuse to monitor token usage.
- Maintenance burden scales with pipeline complexity. More nodes means more moving parts.
Tools: LangChain, LangGraph, Pydantic, Dagster or Airflow, Neo4j Python driver, optional: Langfuse for cost tracking.
When to use it: You have multiple data sources, complex transformations, and a team comfortable with Python. This is the “we’ll build it ourselves” approach. Choose it when the generic tools don’t fit your requirements.
3. Databricks Lakeflow + Neo4j: The Data Warehouse Approach
Best for: Enterprise data warehouses, structured data, existing Databricks deployments, cost tracking built-in.
If your organization already runs Databricks then Lakeflow is a natural extension. It provides SQL-based orchestration with a bronze/silver/gold data lakehouse pattern: raw ingestion → enrichment → refined output.
How it works:
Data lands in Delta Lake as bronze tables (raw). Lakeflow Spark Declarative Pipelines define transformations as SQL or PySpark code, moving data through silver (cleaned) to gold (refined) layers. You can invoke LLMs via UDFs or API calls within PySpark, then export the result to Neo4j. Databricks Delta Live Tables handle scheduling, retries, and monitoring.
Ingest method: SQL and Spark. Data types are schema-defined, validated by Delta Lake. Less flexible than Pydantic but more structured. You’re working with tables and columns, not Python objects.
LLM usage: Optional. LLMs can be called via UDFs or external API calls within transformations, but they’re not the primary extraction mechanism. Better for enrichment than extraction.
Orchestration: Built-in. Delta Live Tables manages scheduling, retries, and dependency tracking. No separate orchestrator needed.
Supporting new datasets: Medium flexibility. Adding a new data source means adding a new bronze table and pipeline. The schema-first approach is less flexible than code-first, but more robust for structured data.
Tradeoffs:
- Requires Databricks. Not an option if you’re on a budget or prefer open-source tools.
- Bronze/silver/gold pattern assumes structured data. Unstructured text (documents, images) requires preprocessing.
- LLM integration is an afterthought, not native. More complex than LangChain’s built-in LLM support.
- Cost is per compute cluster. Large-scale document processing can be expensive.
- Vendor lock-in. Lakeflow only works with Databricks.
Tools: Databricks, Delta Lake, Apache Spark, Neo4j connector, Langfuse (optional).
When to use it: Your organization runs Databricks for data warehousing and wants to extend it to graph analytics. Great for enterprises with structured data and existing infrastructure investments.
4. Manual Python + Pandas + Neo4j: The DIY Approach
Best for: One-off scripts, small datasets, prototyping, teams comfortable with raw code.
Sometimes the simplest approach is the best. Write Python, use Pandas to wrangle data, and write directly to Neo4j. No abstractions, no frameworks, no management layer. You”re the engineer.
How it works:
Load data with Pandas. Transform using standard Python and Pandas operations. Build nodes and relationships as dictionaries or DataFrames. Use the Neo4j Python driver to execute Cypher queries and insert the graph. Write custom exception handling and implement your own retry mechanism.
Ingest method: Custom Python. No schema enforcement unless you add it. Fast iteration, minimal overhead.
LLM usage: No (unless you manually add API calls). Best for structured data that doesn’t require understanding intent or fuzzy matching.
Orchestration: Required but DIY. Cron jobs, shell scripts, or manual execution. No built-in monitoring or alerting.
Supporting new datasets: Very high, because there’s nothing stopping you. Also very low, because maintaining multiple scripts is painful. Flexibility without reusability.
Tradeoffs:
- Maximum control, minimum abstraction. You handle every edge case.
- No error recovery. If the script fails at row 500 of 1,000, you restart from the beginning or manually resume.
- No monitoring or cost tracking without custom instrumentation.
- Maintenance headache. Python scripts are easy to write, hard to maintain.
- Not production-ready. Works great for analytics, research, and one-offs; scales poorly for enterprise.
Tools: Python, Pandas, Neo4j Python driver, requests (if calling APIs).
When to use it: You have a small, one-time job. You’re testing a hypothesis. You want to avoid the overhead of infrastructure. Acceptable for data scientists and researchers; not for production data pipelines.
5. AI Orchestrator + Neo4j LLM Graph Builder: Use Your AI as Super Orchestrator
Best for: Interactive configuration, cost-aware ingestion, dynamic schema definition, enterprise automation.
This approach layers a Claude agent on top of Neo4j LLM Graph Builder. The agent acts as a “meta orchestrator”. It guides you through defining documents of interest, Pydantic validation terms, Neo4j schema, and cost estimates. Then it invokes the Graph Builder with the optimized configuration.
How it works:
The Claude agent asks clarifying questions: “What documents are you ingesting? What entities matter? What relationships exist?” You respond conversationally. The agent generates a Pydantic schema and Neo4j graph schema, then calculates token cost estimates before execution. Once you approve, it invokes Neo4j LLM Graph Builder with the configuration, monitors extraction, suggests additional nodes based on extraction results, and surfaces any anomalies.
The Graph Builder UI accepts a graph schema, not Python classes. It is configured with node labels, relationship types, source–relationship–target patterns, an existing Neo4j schema, Data Importer JSON, or schema text that the application converts into its internal format. It does not provide an API. The Neo4j GraphRAG Python package is a Python library for building your own ingestion pipeline. Its schema classes are Pydantic-based internally, and its LLM interfaces support structured output using a Pydantic model or JSON Schema. This provides actual Python-level Pydantic integration.
Ingest method: Hybrid. The agent builds Pydantic definitions, with schema evolution and passes them to the Graph Builder as schema constraints. You get Pydantic-like validation without writing code.
LLM usage: Yes, explicitly. Claude as the orchestrator + LLM Graph Builder’s LLMs as extractors. You might use multiple LLMs in sequence (Claude for configuration, OpenAI for extraction).
Orchestration: Hybrid. Claude orchestrates the meta-process (configuration, approval, execution), and the Graph Builder handles the actual extraction.
Supporting new datasets: Very high. The agent adapts the schema and configuration interactively. New document type? The agent suggests schema updates without code changes.
Tradeoffs:
- Meta-layer adds complexity. You’re orchestrating an orchestrator.
- Cost prediction requires token counting logic. Must implement or estimate token usage per model.
- Requires custom integration. No out-of-the-box product exists; you’re building this yourself.
- More expensive per-run because of Claude’s involvement (though amortized if running once then reusing schema).
- Requires human interaction. Not suitable for fully automated, unattended pipelines.
Tools: Claude API, Neo4j LLM Graph Builder, Langfuse (for cost tracking), Pydantic, Python.
When to use it: You need interactive, cost-aware configuration. Your team wants guidance on schema design. You’re building an internal platform for business users to define graph ingestion jobs. Best for enterprises automating knowledge graph creation.
Best for: Interactive configuration, cost-aware ingestion, dynamic schema definition, enterprise automation.
This approach layers a Claude agent on top of Neo4j LLM Graph Builder. The agent acts as a “meta orchestrator”. It guides you through defining documents of interest, Pydantic validation terms, Neo4j schema, and cost estimates. Then it invokes the Graph Builder with the optimized configuration.
How it works:
The Claude agent asks clarifying questions: “What documents are you ingesting? What entities matter? What relationships exist?” You respond conversationally. The agent generates a Pydantic schema and Neo4j graph schema, then calculates token cost estimates before execution. Once you approve, it invokes Neo4j LLM Graph Builder with the configuration, monitors extraction, suggests additional nodes based on extraction results, and surfaces any anomalies.
Ingest method: Hybrid. The agent builds Pydantic definitions and passes them to the Graph Builder as schema constraints. You get Pydantic-like validation without writing code.
LLM usage: Yes, explicitly. Claude as the orchestrator + LLM Graph Builder’s LLMs as extractors. You might use multiple LLMs in sequence (Claude for configuration, OpenAI for extraction).
Orchestration: Hybrid. Claude orchestrates the meta-process (configuration, approval, execution), and the Graph Builder handles the actual extraction.
Supporting new datasets: Very high. The agent adapts the schema and configuration interactively. New document type? The agent suggests schema updates without code changes.
Tradeoffs:
- Meta-layer adds complexity. You’re orchestrating an orchestrator.
- Cost prediction requires token counting logic. Must implement or estimate token usage per model.
- Requires custom integration. No out-of-the-box product exists; you’re building this yourself.
- More expensive per-run because of Claude’s involvement (though amortized if running once then reusing schema).
- Requires human interaction. Not suitable for fully automated, unattended pipelines.
Tools: Orchestrating AI, Neo4j LLM Graph Builder, Langfuse (for cost tracking), Pydantic, Python.
When to use it: You need interactive, cost-aware configuration. Your team wants guidance on schema design. You’re building an internal platform for business users to define graph ingestion jobs. Best for enterprises automating knowledge graph creation.
6. Graphwise for M365/SharePoint: The Enterprise Platform
Best for: Enterprise SharePoint/M365 environments, knowledge discovery, org-wide search.
If your data lives in Microsoft 365 (SharePoint, Teams, OneDrive), Graphwise is a managed platform that builds knowledge graphs from that data natively.
How it works:
Graphwise connects to Microsoft Graph Data Connect, indexes SharePoint documents and metadata, runs graph algorithms to identify relationships, and exposes results through conversational search. The entire workflow is managed—no infrastructure, no configuration, just results.
Ingest method: Native M365 connectors. Data is indexed as-is; no custom schema needed.
LLM usage: Built-in via Microsoft Graph AI. You can’t choose the LLM.
Orchestration: None. Managed service handles indexing and updates automatically.
Supporting new datasets: Low. Limited to M365 data sources. Can’t extend to external documents, databases, or APIs easily.
Tradeoffs:
- Enterprise-locked. Only works with M365. If your data is elsewhere, this isn’t an option.
- Limited customization. You get what Microsoft built; changing schema or extraction logic isn’t straightforward.
- M365 data only. External data sources require custom connectors.
- Indexing latency. Updates may lag behind source data changes.
- Cost opacity. Pricing is bundled into M365 licensing; budgeting is opaque.
Tools: Graphwise, Microsoft Graph Data Connect, Azure AI.
When to use it: Your organization is M365-first and wants to enable org-wide knowledge search. Useful for enterprise search, compliance, and knowledge discovery. Not for heterogeneous data sources.
7. LlamaIndex + Neo4j: The Retrieval-Focused Approach
Best for: RAG systems, document indexing, hybrid search (vector + graph), retrieval-focused applications.
LlamaIndex’s Property Graph Index is designed for retrieval-augmented generation. It extracts entities and relationships from documents, builds a property graph, and supports vector search over entities. Property Graph Index is a programmable knowledge graph construction framework and unlike Neo4j LLM Graph Builder, it is a library and not an application. This means that all of the processes of LLM Graph Builder can be replaced by interchangeable components rather than a fixed pipeline, thus giving fine grained control.
How it works:
LlamaIndex ingests documents, chunks them, extracts entities and relationships using LLMs, and stores them in a property graph alongside embeddings. The graph is optimized for retrieval: given a query, find relevant entities, traverse relationships, and augment the LLM’s context.
Ingest method: LlamaIndex’s Property Graph Index (Pydantic-adjacent). Define entity types and relationships; LlamaIndex extracts and links to source documents.
LLM usage: Optional but recommended. LLMs extract entities and generate embeddings; you control which LLM and when it’s invoked.
Orchestration: Required. LlamaIndex handles indexing, but you need an orchestrator (Dagster, Airflow) for scheduling and monitoring.
Supporting new datasets: High. Flexible property graph model adapts to new document types. Code-based configuration.
Tradeoffs:
- Focused on retrieval, not construction. The graph is a byproduct of indexing, not the primary output.
- Requires separate orchestration layer.
- Less mature than Neo4j’s native tools for graph construction.
- Best for read-heavy workloads (queries), not write-heavy (ingestion).
- Vector search overhead. Embeddings add cost and latency.
Tools: LlamaIndex, Neo4j, Pydantic, embedding model provider (OpenAI, Anthropic, etc.), Dagster (optional).
When to use it: You’re building a RAG system and want entity-level retrieval. The graph is a means to better search results, not the end goal. Ideal for document-heavy applications where relevance ranking matters.
Decision Matrix: Choosing Your Approach
Here’s how to pick the right tool:
Use Neo4j LLM Graph Builder if:
- You want results fast with minimal code.
- Your data is mostly documents (PDFs, web pages, images).
- You’re okay with UI-driven workflows.
- Cost prediction isn’t critical.
Use LangChain + LangGraph if:
- You have complex transformation requirements.
- You need Pydantic validation and custom logic.
- Your team can build and maintain Python infrastructure.
- Reusability across multiple projects matters.
Use Databricks Lakeflow if:
- Your organization already runs Databricks.
- Your data is structured (tables, not documents).
- You want built-in orchestration and cost tracking.
- You’re comfortable with SQL-first thinking.
Use Manual Python if:
- This is a one-time job or small experiment.
- Your dataset is small enough to fit in memory.
- You value simplicity over reusability.
- You’re willing to accept maintenance debt.
Use Claude Agent + Graph Builder if:
- You need interactive schema configuration.
- Cost prediction before execution is critical.
- You’re building a platform for non-technical users.
- Your team has the engineering capacity to build it.
Use Graphwise if:
- Your organization is M365-first.
- You need org-wide knowledge discovery.
- You want a fully managed solution.
- Your data lives exclusively in SharePoint/Teams.
Use LlamaIndex if:
- You’re building a RAG system.
- Vector search + graph traversal is your retrieval strategy.
- Your workflow is read-heavy (query-focused).
- You want hybrid search capabilities.
The Hybrid Future
In practice, teams often combine approaches. A common pattern:
- Use Neo4j LLM Graph Builder to ingest documents and explore the resulting graph.
- Graduate to LangChain + LangGraph once you understand the schema and want production reliability.
- Add Langfuse for cost tracking and monitoring.
- Layer a Claude Agent on top for interactive configuration.
This progression lets you start simple and add complexity only when needed.
The key insight: there’s no universal “best” approach. The right choice depends on your data, your team’s expertise, your budget constraints, and whether you’re optimizing for speed, control, or cost-efficiency. Choose based on what matters most to your project, and don’t be afraid to evolve as requirements change.
Appendix: Quick Reference
| Approach | LLM | Orchestration | Pydantic | Best For |
|---|---|---|---|---|
| Neo4j LLM Builder | Required | None | Schema-driven | Fast docs-to-graph |
| LangChain + LangGraph | Optional | Required | Native | Production pipelines |
| Databricks Lakeflow | Optional | Built-in | N/A (SQL) | Data warehouse extension |
| Manual Python | No | DIY | No | One-offs, small data |
| Claude Agent + Builder | Yes | Hybrid | Generated | Interactive config |
| Graphwise | Built-in | None | N/A | M365-only enterprises |
| LlamaIndex | Optional | Required | Optional | RAG + retrieval |
