AutoData by Kiwi AI

Graph-augmented retrieval-augmented generation — GraphRAG — is rapidly becoming the defining architecture for enterprise AI that must reason over connected knowledge. Where standard vector retrieval returns isolated text snippets, GraphRAG adds relational context: who is connected to what, what depends on what, what concepts co-occur across documents and systems. The improvement in answer quality for relationship-heavy enterprise queries is substantial, and adoption is accelerating.

Yet the market remains structurally incomplete. Most vendors are strong in one layer — graph traversal, vector retrieval, ontology, governance, orchestration, or cloud infrastructure — but few productize the operational middle layer that makes GraphRAG work in practice.

"AutoData is the only developer-accessible GraphRAG platform in the reviewed set that productizes the entire ingestion-to-graph pipeline — covering multimedia, all major document formats, and structured data, with production safety hardening, per-file job tracking, and application-layer RBAC that competitors leave to the buyer to build.

GraphRAG Is Not a Product — It Is a Stack

Enterprise buyers who want GraphRAG quickly discover that they are not buying a single product. They are assembling at minimum seven distinct layers:

Each layer has its own failure modes, size limits, format gaps, and operational requirements. Most vendors productize one or two layers well. The rest is left to the buyer's engineering team. That assembly cost — in engineering time, operational risk, and ongoing maintenance — is often the hidden budget line item that derails enterprise GraphRAG programs.

Market Structure

The competitive landscape fragments into four camps, none of which delivers a complete end-to-end solution.

Product Definition

AutoData is an end-to-end GraphRAG ingestion and retrieval infrastructure platform. In a single operational system, it provides:

• Broad enterprise file ingestion across documents, spreadsheets, JSON, code and configuration files, and multimedia
• Dual-store indexing into Weaviate for vector retrieval and Neo4j for graph traversal
• Multimedia ingestion with adaptive vectorization or Gemini-powered transcription and summarization
• A dedicated spreadsheet ingestion engine with structural awareness and safety controls
• An application-layer knowledge base model with role-based access control and multi-KB fan-out search
• An asynchronous job system with per-file status tracking and readiness probes
• Production safety hardening including ZIP-bomb detection, prompt-injection scrubbing, and container-aware memory scaling

The Positioning

AutoData is not a graph database, a vector database, a semantic web platform, or a generic RAG framework. It is the operational layer that makes enterprise GraphRAG deployable over real enterprise content.

What AutoData Ingests

AutoData routes files through purpose-built handlers across more than thirty file extensions in six categories.

Format Coverage Across Competitors

Sources: ¹ microsoft.github.io/graphrag/index/inputs/ and GitHub Discussion #375 · ¹ᵃ MS GraphRAG outputs pipeline results as Parquet files but does not ingest Parquet as input · ² docs.aws.amazon.com/bedrock (JPEG/PNG supported for multimodal S3 sources at a separate 3.75 MB limit) · ³ docs.unstructured.io · ⁴ graphacademy.neo4j.com · ⁵ docs.vectara.com · ⁶ github.com/Unstructured-IO/unstructured/issues/4047 — XLSM confirmed "not recognized" · ⁷ developers.llamaindex.ai/python/cloud/general/supported_document_types/ · ⁷ᵃ LlamaParse lists XLSM/XLSB as "Also supported" on its canonical types page; it is a paid cloud API ($0.003/page) with no published ZIP-bomb, cgroup, or POSIX lock documentation — raises data sovereignty concerns for enterprise financial workbooks · ⁸ docs.glean.com/connectors/crawler-and-indexing-limits (size-limits page only; no supported-format matrix found in reviewed documentation)

File Size Handling

AutoData enforces explicit size controls at multiple ingestion points. Remote document downloads are capped at 200 MB. Media files are capped at 200 MB during streaming download.

Enterprise knowledge increasingly lives in non-text formats: recorded meetings, training videos, customer call recordings, product demonstrations, embedded charts, and scanned documents with annotations. Most GraphRAG platforms treat these as out of scope. AutoData treats them as first-class ingestion targets.

The Multimedia Pipeline

Spreadsheets are among the most common enterprise knowledge sources — used by finance, operations, procurement, and back-office functions to store critical business knowledge. They are also structurally complex: merged headers, multiple tables per sheet, wide columns, macro-enabled and binary formats. AutoData uses a dedicated spreadsheet engine.

Format Coverage and Safety Bounds

AutoData's differentiation on spreadsheets is not simply which format names are listed — it is what happens inside: documented safety bounds enforced before any decompression, graph output at zero LLM cost, and no dependency on a third-party cloud parsing API.

Header Detection, Cell Propagation, and Table Segmentation

• Identifies header rows using a density + string/numeric ratio heuristic; detects up to 3 stacked header rows and flattens them into compound labels like Revenue / Q1 / Actual
• Propagates merged cell anchor values to every dependent row — no silent blank cells in any returned chunk
• Detects multiple independent tables within a single sheet and segments them independently, preventing cross-table entity contamination in the knowledge graph
• Captures side annotations, footnotes, and sidebar data as separate notes chunks — no content is silently dropped
• Enforces an 80× ZIP expansion ratio cap, a 50,000 ZIP member cap, and a specific guard on xl/sharedStrings.xml — the single most common cause of openpyxl memory exhaustion on large workbooks

Five Chunk Types Per Workbook

Safety Controls

• ZIP container inspected before any decompression: 80× expansion ratio cap, 50,000 ZIP member cap, specific guard on xl/sharedStrings.xml
• Cross-process POSIX lock serializes heavy spreadsheet operations across worker processes — prevents memory spikes in multi-worker deployments
• Container memory limits read from Linux cgroup filesystem at runtime (v1 and v2) — processing caps self-adjust to available RAM in ECS Fargate and Kubernetes environments
• None of these controls are documented for any competitor in the reviewed set

Deterministic Graph at Zero LLM Cost

AutoData's KB Architecture

RBAC Comparison

Dual-Store Architecture with Graceful Degradation

AutoData loads every ingested document into both Weaviate for vector retrieval and Neo4j for graph traversal. Backend availability is tracked independently per job. If vector indexing succeeds but graph extraction fails, the job is marked PARTIAL_AVAILABLE and vector retrieval continues to work — materially better than treating any backend failure as a complete job failure.

Three-Context Answer Synthesis

LLM Provider Flexibility

AutoData supports Azure OpenAI, standard OpenAI, Anthropic Claude, Google Gemini, Perplexity, DeepSeek, and Grok — switchable via a single configuration string, with new models continuously added as the ecosystem evolves. AWS Bedrock locks graph extraction to Claude 3 Haiku with no override supported per official documentation.

GraphRAG Capability Comparison

Open-source GraphRAG frameworks assume controlled environments with trusted inputs. Enterprise production deployments encounter adversarial inputs, resource-constrained containers, and concurrent workers. AutoData addresses each attack surface as a built-in platform capability.

AutoData's Production Job System

Beyond the primary ingestion pipeline, AutoData includes a real-time indexer that continuously monitors MongoDB collections for new and updated documents, indexing them into Weaviate and Neo4j without requiring explicit upload actions.

AutoData's advantages over each competitor are focused on the ingestion, transformation, and governance layers that competitors leave incomplete or unbuilt.

Sources grouped by vendor and topic. Each chip is a direct link to the primary document. Where a capability is described as "not documented in reviewed materials," this reflects absence of documentation rather than a confirmed absence of the capability.