Comment by sophacles

I don't know specifically, I'm not the person who posted about that database. But it happens all the time, even in 2026 at good tech companies.

It tends to come from a couple of common places...

* efficiency - triggers, stored procedures and constraints can often speed up throughput in terms of transactions per second by reducing the number of round trips from the application to the db. I know above i mentioned its not about qps necessarily, but a telephone billing db probably includes records of calls and txts and so on, which across millions of people adds up.

* Older architecture patterns didn't put a single service in front of a database for that service. Instead theres a single database for the company, or for a function within the company, and many programs and services interacted with that database. In such an architecture, stored procedures and triggers are really useful for some business logic, to ensure consistency between various systems... Need to update tax rules for one state? Just donit in the db instead of the sales pos system at the stores and the billing system and the phone operator sales system and the website and the gateway for 3rd party sellers, etc. there's a certain logic to it too... This data is fundamental to the business and has lots of rules associated with it, those make sense to place together - the rules change independently of the systems accessing those rules, and over the life of the company those rules tied to laws and accounting may last far far longer than any given pos system or website rewrite.