With Pelican, you move away from dynamic, database-driven websites toward static ones. The obvious question is: why would you want to do that in the first place?
One possible answer is risk reduction. You may want to lower your risk, that is, the probability of an incident multiplied by its impact, by reducing the number of possible threat vectors. You may also want to rely on less code, knowing that more code usually means more programming errors.
In a traditional CMS-based setup, both the application layer and the database design can introduce weaknesses that may eventually turn into vulnerabilities. By contrast, a static site reduces that complexity significantly. Instead of maintaining an entire dynamic stack, you are often left with a much smaller exposure surface centred primarily on the web server and its surrounding infrastructure.
At first glance, that trade-off may seem impractical. Greater security is of limited value if moving from a dynamic site to a static one means losing useful or even critical functionality. The more interesting question, therefore, is whether those features can be retained without reintroducing the same monolithic complexity.
That is where static publishing becomes more compelling.
Pelican allows you to keep a simple writing workflow while generating the final HTML for you. At the same time, additional functionality does not necessarily need to live inside the site itself. Instead, it can be provided by separate external services.
In that sense, the discussion becomes less about static versus dynamic websites and more about architectural style. Rather than relying on a single monolithic platform to provide everything, you can begin to think in terms of distributed services, a microservices-style approach to web publishing.
A Pelican-generated site that uses APIs to communicate with services such as Disqus for comments and Mailchimp for mailing lists is, in practice, an example of this way of thinking. The site itself remains simple and static, while specialised external systems provide selected dynamic capabilities.
This does not mean there is a universal solution. There is no one-size-fits-all architecture. But it does suggest a useful shift in perspective.
An organisation consists of functional building blocks that interact with one another in order to produce goods or services. In software, object-oriented programming introduced a major shift in how systems were structured. Microservices may represent a comparable shift at the level of service infrastructure.
From that perspective, Pelican is more than just a static site generator. It can also be part of a broader move toward smaller, more focused, and more loosely coupled services.