# 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:** 4\ **Page:** 1
**Author:** ![Hartmut](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/hartmut/32/135_2.png) [@Hartmut](https://forum.scylladb.com/u/Hartmut)\ **Post date:** [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/1 "2023-10-04T11:00:02Z")
Hi, are there any plans for _TRIGGERS_ of any kind on the ScyllaDB Roadmap? Also how about functions that go beyond UDF/UDA, to e.g. read/write into other tables? References > **[DynamoDB Streams and AWS Lambda triggers - Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.html)** > > When you need database triggers in DynamoDB, use the combined power of DynamoDB Streams and Lambda functions. Learn about creating triggers and out-of-band data aggregations to scale to new heights. > **[CREATE TRIGGER](https://www.postgresql.org/docs/current/sql-createtrigger.html)** > > CREATE TRIGGER CREATE TRIGGER — define a new trigger Synopsis CREATE \[OR REPLACE \] \[CONSTRAINT \] TRIGGER name … ---
**Author:** ![tzach](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/tzach/32/172_2.png) [@tzach](https://forum.scylladb.com/u/tzach)\ **Post date:** [October 9, 2023, 8:10am UTC](https://forum.scylladb.com/t/are-there-any-plans-for-triggers-procedures-of-any-kind-on-the-scylladb-roadmap/889/2 "2023-10-09T08:10:42Z")
Hi No, there is no plan for triggers in the short-mid term. See > > > Support CQL \`CREATE TRIGGER\`, \`DROP TRIGGER\` > Similar to UDF #2204, Scylla trig…ger should \*\*not\*\* necessary use Java > > related nodetool operations: \`nodetool reloadtriggers\` > > https://issues.apache.org/jira/browse/CASSANDRA-1311 > https://issues.apache.org/jira/browse/CASSANDRA-7606 > https://issues.apache.org/jira/browse/CASSANDRA-4949 Note that UFA/UDA are close but not yet production-ready. Similar to the DynamoDB reference you included, one can use the ScyllaDB CDC feature to look for an event and run application-level logic. Tzach ---
**Author:** ![Hartmut](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.scylladb.com/hartmut/32/135_2.png) [@Hartmut](https://forum.scylladb.com/u/Hartmut)\ **Post date:** [October 9, 2023, 5:42pm UTC](https://forum.scylladb.com/t/are-there-any-plans-for-triggers-procedures-of-any-kind-on-the-scylladb-roadmap/889/3 "2023-10-09T17:42:51Z")
Thanks @tzach for your reply. One use case I’ve had in mind actually would have been to build sort of an outbox pattern. Since it’s not recommended/applicable to enable CDC for a high number of tables it would be interesting to create a single ‘outbox’ table with CDC enabled, and push events into this table upon writing to many other tables (via TRIGGERS). But maybe that’s actually ‘putting the cart before the horse’. I guess what I’m asking for or planning to workaround is having a DB-wide WAL?!? Would that be something worth exploring? ---
**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.