Perplexity has replaced one of the most consequential pieces of infrastructure behind its sourced answers: the engine that decides which pages enter the retrieval pipeline and how those candidates are ranked before the model receives evidence. The new system, called Photon, now powers retrieval and ranking across Perplexity’s production search stack, and the company says it has reduced p99 latency at that stage from roughly 800 milliseconds to about 65 milliseconds.
The architecture is detailed in Perplexity’s official Photon technical report. The company says its previous system was a mature open-source retrieval and ranking engine that Perplexity had forked and adapted over time. As the index and workloads grew, however, the team encountered scaling costs, tail-latency spikes and recovery constraints that it concluded would be easier to solve with an in-house system built around Perplexity’s own AI-search workload.
For publishers, Photon matters for a reason that is easy to miss when infrastructure announcements are reduced to latency charts. This is not merely a faster database. Photon participates in candidate retrieval, initial ranking and second-stage ranking. In other words, it helps determine which pages the higher-level search system is allowed to consider before it gathers page content for the agent to generate a grounded answer.
Photon sits at the gate before citations
Perplexity describes each query as moving through a distributed search index where a small set of relevant pages must be selected and ordered under a strict latency budget. Photon’s shards retrieve candidates, perform ranking and return their best results to a broker. The broker merges those candidates, fetches selected document fields and returns the ranked results to the higher-level search service, which then gathers the page content needed by the agent.
That means Photon is upstream of the visible citation. It does not guarantee that every selected page will appear in the final answer, and it does not by itself decide whether a generated claim is properly supported. But a page that fails this retrieval-and-ranking gate may never become available to downstream reasoning at all.
NetContentSEO recently examined exactly that distinction in Perplexity’s Q2D-Web retrieval benchmark. That research showed why citation visibility is the result of a funnel rather than one ranking event. Photon is now the production infrastructure operating at a crucial part of that funnel.
The headline speed gain is at p99, not average latency
Perplexity reports that the old production system’s p99 response time was approximately 800 milliseconds. Under some index-merging conditions, page faults could push p99 to roughly 1.2 seconds for periods of 10 to 15 minutes. Photon reduced the production p99 measurement to around 65 milliseconds, according to the company.
That is a reduction by a factor of a little over twelve at the 99th percentile. The distinction matters: Perplexity is not claiming that every search call became twelve times faster end to end. The 800-to-65-millisecond comparison covers stages inside Photon and explicitly excludes later stages in the higher-level search stack.
Tail latency is particularly important for agentic search because one slow retrieval can stall a larger workflow. An agent may execute several searches, compare sources and continue reasoning only after results arrive. Reducing the slowest retrievals can therefore matter disproportionately even when median latency is already acceptable.
Photon stores 2.5 times more ranking data per document with fewer serving machines
The performance gain did not come from shrinking the amount of information available to the production ranking system. Perplexity says Photon stores approximately 2.5 times as much data per document while using about 20% fewer equivalent serving machines than the content nodes in the previous system.
The engine achieves that partly through compact data representations and selective decoding. Photon maintains inverted indexes for candidate selection and separate compact per-document records—called docblobs—for ranking information such as term frequencies, field coverage and term positions. The system can inspect only the pieces needed for matched query terms rather than decoding an entire record.
Perplexity says it subsequently used the additional per-document data capacity to improve ranking quality beyond the old system. That is strategically important for GEO: infrastructure efficiency is being converted into richer signals available at source-selection time, not simply lower compute cost.
Candidate selection is explicitly bounded by a work budget
Photon’s retrieval design also makes the economics of source visibility unusually concrete. Exhaustively scanning every posting list would be too expensive, so the engine uses a WAND-like traversal that divides term lists into those that can propose candidates and those that contribute to scoring candidates proposed elsewhere.
The process begins with a strict query-coverage requirement and relaxes it if too few candidates are found. Candidate admission becomes harder as the retained set improves, allowing Photon to prune documents whose maximum possible score cannot clear the current threshold.
For publishers, this is another reminder that relevance exists inside computational constraints. A potentially useful page does not compete in an unlimited reasoning environment. Retrieval systems have budgets for how many lists they inspect, how many candidates they retain and how much ranking data they decode before returning a source set.
Fresh verticals can update in minutes
Photon separates index building from live query serving, allowing Perplexity to prepare new index versions without making search requests compete for the same compute resources. Distributed preparation and parallel indexers can build the full web index in a single-digit number of hours, according to the report.
Not every vertical waits for a full rebuild. Perplexity says document delivery for verticals with high freshness requirements can happen in a single-digit number of minutes. New index versions are loaded into serving groups one at a time, warmed with real search-log queries and checked before returning to production traffic.
This narrows the time between publication or change and potential availability in retrieval for freshness-sensitive content. It does not guarantee immediate ranking or citation, but it reduces infrastructure delay as one possible reason a new page remains invisible.
The new Search API fast preset uses Photon differently
Perplexity is also exposing the infrastructure improvement to developers through a new fast preset for its Search API. The company reports single-search-call latency of 160 milliseconds at p50 and 230 milliseconds at p95 for the preset.
Across six agentic benchmarks—WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 and SEAL-Hard—Perplexity reports an aggregate task score of 64.3% for the fast configuration at an estimated model-plus-search cost of $59.73, compared with 64.0% at $187.60 for its default preset. On that test set, the estimated total cost was therefore about 68% lower while aggregate task performance remained similar.
Those comparisons need the caveats Perplexity itself supplies. Provider latency figures are self-reported and the measurement setups are not controlled like-for-like comparisons; some providers also publish different tail percentiles. The cost and quality results are based on Perplexity’s selected benchmark suite and model-plus-search estimates rather than an independent universal workload.
Fast is not simply the default preset at lower cost
The most useful disclosure in the report is that Perplexity quantifies what the faster preset gives up. On internal retrieval-quality benchmarks covering long-tail queries, broad coverage and result diversity, the fast preset scored 2.21 on Perplexity’s relevance measure versus 2.45 for the default configuration. Answer availability fell from 0.596 to 0.567, a difference of 2.9 percentage points.
Perplexity attributes the trade-off to using less compute for ranking. It recommends the fast preset for day-to-day agentic tasks, while describing the default preset as more robust for challenging or ambiguous questions where latency matters less.
This is a revealing design choice because it makes retrieval depth a tunable product parameter. The system can spend less time and compute selecting sources and still perform similarly on an aggregate task benchmark, while losing some relevance and coverage on harder retrieval cases.
Long-tail source visibility can depend on the retrieval budget
For GEO, the fast/default distinction suggests that citation opportunity is partly workload-dependent. A page relevant to an obvious, well-covered query may survive even under a cheaper retrieval configuration. A niche page answering an ambiguous or long-tail question can require broader candidate coverage or more ranking effort before the system identifies it as useful evidence.
This does not mean publishers can know which Perplexity configuration will encounter their page in every context. The Search API preset is a developer-facing choice, and the production Perplexity product has its own search stack. But the underlying engineering result demonstrates something important: source selection quality changes when retrieval compute changes.
That makes “rank in AI search” an even less stable concept than conventional position tracking. The source set can depend not only on the prompt and index state but on latency budgets, retrieval configuration, ranking depth and the requirements of the calling agent.
Photon and CobbleDB solve adjacent but different citation-layer problems
Photon follows another major Perplexity infrastructure change that NetContentSEO covered in our analysis of CobbleDB. The two systems occupy different parts of the source pipeline.
Photon retrieves and ranks candidate pages. CobbleDB serves prepared page records—including the passages and representations needed after source selection—so downstream systems can consume the chosen evidence efficiently. Put together, the projects show Perplexity replacing multiple generic infrastructure layers with systems designed specifically around AI-native search.
That distinction is useful for publishers because it separates two invisible failure modes. A page can fail because the retrieval-and-ranking engine never selects it, or it can be selected but encounter later processing, evidence-selection or generation decisions before a citation appears. Faster passage storage does not solve candidate ranking, and better candidate ranking does not guarantee final citation.
Faster retrieval changes the economics of agentic search
Photon’s larger significance may be economic rather than purely technical. Agentic applications can perform multiple searches inside one task. If every retrieval call is expensive or has unpredictable tail latency, developers have an incentive to search less often. Lower search latency and lower model-plus-search cost can make repeated retrieval more practical.
That can change how agents behave. Instead of relying heavily on internal model knowledge after one search, an agent can potentially issue additional queries, investigate subproblems or verify a claim with another retrieval pass while remaining within an acceptable latency and cost budget.
The trade-off is that the fastest configuration is also less robust on long-tail coverage. Developers are therefore choosing not merely between expensive and cheap search, but between different evidence-acquisition profiles.
The gatekeeper behind AI citations is becoming a first-class product
Traditional SEO tends to focus on the ranking result that users can see. AI search makes several ranking layers invisible because the user sees an answer after retrieval, reranking, evidence gathering and generation have already happened. Photon exposes one of those hidden layers in unusual detail.
Perplexity’s production migration confirms that retrieval and ranking are not peripheral plumbing beneath its answer engine. They are a deliberately engineered gate that determines which pages can become evidence, how quickly the candidate set can be produced and how much document information the ranking system can afford to inspect.
The company’s internal numbers are strong but should remain framed as company-reported measurements. The p99 improvement is specific to the Photon stage, the API provider comparisons are not fully standardized, and the fast preset deliberately accepts lower relevance and answer availability on harder internal retrieval tests.
For publishers, the important lesson is not that a 65-millisecond engine will automatically produce more citations. It is that the machinery deciding who can be cited is becoming faster, richer and more configurable. Perplexity has rebuilt that gatekeeper from scratch—and its own fast preset shows that when an AI agent buys speed by spending less compute on ranking, some of the first evidence to disappear can be the harder, longer-tail material at the edges of the source pool.