Glean Knowledge Graph vs Microsoft Graph: the architectural fork that decides enterprise search at scale

Glean's bet was made in 2019 and is now compounding. Build a proprietary knowledge graph over the customer's SaaS estate. Index it. Re-rank against it. Sell the graph as the differentiator. Six years later that bet has produced a company that doubled ARR to roughly $200M in 2025 per Futurum Group coverage [1] and shipped a permissions-aware retrieval surface that competitors have spent two years trying to copy.

Microsoft's bet was made a decade earlier and is structurally different. The Microsoft Graph API, GA since 2015, exposes every entity inside a Microsoft 365 tenant — users, files, mail, calendar, chat, sites, devices — as a queryable surface [2]. Copilot did not build a parallel index. It calls the Graph live, scopes results by the caller's permissions, and threads the response back to the LLM. The compute lives in the tenant. The index is implicit.

These are not the same product strategy in different paint. They are different theories of where enterprise data should sit when an agent asks for it. The Glean theory says the customer's data is too scattered and too slow to query in place, so a permissioned mirror is the only way to make retrieval fast and ranking good. The Microsoft theory says the data already sits inside a tenant the customer pays Microsoft to host, so there is no reason to copy it — federation is the architectural primitive.

Per Glean's published architecture talks and Futurum's deep-dive coverage [1], the Glean Knowledge Graph is a permissioned, multi-tenant inverted index with a vector layer alongside, fed by 100+ connectors that pull from Salesforce, Slack, Confluence, Jira, ServiceNow, Box, Drive, GitHub, Notion, and the rest of the SaaS estate the customer authorizes. The index stores permission tuples per document — "this file is visible to these users at this moment" — and the connector refresh job updates both content and ACLs on a configurable cadence.

The flywheel is the part that matters. Every Glean customer adds query telemetry, click signals, and dwell-time data to a shared ranking model that no single customer could train on their own. The ranking gets better as the customer base grows, even before any individual customer's data changes. That is what "data flywheel" means in this category, and it is the structural reason Glean's per-seat price holds across cycles — the customer is buying the ranking model, not the index.

Trade-offs sit on the same shelf. The index is eventually consistent. The refresh window for a permission change in Salesforce is on the order of seconds-to-minutes per Glean's docs, which is fast for a permissioned mirror but not the live ACL enforcement you get when the source system answers the query directly. The vendor owns the ranking signal, so a customer who churns off Glean loses six-to-eighteen months of ranking-tuning the moment the contract ends.

Microsoft Graph is a REST API surface, not a search product. The endpoints expose Office 365 entities through a unified namespace: `/me/messages`, `/users/{id}/drive/root/children`, `/sites/{id}/lists`, plus search endpoints like `/search/query` that wrap the underlying SharePoint and Exchange indexing layers [2]. The compute that runs those endpoints lives in the customer tenant. The data does not leave the tenant. Permissions resolve against Entra ID at request time.

Microsoft 365 Copilot rides on top of that. A Copilot query becomes a sequence of Graph calls scoped by the caller's permissions, plus a call to Azure OpenAI to draft an answer grounded in the retrieved Graph results. The retrieval scaffolding (semantic kernel, the orchestration layer, the rerankers) is Microsoft's; the data plane is the customer's tenant. There is no proprietary index sitting between them, which is why "Copilot indexing" is a different shape of work than "Glean indexing." Copilot relies on the SharePoint search index and the Exchange index that the customer already pays for as part of M365.

The strength is structural. No data residency surprise. No vendor index to invalidate when an ACL changes. No license-tier mismatch between the search seat and the storage seat. The weakness is structural too. Throttling. The Graph API publishes per-resource rate limits — typical limits run 10,000 requests per 10 minutes per app per tenant for many endpoints, with backoff codes when you exceed them [3]. A Copilot rollout at 5,000 active seats hits those limits faster than anyone expects.

The freshness question is where the two architectures genuinely differ. A Microsoft Graph query returns whatever the SharePoint index and Exchange index hold at request time. The SharePoint indexer typically processes updates within 15 minutes; the Exchange indexer is faster [2]. For a Copilot query that asks "what did Maria send me this morning," the lag is operationally invisible — Exchange answers in seconds.

Glean's freshness depends on the connector. The Salesforce connector ships near-real-time webhook support; the Confluence connector runs scheduled pulls; the long-tail connectors run batch refresh on cadences ranging from hourly to overnight. Glean's own engineering blog has been candid that the worst-case freshness window for a custom connector can be 24 hours, with the median in single-digit minutes for the top-tier connectors.

For permission changes specifically, the asymmetry inverts. Glean's permission-mirror refresh has a non-zero window between the moment an ACL changes in Salesforce and the moment that change reflects in the Glean index. During that window, a user who lost access in the source system can still surface the document through Glean. Microsoft Graph does not have that window — the ACL resolves against Entra ID at request time, so permission changes are effectively immediate. That is the cleanest single argument for the federated architecture in regulated environments.

Microsoft Graph publishes its throttling thresholds. The numbers vary by endpoint, but the pattern is consistent: each application gets a per-tenant quota, breaches return HTTP 429 with a Retry-After header, and sustained breach triggers backoff windows of minutes [3]. For Copilot specifically, Microsoft has tuned the orchestration layer to batch and cache Graph calls — but at scale (5,000+ active Copilot seats sending mixed queries) you will hit the throttle. The architectural response is to pre-warm caches, batch reads, and accept that some queries take seconds longer than the demo suggested.

Glean's internal capacity is less publicly documented. The product does not publish per-tenant rate limits in the way Microsoft does, because the index is Glean's to scale. That is a product strength — the customer does not own the capacity-planning problem — and an opacity risk. If Glean has a bad quarter on infrastructure spend, the response is on Glean's side of the SLA. If Microsoft Graph has a throttling incident, the response is on the tenant's side of the SLA, with public dashboards and known mitigation patterns.

Cost-per-query math falls out of this asymmetry. Glean amortizes its indexing and serving cost across roughly $200M of ARR [1], which is how the per-seat price stays flat as the customer's query volume grows. Microsoft Graph's serving cost lives inside the customer's M365 license — the customer is already paying for SharePoint search and Exchange search as part of E3/E5. The marginal cost of a Copilot query is the Azure OpenAI inference call ($30/seat/month covers a metered allocation) [4], not the Graph read.

Lock-in is the procurement word for "how expensive is exit." Both architectures lock the buyer in. The shapes of the lock-in differ enough that some procurement teams pick one over the other on this alone.

Read that matrix once for what is symmetric — both vendors lock you in on identity, on connector investment, on pricing escalator timing. Read it again for what is not. Glean locks you into a multi-tenant SaaS where the proprietary index is the moat. Microsoft locks you into Azure, the M365 license stack, and the assumption that your data lives where Microsoft already keeps it. If your procurement guardrails forbid one of those postures, the architectural choice is decided before the eval starts.

Reduce both architectures to a unit cost and the comparison sharpens. A 1,500-seat enterprise running moderate query volume — say 40 queries per active seat per month, 600 active seats — generates 24,000 queries per month, or roughly 290K per year.

On Glean, the cost basis is the per-seat fee. Third-party reporting puts Glean's seat price near $45-50/user/month, with a Work AI add-on near $15/user/month that fires for agentic queries [5]. At 1,500 seats × $45 × 12 months that is $810K of base license. Divide by 290K queries and the unit cost is roughly $2.79 per query — but only at moderate volume. Push to 100 queries per active seat per month and the unit cost halves. That is the per-seat-pricing magic: heavy users subsidize light users, and Glean does not care because the price is flat.

On Microsoft 365 Copilot, the cost basis is the $30/seat/month Copilot add-on plus the E3 or E5 base the seat already carries [4]. Counting only the Copilot delta — the marginal cost of enabling Graph + Azure OpenAI orchestration — that is $30 × 1,500 × 12 = $540K. Same query volume gives roughly $1.86 per query. Lower than Glean. But the math hides the E3/E5 base ($648K-$1.03M depending on tier), without which Copilot does not function. Loaded all-in cost-per-query is in the $4-6 band, and the customer is paying for SharePoint search and Exchange search whether Copilot uses them or not.

Forrester's TEI report on Glean's work-AI platform [6] models a different scenario, with a composite organization that lands a three-year ROI of 304% — but the underlying per-query cost is not published. Procurement teams who want the math have to build it themselves, on their volume, with their seat mix. The headline number is rarely the decision input.

Architecture-level recommendations sit underneath product-level recommendations. The product comparison (Glean vs Copilot, feature-by-feature) we have covered in our Glean vs Microsoft Copilot piece. The architecture comparison is the question you answer first, because it narrows the product list.

Disclosure: Explore Agentic is published by ASCENDING, which builds Jarvis AI. The next paragraph is going to describe how a governance-first MCP platform sits between the two architectural bets above. Read it as that — an architectural option some buyers consider, not an attempt to relitigate the Glean-vs-Microsoft choice for everyone.

Both Glean and Microsoft assume a single primary graph. Glean builds one. Microsoft federates over the one already inside the customer's tenant. Neither posture composes well when the customer's data lives across AWS, Azure, and SaaS — three primary surfaces that are governed by three different identity systems. The MCP-first architectural option is to skip the proprietary index entirely and let an MCP gateway federate retrieval across whichever sources answer best per query. Jarvis Registry runs that pattern: connector calls go through MCP servers, the gateway logs every retrieval and tool call, and the LLM routing layer chooses between OpenAI, Anthropic, and Bedrock per query rather than per vendor agreement.

The trade-off is honest. You do not get Glean's cross-tenant ranking model — that flywheel only spins when one vendor sees query telemetry across many customers. You do not get Microsoft's tenant-native freshness — federation through MCP adds a connector hop that the Graph API does not. What you get is a control plane the procurement team can audit on its own terms, with MCP as the open protocol underneath and the LLM as a swappable backend. For organizations whose architectural risk is single-vendor lock-in more than retrieval quality, that trade is the reason the third path exists.