A weekly event is one post to you and thousands of dated instances to the database. Calendars get slow because of the ones nobody typed.
Recurrence is the thing that makes an events site heavy, and it is invisible in the admin.
A weekly event running two years is thousands of occurrences the calendar must filter by date. Those lookups are indexed so opening next March costs the same as opening this week.
Events have a timezone and visitors have another. Dates are stored and compared in a way that survives daylight saving, so a listing does not drift by an hour twice a year.
Calendar subscriptions and iCal exports are polled by software on a timer. They are cached and revalidated, so a hundred subscribed calendars are not a hundred renders.
A month grid asks for every occurrence inside a date window. Given the right indexes that is a range lookup rather than a walk through the whole series table.
Editing a recurring event can rewrite every future instance at once. Daily backups mean getting that wrong is recoverable rather than a manual repair.
An organiser sees a dozen events. The database sees every occurrence of every series, and it is the second number that decides how the calendar performs.
The measure for a calendar is whether moving forward a few months feels the same as loading the current view, because that is what visitors do constantly.
Recurrence turns a small content set into a large one, and every row here is about querying the large one.
| Setting | What we do | Why |
|---|---|---|
| Occurrence indexing | Indexed on start and end date | Every calendar view is a date-range question against a table that recurrence has already multiplied by hundreds. |
| Feed caching | iCal and subscription feeds cached with validators | Calendar clients poll on a timer, so those URLs are requested far more often than any page on the site. |
| Timezone storage | Kept with the event rather than derived at display | Deriving a time at render means a daylight saving boundary silently moves listings by an hour twice a year. |
| Series regeneration | Run as a batch with its own limits | Changing a recurring event's schedule rewrites every future occurrence, which is far more work than a page request allows. |
| Past occurrences | Kept but excluded from default queries | An archive of finished events is worth keeping and worth never scanning on a view of next month. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Move the events site across — migration is free, every series included.