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.

Moving every existing account whenever a database fills up would be a lot of work. Authrim can distribute accounts across multiple databases from the start. We call each storage unit a shard.

Existing accounts stay where they are; new accounts get more places to go. That is how Authrim expands account storage.

What routine operations no longer require

Once automatic provisioning is configured, an operator need not create another database each time registrations grow. Preparing its tables and connecting a new destination no longer has to be repeated by hand. Adding capacity does not call for another plan to move existing accounts, either.

The operator watches provisioning progress, failures, usage and costs. Missing permissions or service limits still need a person to intervene. Authrim handles the preparation of 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.