Please provide some sizes. For example, how big would BIG be when it is time to remove the rows? How big are the other tables?

MEMORY is not necessarily better than InnoDB. It may be slower because of table vs row locking. It may interfere with overall performance because of taking RAM away from the buffer_pool for BIG, thereby slowing down other things.

Yes, having a "staging" table is a practical way to do certain things. For really high-speed staging, ping-ponging between two table may be desirable.

PARTITION is unlikely to be useful in what you have described so far.

Please describe what kind of data you have and why it needs AC or ACID (if it is not obvious from the data).

Please provide some sizes. For example, how big would BIG be when it is time to remove the rows? How big are the other tables?

MEMORY is not necessarily better than InnoDB. It may be slower because of table vs row locking. It may interfere with overall performance because of taking RAM away from the buffer_pool for BIG, thereby slowing down other things.

Yes, having a "staging" table is a practical way to do certain things. For really high-speed staging, ping-ponging between two table may be desirable.

PARTITION is unlikely to be useful in what you have described so far.

Please describe what kind of data you have and why it needs AC or ACID (if it is not obvious from the data).

Edit

Thanks. One row a minute? Things don't get exciting until 100 per second. Based on that, I would expect either MySQL or Postgres to consider this to be a "tiny" database.

I recommend doing it in whatever way is easiest for you. I do not forsee any scaling/performance problems, at least not for the near future. (I am assuming adequate INDEXes on the tables and reasonable queries.) I'm still vague on what the "pump" is, but it sounds unnecessary.