Sequin can send a JSON event for every INSERT, UPDATE, or DELETE in your Postgres database to AWS Lambda via SQS or SNS:

• SQS queue – Sequin pushes to SQS; Lambda pulls via an event‑source mapping.
• SNS topic – Sequin publishes to SNS; SNS pushes straight into Lambda.

We’ll start by discussing the differences between using SQS and SNS. Then walk through the steps to create a CDC pipeline using each service.

With your Postgres data streaming to Lambdas, you can:

• Trigger downstream workflows (for example, send a Slack message or transactional email the moment a row is inserted).
• Keep an external cache or search index (Redis, OpenSearch, Algolia) in‑sync with Postgres updates. (When Sequin’s native sinks don’t meet your needs.)
• Fan‑out enriched CDC events to micro‑services that don’t have direct database access.
• Feed real‑time analytics pipelines (Kinesis, Firehose, Redshift) without complex ETL jobs.
• Detect anomalies in critical tables and raise alerts within seconds.

​

Architecture overview

1. Sequin captures logical replication changes from Postgres.
2. Changes are delivered to SQS or SNS (your chosen sink).
3. AWS Lambda consumes the events—either by polling a queue (SQS) or by receiving pushes (SNS).
4. Your Lambda code processes the payload (e.g., triggers workflows, updates downstream systems).

​

SQS vs SNS at a glance

We generally recommend SQS if you need:

• Ordering: You can use Sequin with an SQS FIFO queue to receive messages in order. For example, if a row is inserted than updated, an SQS FIFO queue will ensure your Lambdas process the insert before the update.
• Batching: SQS allows your Lambda to receive batches of messages. You might prefer batching if your Lambda is sending messages to another system, as batching can improve throughput.

However, choose SNS when you want the simplest, lowest‑latency fan‑out: SNS pushes each message directly to Lambda (no polling) and can deliver the same event to multiple subscribers at once. There’s no queue to manage, retries are handled automatically, and the operational overhead is lower than SQS for many‑consumer, push‑based workloads.

​

Prerequisites

If you’re self‑hosting Sequin:

1. Sequin installed
2. A database connected

If you’re using Sequin Cloud:

1. A Sequin Cloud account
2. A database connected

For both deployment modes:

• Permissions in AWS to manage SQS/SNS and Lambda resources.

​

Option A – SQS queue

​

1. Create or pick a queue

​

2. Grant Sequin permission

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sqs:SendMessage",
        "sqs:SendMessageBatch",
        "sqs:GetQueueAttributes"
      ],
      "Resource": "arn:aws:sqs:us-east-1:123456789012:postgres-events"
    }
  ]
}

​

3. Create an SQS sink in Sequin

​

4. Verify messages are being sent to SQS (optional)

Before proceeding to set up the Lambda consumer, it’s a good idea to verify that messages are being delivered to your SQS queue:

1. Make some changes in your Postgres database (e.g., insert into users(name) values ('test_user');). (If you had Sequin perform an initial backfill, you can skip this step.)
2. In the Sequin console, navigate to your SQS sink and check the “Messages” tab. You should see the changes listed with “Delivered” status.
3. In the AWS Console, navigate to SQS → Your queue. In the graphs, you should see a spike in messages received.
4. If messages aren’t appearing, check the sink’s status in Sequin (any error messages?)

Once you’ve confirmed messages are flowing to SQS, you’re ready to connect Lambda as a consumer.

​

5. Connect Lambda to the queue

​

6. Handle events in your function

If you didn’t specify a transform, refer to the messages reference for details on the default payload you’ll receive:

// cdc-processor/index.js
export const handler = async (event) => {
  for (const record of event.Records) {
    const change = JSON.parse(record.body);
    /* {
      record: {
        id: 1,
        name: "alice"
      },
      changes: null,
      action: "insert",
      metadata: {
        table_schema: "public",
        table_name: "users",
        commit_timestamp: "2024-03-21T15:30:00Z",
        commit_lsn: "0/16B78D8",
        sink: {
          id: "f47ac10b-58cc-4372-a567-0e02b2c3d479",
          name: "users_sqs"
        }
      }
    } */
    console.log(change);
  }
};

​

7. Test the pipeline

1. Insert a row in Postgres (INSERT INTO users(name) VALUES ('alice');).
2. In Sequin, you should see “Processed messages” increase. The message should also be shown as “Delivered” in the “Messages” tab.
3. In CloudWatch → Logs → “Log groups” locate /aws/lambda/postgres-processor and confirm the event appears.

If Sequin shows the message as “Delivered”, that means that the message made it to the SQS queue.

If you’re not seeing logs for your Lambda function in CloudWatch, it means that the message is not reaching your Lambda function. Be sure that the SQS trigger (event‑source mapping) on your function is Enabled, that the Lambda execution role has sqs:ReceiveMessage permission, and that any batch‑size or reserved‑concurrency limits aren’t blocking the invocation.

​

Option B – SNS topic

​

1. Create or pick a topic

​

2. Create Lambda function

// cdc-processor/index.js
export const handler = async (event) => {
  for (const record of event.Records) {
    const change = JSON.parse(record.Sns.Message);
    /* {
      record: {
        id: 1,
        name: "alice"
      },
      changes: null,
      action: "insert",
      metadata: {
        table_schema: "public",
        table_name: "users",
        commit_timestamp: "2024-03-21T15:30:00Z",
        commit_lsn: "0/16B78D8",
        sink: {
          id: "f47ac10b-58cc-4372-a567-0e02b2c3d479",
          name: "users_sns"
        }
      }
    } */
    console.log(change);
  }
};

​

3. Subscribe Lambda to the topic

​

4. Grant Sequin permission

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "sns:Publish",
        "sns:PublishBatch",
        "sns:GetTopicAttributes"
      ],
      "Resource": "arn:aws:sns:us-east-1:123456789012:postgres-events"
    }
  ]
}

​

5. Create an SNS sink in Sequin

​

6. Test the pipeline

1. Insert a row in Postgres (insert into users(name) values ('alice');).
2. In Sequin, you should see “Processed messages” increase. The message should also be shown as “Delivered” in the “Messages” tab.
3. In CloudWatch → Logs → “log groups” locate /aws/lambda/cdc-processor and confirm the event appears.

If Sequin shows the message as “Delivered”, that means that the message made it to the SNS topic. If you’re not seeing logs for your Lambda function in CloudWatch, check that:

• The subscription between SNS and Lambda is properly configured and active
• The Lambda execution role has permissions to receive messages from SNS
• SNS delivery status notifications aren’t reporting failures (check SNS → Topics → your topic → “Subscriptions”)

​

Verify & monitor

1. Sink dashboard – In Sequin, open the sink and watch the “Messages” tab for latest deliveries.
2. SNS delivery status – In the SNS console, you can enable delivery status logging to CloudWatch to track message delivery.
3. CloudWatch metrics – Monitor Lambda duration, error count, and SNS delivery metrics.
4. CloudWatch Alarms – Set up alarms for delivery failures and Lambda errors to catch issues early.

​

Maintenance & troubleshooting

• Schema changes – When your database schema changes, your Lambda code may need updates to handle new or removed fields.
• Message filtering – Use SNS message filtering or Sequin’s filters to reduce noise.
• Backfills – Use Sequin’s “Backfill” feature to send existing rows to your topic when adding new consumers or recreating a Lambda.

​

Next steps