IMHO, there are some very limited scenarios where the use of a database trigger is valid.
These include the following:
- Audit trails: If there are multiple applications (micro-services) accessing a DB, you might want to keep a trail of which service (and user of service) modified or created a row. Even in this case, libraries and ORMs today will provide this functionality out of the box. I'm not entirely sure about Node.js, but Java Spring does provide this effortlessly.
That's about it. While triggers by themselves aren't evil, most developers don't use them properly which earns them a bad rap. It's like the Git Submodules of the database world. The list of cons is much longer than the pros:
- Because the triggers are defined in the database and not the source code, they are invisible to a new developer reading your code in a year's time. They will not be apparent till the application is run and the data changes stealthily. Extensive documentation is the only way out of this and we all know how much engineers love writing documentation :P
- Triggers will cause your SQL statement to not return till the trigger is completed. Unless you trust your current (and future) team to understand triggers, they'll become a huge performance bottlenecks in the future.
- Developers forget to load test triggers. Most people, while writing a trigger, will assume that only a single record is changing. They don't realize that busy databases have thousands of changes happening each database. What happens during a batch insert? What happens when an ETL job is running? Watching out for these scenarios making it much harder to write a good trigger.
- Triggers were originally meant to maintain data integrity, not execute on business rules. If you need to send an e-mail when a new user is created, this is not the responsibility of the database trigger. Developers start to play fast & loose with this constraint which leads to disaster.
- Triggers are global in nature. The trigger will not care which micro-service or which user is modifying a table. They will fire 100% of the times. If you believe using global variables is a bad idea, using global functions is 10x worse.
I don't know the specifics of your business use-case, but almost always, using a trigger is not a good idea. 99.9% of the use-cases can generally be covered using a good event management system and executing code based on events that are raised. This ensures that the code is doing exactly what it says it's doing, making it simpler to write, maintain & debug.