Resources & Limitations
Donotname is self-hosted on Railway. At our data volume (20,000+ records in several tables) everyday work is fast. This page is honest about the one operation that is genuinely heavy, why adding more hardware does not solve it, and how we handle it. This is about hardware and design trade-offs, not licensing.
Our environment
| Our production setup | |
|---|---|
| Host / region | Railway — EU West (Amsterdam, Netherlands) |
| Horizontal scaling | 2 replicas |
| Per replica (plan limit) | up to 24 vCPU and 24 GB RAM |
| Accounts table | ~21,600 records, ~45 calculated fields |
| Opportunities table | ~20,700 records, ~40 calculated fields |
| Projects table | ~20,700 records, ~51 calculated fields |
| Calculated fields per table | typically 40–52 (formulas, rollups, lookups) |
What we have measured
| Operation | At our scale | Result |
|---|---|---|
| Create / edit / delete a record | any table | Instant |
| Filter, sort, group, switch views | any table | Instant |
| Automations firing on record changes | any table | Instant to a few seconds |
| Recalculate one calculated field over a big table | ~50 records per batch | ~13–14 seconds per batch |
| Import a few thousand rows | large table | Runs in the background; minutes |
| Add or rename a dropdown option on a high-dependency field (e.g. Status, 109 dependent fields) | ~20,000+ linked records | Runs past the 10-minute operation limit, rolls back, does not save |
Where these come from: everyday timings are observed in normal use; recompute timings and the 10-minute ceiling come from the server logs and the automation run history (each step shows its duration).
The one genuinely heavy operation
Adding or renaming a dropdown option on a field that many calculated fields depend on forces the system to recalculate every dependent field, for every affected record, in a single database transaction.
On our data, changing an option on the Status field touches 109 dependent calculated fields across 20,000+ Opportunities, Projects, and Accounts records. That recalculation runs longer than the 10-minute transaction limit, so the change rolls back and does not save from the interface.
Why more hardware does not fix this
- More replicas do not help. Our 2 replicas scale concurrency — they let more people use the app at once. But a single heavy operation runs in one request, on one replica, in one transaction. It cannot be spread across replicas.
- More CPU / RAM per replica barely helps. The work is sequential and database-bound, not memory-bound. A replica can already use up to 24 vCPU and 24 GB RAM; the bottleneck is the amount of sequential recalculation (dependent-fields × records) and the 10-minute limit, not spare capacity.
- Raising the Railway plan's per-replica cap (currently 24 vCPU / 24 GB) buys more room for concurrent users, not for this single long operation.
How we handle it
- Adding a new Status (or similar) option: a developer adds it directly in about a minute — safe, because a brand-new unused option changes no existing values, so no recalculation is needed. (This is exactly how Contract — sent and Contract — signed were added.)
- Do not retry from the interface. Each attempt starts another full recalculation, can slow the whole app for minutes, and can leave a lock that blocks further edits until it clears.
- Large imports: split into smaller batches and run during quiet hours.
The real fix
Because this is a design characteristic, not a capacity shortage, the durable fix is a code optimization: treat "add / rename an option" as the lightweight metadata change it actually is and skip the unnecessary full recalculation. That removes the limit entirely, independent of server size or replica count. Until then, routing these specific changes through a developer is the safe path.
Reliability notes
- With 2 replicas, routine updates roll out with little or no downtime; an individual replica restarts briefly during a deploy.
- Back up the database regularly.
- Very long-running jobs (huge recomputes, massive imports) are best run during quiet hours.
Summary
- On our Railway setup (2 replicas, up to 24 vCPU / 24 GB each, EU West) the app is fast for everyday work at 20,000+ record scale.
- One operation is genuinely heavy — adding/renaming a dropdown option on a field with many dependents — because it recalculates everything downstream in one 10-minute-bounded transaction.
- Neither more replicas nor more RAM fixes it; the cost is sequential recalculation.
- For now a developer applies those specific changes directly (seconds); the durable fix is a small code optimization.