A database that grows quietly

Add storage before moving data

Cloudflare D1, the database Authrim uses, has a size limit per database: 500 MB on the Free plan and 10 GB on the Paid plan. As users and their data grow, another place to store that data will eventually be needed.

Authrim is built to distribute accounts across multiple databases from the start, so reaching that point does not require moving every existing account. We call each of these storage units a shard.

Keep existing accounts where they are, and add destinations for new accounts.That is the basic approach to expanding account storage.

What routine operations no longer require

Once automatic provisioning is configured, an operator does not have to create a database, prepare its tables and connect a new registration destination every time registrations grow. Adding capacity does not require a migration plan for existing accounts each time, either.

The operator checks that provisioning is progressing, failures are visible, and usage and costs remain within expectations. Permission problems or service limits still need attention. With that division of work, Authrim prepares the next storage destination.

Today's free space is not enough

With 20,000 account slots remaining, a service adding 100 accounts a day has much more time to prepare than one adding 10,000 an hour.

Authrim therefore estimates future capacity from recent registration rates as well as current allocations. Both account storage and lookup indexes are forecast. A scheduled job runs every minute, and account forecasts are also updated after allocation.

Shards already being created count toward the estimate. If several processes notice the same shortage, they should not each create another unnecessary database.

From creation to active use

When spares are not enough, Authrim creates D1 databases through Cloudflare's management API. It creates the tables, configures Worker access and distributes the new storage locations. A database becomes an allocation target after its read and write checks pass.

Automatic provisioning must be enabled, with separate API tokens configured for D1 and Workers. When automatic execution is unavailable, an operator continues the work through the setup tool.

Progress is persisted during creation. A temporary connection failure can be retried from that state. Missing permissions or resource limits need an operator to resolve the cause before work can resume.

If preparation falls behind and account slots run out, new registrations may need to retry. Preparing ahead is intended to reduce that wait.

What has been measured

In a July 2026 test with 200,000 accounts, Core used about 208 MB, PII about 238 MB and Lookup about 426 MB. Each was below 5% of the Paid plan's 10 GB per-database limit. Actual usage depends on the attributes and indexes stored.

The default target is 100,000 accounts per shard, leaving room to prepare the next one instead of filling a database to its physical limit.

Authrim is pre-1.0, and long-running production experience at large scale is still to come. Measuring storage for 200,000 test accounts is distinct from operating a service used daily by millions of people.

Less migration planning as you grow

A small service does not need a large deployment on day one. It can start with a few shards and add destinations as registrations grow. Authrim includes the preparation and procedures needed to do that.

When users start arriving, planning a database move should not become the first job on the list. We want to reduce that work so more time can go into the service itself.