# Are there any plans for TRIGGERS/PROCEDURES of any kind on the ScyllaDB Roadmap **URL:** \ **Category:** ScyllaDB\ **Tags:** roadmap\ **Created:** [October 4, 2023, 11:00am UTC](https://forum.scylladb.com/t/are-there-any-plans-for-triggers-procedures-of-any-kind-on-the-scylladb-roadmap/889 "2023-10-04T11:00:02Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![felipemendes](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/felipemendes/32/11_2.png) [@felipemendes](https://forum.scylladb.com/u/felipemendes)\ **Post date:** [October 10, 2023, 2:12pm UTC](https://forum.scylladb.com/t/are-there-any-plans-for-triggers-procedures-of-any-kind-on-the-scylladb-roadmap/889/4 "2023-10-10T14:12:54Z")
A single outbox table is definitely the way to go - but it is not clear exactly why you would need a trigger. In fact, there are concerns to that, eg: tables can have a different partition (thus making your updates to end up on different set of replicas), or even in different DCs (should the table in keyspace live in a different keyspace), all of which could introduce an availability concern and make your trigger to fail (or worse, accumulate and over time degrade the entire system performance). What is feasible is to write to both your primary datastore and to an outbox table, and then consume the tail (with CDC or not) of the outbox table overtime. However, I see where you are coming from given [Are BATCH insert/update into different tables logged + "safe"?](https://forum.scylladb.com/t/are-batch-insert-update-into-different-tables-logged-safe/888) (which is ultimately tied to [scylladb/scylladb#13390](https://github.com/scylladb/scylladb/issues/13390)), but you will ultimately need to decide whether you will batch both entries (to different tables) altogether, or concurrently write. For batching, this will incur an entry on the batchlog, and the updates will be done asynchronously. So it may happen that you consume an event from the outbox table before a record gets persisted in the main service table (though that should be rare), but it doesn’t mean that the main table record is lost, as there’s a built-in retry mechanism to ensure that all entries eventually are applied. For parallel writes, you would need to work around the old fashioned “dual write” problem, so indeed not fun. --- _[View the full topic](https://forum.scylladb.com/t/are-there-any-plans-for-triggers-procedures-of-any-kind-on-the-scylladb-roadmap/889)._