Self-hosted Grist benchmarks

Grist is a spreadsheet-like database that can be self-hosted. I was considering if it was practical to use Grist as a backend instead of a database.

The hosted version of Grist has a rate limit of 5 requests per second and 5000 requests per day for the free plan. However, its documentation does not mention any rate limits for the self-hosted version, so I decided to test it. Here are the results. On the self-hosted version:

• There is no rate limit per second.
• There is no rate limit per day.
• There is a concurrency limit of 10 active requests per document which is hardcoded and applies to everyone.
• There is no limit on the number of rows.

I also ran some performance tests. The self-hosted Grist was running on a $10/mo Linode instance which is also used for other services. With that, I was able to make:

• 70 GET requests per second.
• 40 POST requests per second.

This shows that Grist is a viable option for using as a backend, with a few considerations:

• Use an in-memory asynchronous task queue such as p-queue to avoid hitting the concurrency limit, if you will have a sudden surge in requests. Importantly, set a cap on the queue size to prevent excessive queuing¹. This helps maintain responsiveness and avoids wasting resources on potentially stale requests². Note that the app may still hit the concurrency limit anyways especially if it is serverless or runs in multiple processes, so they must still be prepared to handle the occasional 429 responses.
• If there's a surge of users, then requests may start queuing up. If most users are making the same request, consider using an in-memory cache that coalesces requests, such as async-cache-dedupe.