Sometimes it’s the smallest additions that unlock the biggest improvements.

The problem

Until now, FutureCalls in Serverpod were executed sequentially. That worked — but it also meant: If one job took a long time, every other one had to wait.

The solution

I just contributed a small but powerful change to the Serverpod package: You can now configure

✅ how often the database is scanned for new calls ✅ how many calls are processed in parallel

In short: FutureCalls are no longer a bottleneck. You get full control over scheduling behavior and server load.

The how

Configuration is simple and flexible — and officially documented: 👉 https://docs.serverpod.dev/concepts/scheduling#configuration

The why

I ran into this myself while building a feature-heavy app. Instead of working around the bottleneck, I decided to fix it — and share it. Open Source, the way it’s meant to be. 🤝

Curious how you’re using FutureCalls in your projects. Any patterns or use cases worth sharing?