#5133·atproto

Proposal: Admin endpoint for per-account and per-server storage usage

Author: btrscoCreated Jun 24, 2026Updated Aug 29, 2026

Is your feature request related to a problem? Please describe.

There's no way to read how much storage, in bytes, an account or the whole server consumes. com.atproto.server.checkAccountStatus already exposes per-account counts (repoBlocks, indexedRecords, expectedBlobs, importedBlobs), but those are counts, not byte sizes, and the endpoint is authed as the account holder rather than as an admin, so an operator can't read them across accounts and there's no server-wide rollup. To get actual byte usage today I shell into each container and run du -sb /pds/actors /pds/account.sqlite on a cron, and I list the blob store per account to sum blob sizes. Both are slow at scale, race against live writes, and break the moment the on-disk layout changes.

Describe the solution you'd like

An admin endpoint returning per-account byte usage, which the PDS can compute from its own per-actor SQLite (repo block lengths) and blob store:

com.atproto.admin.getAccountStorage
  params:  { did }
  output:  { did, blobBytes, repoBytes, recordCount }

Plus a server-wide rollup:

com.atproto.admin.getServerStorage
  output:  { accountCount, totalBlobBytes, totalRepoBytes }

This lets operators drop the container shelling and blob-store scanning they currently use to measure storage, and report accurate byte figures instead of estimates.

Describe alternatives you've considered

  • com.atproto.server.checkAccountStatus (current closest thing). Returns counts, not bytes, and is scoped to the calling account, so it can't be used by an operator across accounts.
  • du over the data directory via container exec (current approach, fragile and layout-dependent).
  • Scanning the blob store per DID (both the disk and S3 blob stores key objects under the DID, so this works either way, but it is slow and is bookkeeping the PDS could do itself).
  • Walking each repo over getRepo to sum block sizes (far more expensive than reading from the actor store directly).

Additional context

Useful for capacity planning, quota enforcement, and usage-based billing. Relevant to anyone running more than a handful of accounts, not just managed hosts. The byte sizes are the missing piece. The counts already exist, they're just not exposed to an operator.