Capturing data modification events

A common requirement is to publish an event whenever a particular record changes — a listing is withdrawn, an order is paid, a device reading crosses a threshold. RDS and DynamoDB answer that requirement very differently, and the difference catches people out.

RDS

Amazon RDS event notifications fire on database instance-level events only: maintenance, backups, failovers, configuration changes. They do not fire on individual record changes or on SQL statements. Subscribing to RDS events to learn that a row was deleted will never work.

To capture record-level changes from an RDS database, use one of the following.

Application-level publication. The application that performs the write also publishes the event — for example to an SNS topic or EventBridge — after the transaction commits. This is the simplest option and the one with the fewest moving parts, but it only catches writes that go through that application.

Database trigger plus change data capture. A trigger in the database writes to an audit or outbox table; AWS Database Migration Service (DMS) with change data capture (CDC) reads that table and delivers the change downstream, typically to a Lambda function that publishes the event. This catches writes made by any client, at the cost of a trigger on the hot path.

Log-based change data capture. Rather than a trigger, read the engine’s replication log directly — the MySQL binlog, the PostgreSQL write-ahead log. DMS and other CDC tools do this. It imposes no write-path overhead and catches every committed change, which makes it the usual choice where completeness matters.

DynamoDB

DynamoDB publishes item-level changes natively through DynamoDB Streams, so no outbox table or CDC pipeline is needed.

Event types captured:

• INSERT — a new item was added.
• MODIFY — an existing item was updated.
• REMOVE — an item was deleted.

A stream record can carry the old image of the item, the new image, both, or keys only, depending on how the stream is configured.

Stream characteristics:

• Records are retained for 24 hours.
• AWS Lambda integrates with streams directly as an event source.
• Records can also be consumed through the Kinesis Adapter for DynamoDB Streams.
• Delivery is near real time, and records for a given item arrive in order.

Common uses: cross-Region replication (global tables are themselves built on streams in eventual-consistency mode), real-time analytics, event-driven application logic, audit trails, and notifications on data changes.

The practical summary is that DynamoDB treats “tell me when an item changed” as a first-class feature, while RDS requires the change stream to be built — through the application, a trigger, or the replication log.