Skip to content

feat: add SQS DeleteMessageBatch operation with performance optimizations#54

Open
birme wants to merge 3 commits into
poundifdef:mainfrom
eyevinn-osaas:pr-batch-remove
Open

feat: add SQS DeleteMessageBatch operation with performance optimizations#54
birme wants to merge 3 commits into
poundifdef:mainfrom
eyevinn-osaas:pr-batch-remove

Conversation

@birme
Copy link
Copy Markdown

@birme birme commented Jan 11, 2026

Summary

  • Adds the SQS DeleteMessageBatch API operation, allowing clients to delete up to 10 messages in a single request
  • Implements batch delete at the database level for better performance instead of deleting messages one-by-one
  • Optimizes Message table queries to use primary key lookups instead of slower composite index scans

Changes

  • Added DeleteBatch method to the Queue interface
  • Implemented DeleteMessageBatch handler in the SQS protocol layer with proper error handling for individual entries
  • Added DeleteBatch implementation in SQLite queue using batch DELETE ... WHERE id IN (...) queries
  • Optimized existing Dequeue and Delete operations to use primary key lookups for the Message table

Test plan

  • Verify DeleteMessageBatch works with valid receipt handles
  • Verify DeleteMessageBatch returns appropriate errors for invalid receipt handles
  • Verify batch delete performance improvement with multiple messages
  • Verify existing Delete and Dequeue operations still work correctly

🤖 Generated with Claude Code

birme and others added 3 commits January 11, 2026 17:42
Add support for batch deletion of messages following the AWS SQS API
specification. This enables deleting up to 10 messages in a single request.

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Instead of calling Delete() in a loop for each message, use a single
database transaction with IN clauses to delete all messages at once.
This improves performance for batch deletions.

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
When querying Message table by id, use only the primary key instead of
filtering by tenant_id, queue_id, and id. This avoids slow composite
index scans when queues have many messages.

Affected queries:
- Dequeue UPDATE: ~2s -> instant (primary key lookup)
- Delete: uses primary key for Message, keeps composite for KV
- DeleteBatch: uses primary key for Message, keeps composite for KV

Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant