hosting costs #
Planning notes, September 9, 2026. These estimates separate measured protocol work from assumed user activity and operator labor. They are not a hosting quote, a supported-account limit, or measurements of moderation workloads.
PDS hosting can have inexpensive record processing while still carrying material costs for media, backups, support, and abuse response. Account count alone is a weak capacity measure: active users, application behavior, retained bytes, and misbehaving clients determine the load.
benchmark evidence #
The local comparison in benchmarking measures equivalent single-caller apply-one-record commits:
| implementation | commits/second |
|---|---|
| ZDS | 1,598 |
| Tranquil | 267 |
| official PDS | 448 |
These are synthetic local measurements. They do not establish production throughput with large databases, media traffic, proxy requests, or background sync. The same document keeps HTTP routes, storage operations, and concurrency curves separate; those measurements should not be substituted for each other.
The August 4 Fly upload run used a shared 1-vCPU / 1-GB target with 100 seeded accounts. Ten concurrent 3-MiB upload/write/verify operations had a publish p95 of 583 ms. Forty reached 13.1 seconds, with an unrelated session probe reaching 11.3 seconds p95. All completed successfully, but latency suffered. This is a historical burst measurement, not a fresh capacity test of current ZDS.
illustrative account scale #
Assume:
- 20% of hosted accounts are active each day.
- Each active account makes 20 record writes/day, including likes and follows.
- Peak record writes reach ten times the daily average.
- New media averages 1 MB per hosted account/day across the entire population.
These are chosen inputs, not observed user averages. MB, GB, and TB below are decimal units. A month is 30 days and a year is 365 days.
| workload | 1,000 accounts | 10,000 accounts | 100,000 accounts |
|---|---|---|---|
| daily active accounts | 200 | 2,000 | 20,000 |
| record writes/day | 4,000 | 40,000 | 400,000 |
| average record writes/second | 0.046 | 0.463 | 4.63 |
| assumed peak writes/second | 0.46 | 4.63 | 46.3 |
| new media/month | 30 GB | 300 GB | 3 TB |
| media retained after one year, without deletion | 365 GB | 3.65 TB | 36.5 TB |
The record rates are below the isolated benchmark throughputs, which suggests ordinary record processing is tractable under these assumptions. This does not prove that one instance can serve any of these populations. Media bursts, database growth, sync replay, proxy traffic, and recovery need separate tests.
Media totals exclude imported account history, repo blocks and event history, backups, and replication. Egress depends on downloads and downstream caching, not just bytes uploaded. Audio/video publishers can change the media assumption by orders of magnitude.
A monthly infrastructure estimate needs measured quantities and current rates:
compute + primary storage + backups + egress + request charges
+ monitoring/email + operational labor
The benchmarks do not supply enough evidence for an all-in dollar quote. Measure the working set, sustained CPU, proxy and sync egress, retained bytes, and backup/restore time before choosing an instance or promising a service level.
moderation scope #
A PDS operator decides what it will host. An appview decides what it will distribute within its product. Operators can choose stricter hosting policies; the protocol does not restrict them to legal compliance. A narrow hosting policy can leave application-specific social moderation to apps while still addressing illegal hosted material and network abuse. Legal obligations depend on the operator's jurisdiction and service; this note does not define them.
PDS account takedowns have consequences across applications, so false positives and appeals deserve care. They stop local hosting and signal downstream services; they do not erase every copy or tombstone the user's identity.
| operator work | cost driver |
|---|---|
| hosted-content complaints | report verification, locating material, investigation, evidence handling, legal escalation |
| spam farms and repeat abuse | correlating accounts, distinguishing legitimate automation, preventing repeat signup |
| compromised accounts | credential revocation, owner communication, investigation, restoration |
| appeals and mistaken enforcement | human judgment, documentation, reversal and follow-up |
| automated media checks, if adopted | scanning volume, integration, false-positive review, video processing |
| infrastructure-provider complaints | timely response and coordination with hosting, storage, and relay operators |
Not all of this is conventionally called moderation; security, support, and abuse operations share the work. Broader hosting policies add cases and judgment requirements. An appview label does not by itself stop the PDS serving content.
ZDS already has account takedown, credential revocation, denied reads/writes, and account-status events. The takedown runbook documents the remaining audit and retention workflow boundaries. Executing a takedown is inexpensive relative to investigating and managing a difficult case.
illustrative operator labor #
There are no measured PDS incident rates behind this table. It is a sensitivity exercise, not a forecast for ZDS, Tranquil, or Bluesky:
- Routine scenario: five actionable cases per 1,000 hosted accounts/month, averaging 30 minutes of total handling time each.
- Elevated-abuse scenario: twenty cases per 1,000 accounts/month, averaging one hour each.
- Operator time is valued at an assumed $50/hour, not a surveyed market rate.
monthly handling hours = accounts / 1000 * cases per 1000 * hours per case
| hosted accounts | routine hours/month | elevated hours/month | routine labor | elevated labor |
|---|---|---|---|---|
| 1,000 | 2.5 | 20 | $125 | $1,000 |
| 10,000 | 25 | 200 | $1,250 | $10,000 |
| 100,000 | 250 | 2,000 | $12,500 | $100,000 |
This amounts to $0.125 or $1 per hosted account/month in case-handling labor alone. It excludes fixed tooling, specialist counsel, scanning services, ordinary support, and staffing for coverage outside working hours. These two scenarios are not lower and upper bounds. A single difficult incident can exceed a small host's entire monthly allowance.
Admission policy, user population, report quality, and automation can change case rates substantially. Attacks arrive in bursts, and staffing needs do not scale smoothly with average handling hours. Paid access may add friction to abusive signup, but should not be modeled as eliminating abuse.
Implementation efficiency changes infrastructure costs; it does not establish lower investigation costs. Bluesky's whole moderation operation is also not a PDS-only baseline: it includes application moderation and other product work.
For pricing, track actionable cases, total handling time, appeal/reversal rates, media growth, and ordinary support separately. Those observations can replace the assumptions above without mixing infrastructure capacity with policy scope.