As @johannconsult's points out, neither this approach nor any other can eliminate malicious tampering with the output. However, using a PDF does discourage tampering more than some other approaches. For example, serving a JPG and overlaying HTML text client-side would make it easier for a user to tamper with output.

Comparing apples to apples (i.e. generating the PDF at the SQL Server vs. the web server): tamper-resistance is implementation specific. It would be possible to have a good web server-based implementation...but it would also be possible to have a poor implementation that accidentally exposed undesired data or functionality.

Some aspects of architecture are subjective, and some decisions are made with an eye on factors such as separation of concerns. In this particular example, I'd prefer not to have to trust the web servers for the integrity of the coupon image. I don't want it to be possible for the web server to accidentally get the wrong serial number on the wrong background image, to serve the same coupon more than once, to expose a means for a user to overlay arbitrary text on a coupon image, etc.

The approach in the article tries to minimize points of failure, minimize the surface area, and to minimize amount of code and number of platforms to debug. But this approach also simplifies life by not requiring the involvement of the web developer in development, support or maintenance of core business-critical functionality. There is good centralized visibility into exactly what was served, with no opportunity for the user to receive something other than what the database thought the user received. Change control is more easily enforced, yet changes are simpler to make when needed. These are a few of the benefits of this particular architecture.

The article is clearly not saying that SQL-side PDF generation is best in every case. Yet in this specific example there is an elegance to having all business logic and coupon-generation functionality encapsulated in the database. Yes, this needs to be weighed against other factors such as scalability. There are no free lunches--but there are no one-size-fits-all solutions either. Good architects make appropriate decisions in view of many factors.

Regarding "scalability": a good architect will understand requirements and make decisions accordingly. Do I need to serve up hundreds of coupons? Thousands? Millions? Am I providing a general service that needs to serve up buzillions of coupons from every manufacturer on earth, or am I serving up coupons for individual small vendors? Does everything need to live in one monster SQL instance, or should each vendor have their own SQL instance? Multi-tenant or single-tenant? Serving directly to consumers, or via API through affiliate partners? and so on...

I'm always amazed at the number of people that blindly cry "scalability" as some sort of a trump card without understanding the requirements first. Scalability is only one of many factors--and it is not necessarily the most important. Not every application needs to be prepared for an infinite growth in usage. What is more, there are lots of ways to scale--even if the architect decides to centralize functionality in SQL.

Consider just a few options in this example: farm of linked SQL servers for rendering PDFs (possibly even SQL Express as Ted Cooper-351490 suggested), separate SQL servers for each vendor, pre-render and store batches of unissued coupons, scale up hardware, and many more. This approach is not a "dead-end" street with respect to scalability.

What's more, until you benchmark and profile the end-to-end solution, you really don't know how resources are consumed. It could be that rendering the PDF is nowhere close to being the limiting factor for performance and scalability. But more importantly, no one who naively cries "scalability" without knowing the requirements really has much to contribute. In the absence of understanding and addressing requirements, that cry is little more than a DBA trying to look out for himself without concern for the overall solution.

I say this not to be defensive, but to try to be helpful and instructive. Yes, I understand that the role of the DBA is to protect the database...but the database is one element of an overall architecture that exists to serve a business purpose. The more that a DBA (or any individual) can understand and contribute to the ultimate business purpose, the greater value that person can offer.