A developer building an ATProto search tool recently hit a cost wall from full firehose egress. Another developer surveyed the ecosystem and found roughly ten independent indexers running -- processing the same firehose, building the same indexes, storing overlapping data. The estimate: two or three shared indexers would serve the same need.
This is the most concrete evidence yet that ATProto's per-app AppView architecture does not match the ecosystem's economic reality.
The architecture assumption
ATProto's design separates three layers: PDSes store records, relays distribute them, and AppViews aggregate and index them for specific use cases. The intended model is that each application runs its own AppView -- its own indexer, its own database, its own query interface. A photo app indexes photo records. A blog platform indexes blog records. A social client indexes social records.
This model makes sense at scale. If an app has millions of users, the cost of running an indexer is amortized across a large user base. The indexer can be tuned for the specific record types and query patterns that app needs.
The economic reality
The Atmosphere has roughly 5,000 daily active users across all non-Bluesky apps. Nine lexicons have more than 50 daily users. At this scale, per-app indexers are pure subsidy. Every developer running a full firehose subscriber pays the same egress costs regardless of whether their app has 50 users or 50,000.
The full ATProto firehose produces a significant volume of data. Most of it is social content (posts, likes, follows) that a non-social app does not need. A photo app subscribing to the full firehose processes gigabytes of social data to extract the photo records it cares about. The ratio of useful to useless data for any single non-social app is low.
Multiply this by ten independent indexers and the waste becomes concrete: ten copies of the same firehose processing, ten databases storing overlapping data, ten servers paying the same egress costs. The ecosystem is spending ten times what it needs to on index infrastructure.
The convergence
The ecosystem is already converging on shared infrastructure, driven by economic necessity:
microcosm.blue emerged as a generic, replicable AppView that indexes records across multiple lexicons. Developers are building apps on top of microcosm.blue's backlink index rather than running their own AppViews. One developer built an entire app using microcosm.blue's backlink queries with no custom indexing infrastructure.
ATQL (Authenticated Transfer Query Language) is being designed as a native query language for ATProto records. Rather than each app writing custom indexer code, ATQL would let apps express queries against a shared index. The design discussion has drawn participation from both community developers and the protocol team, with a proposal to add a collections attribute to record references that would make query resolution significantly easier.
QuickSlice generates relationship queries from lexicon definitions, handling both forward and reverse record references. It represents prior art for the query expressiveness ATQL needs to achieve.
All three share a premise: apps should consume query infrastructure, not build it.
The decentralization tension
Shared indexers are more efficient but also more centralizing. If most atmosphere apps query the same two or three shared indexes, those index operators become critical infrastructure -- chokepoints with the same structural power as relay operators or AppView operators.
This mirrors a pattern from the web: the early web assumed every site would run its own search. In practice, search concentrated into a handful of operators because indexing the entire web is expensive and most sites cannot justify the cost. The result was Google.
ATProto's shared indexer trajectory could follow the same path. The protocol allows anyone to run an indexer. The economics push toward a small number of shared indexers. The equilibrium is not determined by protocol design but by who can afford to run infrastructure at scale.
The counter-argument is that ATProto's data is structured (lexicon-typed records) rather than unstructured (web pages). Structured data is cheaper to index because the schema is known in advance. A shared indexer for ATProto does not need the sophistication of a web search engine -- it needs a database that understands record types and references. This lowers the bar for running shared infrastructure, which could support more independent operators than web search did.
The practical question
The ecosystem needs to decide -- implicitly or explicitly -- whether shared indexer infrastructure is a commons or a market.
Commons model: One or two community-funded shared indexers, maintained as open infrastructure. microcosm.blue is closest to this model. The risk: commons infrastructure depends on sustained funding and maintainer commitment.
Market model: Multiple competing indexer services, potentially with paid tiers for higher query volumes or specialized indexes. The risk: market dynamics push toward consolidation, recreating the AppView concentration problem.
Hybrid model: A reference shared indexer as commons, with specialized indexes as market additions. Apps that need basic record queries use the shared infrastructure. Apps that need custom ranking, ML-based recommendations, or real-time analytics run their own.
None of these models are being explicitly discussed. The convergence is happening organically -- developers choosing microcosm.blue because it exists and works, not because the ecosystem agreed on an infrastructure model. The ten-indexers-where-two-would-do situation will resolve itself one way or another. The question is whether the resolution is deliberate or accidental.