2025 was a big year for Bluesky decentralization. You might have heard of several independent Bluesky alternatives, like Blacksky, Northsky, and Eurosky. You might also have heard that these are nontrivial efforts, requiring significant development work and expensive computing resources. I’d like to dig into the second of those topics.

What makes Bluesky expensive?

Well it’s not the user data itself, I can tell you that much. User accounts in ATproto are each associated with a Personal Data Server (PDS), which is little more than a JSON-returning webserver wrapped around a SQLite database. A single PDS on a raspberry pi can host and serve data for tens of thousands of users without issue. This is not where the costs come from.

If you’re only vaguely familiar with ATproto, you might have heard about "relay servers" and the "global firehose" - big servers that vacuum up all writes to every PDS and serve them in a single massive stream. Is this where the cost comes from?

Nope. A full-network relay can also run just fine on a raspberry pi. It needs a somewhat beefy storage drive (a dozen or two terabytes), but that’s entirely within reach of a hobbyist. I’ve got plenty of friends with Plex servers whose storage requirements dwarf that.

Alright, what about the client web app? Is it just the costs of serving all the read traffic to all those users?

Again, not really. As proof, check out Red Dwarf. It’s a Bluesky client that works entirely client-side, with no AppView server of its own. It achieves this by 1) talking to PDS instances directly, 2) querying the Constellation microservice for links between records, and 3) using the Slingshot edge cache to fetch records more efficiently. Neither of those microservices are expensive either - their storage and compute costs are on a similar level as a full-network relay.

This is how a lot of ATproto infrastructure works. It’s radically different from ActivityPub and Mastodon, which splits up the system into lots of federated instances, with each instance having more or less a complete vertical slice through the infrastructure with its own user database, web frontend, moderation infrastructure, etc. ATproto instead partitions the network into many different microservices, and encourages each microservice to have a global view of the network.

Okay, but something must be expensive here. Blacksky isn’t seeking tens thousands of dollars for the hell of it. Where is the cost coming from?

Red Dwarf actually gives us a bit of a clue here. If you try using the app for a while, you might notice something missing: the Following feed. Custom feeds work fine, but the Following feed specifically won’t load. The documentation for Red Dwarf explicitly points this out as a limitation. That might seem a bit odd without some thought. Why that feed in particular?

It’s just one timeline, Michael

The Following feed is expensive. So expensive, in fact, that according to it accounts for half of Bluesky’s entire production workload, as of October 2025.

But why is it expensive?

Well, for starters, there isn’t just one Following feed. There’s forty million of them. Every user’s Following feed is unique.

They’re difficult to compute on demand too. Users might follow tens of thousands of accounts, or a single account the user follows might post hundreds of times per hour. And users notice when their timelines don’t update quickly. Dealing with this scale is a difficult problem. Bluesky handles it by making the Following feed lossy - rather than giving a precise chronological feed of every post from a followed account, it sheds load by occasionally dropping posts from rapid posters or from timelines of people who follow thousands of other users. Even with that optimization, the costs are significant.

What about Mastodon?

I’ll let you in on a little secret: ActivityPub has this problem too.

Have you ever noticed that if you log in to a Mastodon instance after being away for a while, instead of seeing your timeline you’ll see this friendly fellow:

Depending on how many people you follow, how frequently they post, how long it’s been, and how busy the instance you’re using is, it could take a long time for your timeline to load. This is because Mastodon stops updating timelines for infrequent users. This lets a Mastodon server avoid the costs of keeping timelines up to date for users who don’t use the app very much. It comes at a cost though: users who return to Mastodon after taking time away from it are much more likely to bounce off the app permanently if their returning experience starts poorly. The UX factor here is significant, and often unnoticed by power users.

Mastodon employs various other UX tricks that help reduce the cost of producing timelines. For instance, because every user’s account is tied to a specific Mastodon server, each server doesn’t have to produce timelines for every user, just the users belonging to that server. Similarly, servers don’t fetch posts from every other server. One server only talks to another if at least one user on the first server follows a user on the second server.

This works, but has similar costs as the timeline updating approach: a degraded user experience. Search queries can’t find posts by accounts on servers that your server doesn’t have any relationship with. Moving an account between servers becomes difficult to implement. Small servers bear the brunt of the UX cost, while large servers become significantly more costly to operate. A first-time-follow between a large server and a small server can even knock the small server over due to a sudden influx of processing load.

This doesn’t mean the tradeoff that Mastodon makes here is unreasonable. This is a difficult problem. The solution they’ve chosen makes a lot more sense given the different cultural context. The Fediverse has a much higher proportion of tech-savvy users, and many of them want to run a small semi-isolated stack of social media servers for just them and their friends. I can see why, too. It’s certainly a lot more interesting than just throwing everyone into a Discord server.

Can ATproto do the same?

There’s no reason in principle that the strategies chosen by Mastodon wouldn’t work for ATproto. The reason they haven’t been employed much is that broadly speaking, most Bluesky users want a global view of the network. We like that search works globally without much issue, that it doesn’t matter what PDS you’re using, and that your choice of client and host is invisible to others.

Blacksky, Northsky, and Eurosky are large efforts because they’re not trying to make the equivalent of a separate Mastodon server. They’re trying to make the equivalent of a separate deployment of every Mastodon instance at once. They’re meant to be global, full-network views of all forty million ATproto accounts that are fully independent of Bluesky. There is no cheap way to do that without making significant sacrifices to UX, in one way or another.

But what about power users who want an ATproto-based experience more like a small Mastodon instance for them and their friends? What are they to do?

Today, those users aren’t well-served. There isn’t an out-of-the-box, easy-to-deploy, and lightweight stack that’s completely independent of the Bluesky appview. I think there’s room for improvement here. A modified version of Red Dwarf that included a server for the Following feed limited to a selected list of invited users could be an interesting approach. The invite list could even be based on a PDS: press a button, deploy a PDS you can invite people too, a Following feed limited to just the users of that PDS, and a webserver that presents a Red Dwarf-like client app with customizable theming and which can only be logged into by accounts hosted on that PDS. And it could include its own moderation labeler and Ozone instance too.

I’d love to see it happen.