The round and what it validates
PuppyGraph announced on November 10 a 10 million dollar Series A led by Particle Future and defy.vc, bringing the company's total funding to 15 million dollars. The round follows the general availability release of PuppyGraph 1.0 and will fund engineering and enterprise go to market expansion. The company describes itself as a graph query engine built for enterprise AI agents, one that lets those agents query enterprise data as a single federated graph without loading that data into a separate, dedicated graph database first. PuppyGraph says annual recurring revenue grew sevenfold over the past year, a growth rate that suggests the product is landing with buyers who already have budget allocated for agent infrastructure.
The customer list backing that growth includes AMD, Palo Alto Networks, Datadog, Netskope, Coinbase, Trend Micro, Baker Hughes, and several smaller security and insurance firms. Amy Yin, a partner at defy.vc, framed the investment thesis bluntly: big data remains an unsolved problem in the world of AI. That framing is worth taking seriously from a firm willing to write a check into infrastructure rather than another model wrapper, since it suggests investors see the data access layer, not the model layer, as the current constraint on agent capability at enterprise scale.
Why graph queries matter for agents specifically
Graph queries matter for AI agents in a specific way that most dashboards and chat interfaces do not need: multi hop reasoning across relationships that were never designed to be queried together. An agent investigating a security incident might need to trace a user, through a device, through a network session, through a set of file access events, a chain that spans multiple tables and systems in a typical enterprise data estate. Traditional SQL joins handle one or two hops reasonably well, but performance degrades quickly as the number of hops grows, which is exactly the pattern agentic investigation and reasoning tasks tend to produce.
PuppyGraph's customers describe this problem in almost identical language across very different industries. Leon Goldberg, chief technology officer at Sola Security, said his team runs AI agents across thousands of tables and billions of edges a day, a scale that would be difficult to sustain if every query required a human to write and tune custom SQL joins ahead of time. Ran Xia, director of engineering at Palo Alto Networks, credited the platform with letting the company execute multi hop graph traversals directly on its existing data platform rather than standing up new infrastructure to support agent investigations.
The zero copy argument
The core architectural claim is zero copy: PuppyGraph presents existing tables, in sources including Apache Iceberg, Databricks, Snowflake, ClickHouse, DuckDB, and PostgreSQL, as a graph without extracting, transforming, and loading that data into a dedicated graph database like Neo4j. Xinyu Liu, a staff software engineer at Coinbase, summarized the appeal in three short phrases: no pipelines, no second copy of the data, and no data movement. For any CTO who has run a graph database migration project, that framing lands differently than a feature comparison, since ETL pipelines into a graph store are exactly where those projects tend to stall or blow their budgets.
Patrick Lu, lead architect for data and AI at Trend Micro, said PuppyGraph was the only solution his team found that supports Iceberg natively at the scale they needed, which points to a gap in the market rather than a simple feature preference. The performance claim behind this architecture is a 10 hop query across billions of edges completing in 2.26 seconds on a four machine cluster, alongside claims of petabyte scale operation with subsecond graph queries. Those numbers deserve the same scrutiny any vendor benchmark deserves, but the underlying architecture, querying in place rather than copying, is sound regardless of the exact latency figures.
Who is actually using this and why
PuppyGraph 1.0 adds an AI assisted schema builder that generates a candidate graph schema from existing tables for a team to review and approve, rather than requiring a graph data modeling expert to design the schema from scratch. It also supports natural language investigation through a built in AI agent or through external tools connected via the Model Context Protocol, and the query engine rejects undefined relationship references with feedback rather than failing silently, a detail that matters when an AI agent, not a human, is writing the query.
Security controls include row level permissions enforced during graph traversals, single sign on, role based access controls, user impersonation, short lived credential vending, and administrative audit logs, the kind of checklist that signals the company is selling into security and compliance conscious buyers rather than developer side projects. Weimo Liu, PuppyGraph's cofounder and CEO, put the company's bet plainly: the insights sitting inside enterprise data will soon be generated by agents, and those agents need a query interface built for how they actually ask questions.
The build versus buy question for graph
For a CTO deciding how to give AI agents graph reasoning capability, this round sharpens a real choice. Migrating relevant data into a dedicated graph database like Neo4j still makes sense when graph traversal is the primary access pattern for an application and the data volume is manageable, since purpose built graph databases offer storage and indexing optimized specifically for traversal performance. PuppyGraph's zero copy model makes more sense when the data already lives across multiple systems, when SQL remains the dominant access pattern for most workloads, and when standing up a new dedicated store is not worth the operational overhead.
Either path requires the same first step: mapping which relationships in your data estate actually need multi hop traversal for agent reasoning, rather than assuming every agent use case needs graph capability. PuppyGraph's free Docker based trial, which the company says gets a team from deployment to first query in about 10 minutes, is a reasonable way to test the zero copy approach against a real workload before committing budget to either a migration project or a new standalone data store that may solve a narrower problem than you actually have.
