A DM-based database for twitterbots on AWS Lambda

Armin Samii
2 min readOct 20, 2020


Running a Twitter Bot on AWS Lambda is almost certainly free — the Twitter API rate limits are low enough that you’re likely not going to exceed the 3.2 million seconds of free compute time per month.

To make the @realBigBoyTrump TwitterBot, I needed to read each of Trump’s tweets and translate them to babyspeak:

Every two minutes, my bot polls Trump’s twitter account for any new tweets. How can we keep track of which tweets are new since our last check?

  1. Bad idea: just check for tweets sent in the last two minutes
    This will miss tweets that were just over two minutes old (but that your last poll missed), and you’ll never get tweets back on any failed runs.
  2. Good idea: use DynamoDB to store the last-seen tweet
    You just need to store one value here, so you’ll likely stay in the free tier
  3. Best idea: use DMs as your database
    No fancy setup required, works just as well locally as on AWS, no credentials to share, and best of all, it’s as absurd as our president.

Here’s what our DM-based database looks like: just a DM to itself with the tweet ID of the last-seen tweet.

Benefits of this approach include:

  1. Does the easy thing, not the right thing
    Uses the existing infrastructure for your TwitterBot
  2. You don’t need to learn anything new
    No additional services needed, no additional setup needed
  3. Slow and inefficient
    Rather than using hyperoptimized AWS database services or key/value stores, where you can override data and not increase storage costs, you instead have an infinitely growing list (until the president stops tweeting) and a Twitter API roundtrip to read a single value

All of these being traits that our Baby President embraces.



Armin Samii

Building products using computer graphics and data visualizations. Ranked-Choice Voting enthusiast. Pittsburgh, PA.