We operate on AT Protocol (Bluesky). We need an AppView — either a fork/adaptation of the reference implementation or a purpose-built one — capable of holding and serving approximately 500 TB of firehose-derived data.
We attempted this on PostgreSQL. It did not hold. We need someone to own the data layer decision and the architecture around it.

What the AppView actually has to do:

• Firehose ingestion — continuous, append-heavy write stream of commits (posts, likes, follows, reposts, blocks) from relays. Sustained high write throughput, no natural backpressure.
• Social graph — follows/blocks/mutes. Read-hot, latency-critical, traversal-heavy. Fanout for timeline construction.
• Timeline/feed serving — low-latency reads under high concurrency. Fanout-on-read vs. fanout-on-write is an open decision.
• Aggregations & counters — like counts, reply counts, repost counts. High-cardinality, high-churn, read-hot.
• Search & discovery — full-text over posts, plus trend detection.
• Historical/analytical store — the bulk of the 500 TB. Cold, scanned rarely, must not sit on the same tier as hot data.
• Moderation/labeling — label lookups on the read path, plus retroactive takedown across the corpus.

• Diagnose the PostgreSQL failure. Before proposing anything, determine what specifically broke: write amplification, index bloat, vacuum pressure, connection saturation, fanout query cost, or storage layout. A proposal that does not explain why Postgres failed is not a proposal.
• Decide the storage topology. Almost certainly polyglot. Produce an explicit mapping of each workload above to a storage engine, with justification. Candidate technologies to be evaluated (not prescribed): ScyllaDB/Cassandra, ClickHouse, Redis/Valkey, FoundationDB, TigerBeetle-style purpose-built stores, RocksDB-backed services, object storage + Iceberg/Delta for the cold tier, OpenSearch/Meilisearch for search, and a graph-specific store if warranted.
• Design the hot/cold split. 500 TB cannot be uniformly hot. Define what stays on NVMe, what moves to bulk disk, what moves to object storage, and the mechanism that moves it.
• Design ingestion and backfill. Firehose consumption, ordering guarantees, replay/backfill after outage, and idempotency. Kafka or equivalent as a buffer.
• Design for the sharding boundary. Multi-tenant across federated networks. Define the shard key and its consequences.
• Deliver a benchmarked PoC. Two candidate architectures, real firehose data, real query shapes, published numbers.
• Deliver a cost model. 3-year TCO including hardware, hosting, and headcount to operate it.

• Production experience operating distributed databases at 100 TB+, where you personally owned the schema and topology.
• Demonstrated experience with write-heavy, fanout-heavy social workloads — timelines, feeds, social graphs, or messaging at scale.
• Experience with at least three of: ScyllaDB, Cassandra, ClickHouse, FoundationDB, Redis/Valkey, RocksDB, Kafka, Iceberg/Delta.
• Ability to explain the failure modes of PostgreSQL under this workload class in specific terms.
• Strong SQL and Python. Comfortable reading Go, Rust, and TypeScript — the AT Protocol ecosystem is written in them.

• Direct experience with AT Protocol — running a PDS, relay, AppView, or feed generator.
• Experience with a comparable federated or decentralized protocol (ActivityPub/Mastodon at scale, Matrix).
• Experience running stateful data infrastructure outside the hyperscalers.

• Competitive salary and benefits package.
• Flexible working hours to maintain work-life balance.
• Personal laptop with all necessary software.
• Support services: Corporate accountant and lawyer.
• Transparent and bureaucracy-free management.