PostgreSQL: ... LIMIT 1 much slower than fetching all rows?
The problem is that rows for 'foo@example.com' are deficient in values with an early date_created, but the planner doesn't know that.  It thinks they are evenly scattered, so it will find one early on when walking modwork_ticket_date_created and will be able to stop then.  But instead it has to walk through 1,705,251 of them.

You can create an index on (email_sender_id text_pattern_ops, date_created) and it will be able to jump directly to the tuple you want.  That should be much faster than either existing plan.   (I proposed the including text_pattern_ops purely because the name of the existing index has the word "like" in it, so I assume it was already defined that way--but maybe you actually have a column named "like".  It would be better if you show us the definitions so we don't have to guess about things such as this).  This index may be able to replace an existing one, so the overall number of indexes might stay the same.

If you don't want to create the index and just want it to the use the 2nd plan, you can force it by writing the query like this:

SELECT * FROM modwork_ticket WHERE 
 modwork_ticket.email_sender_id = 'foo@example.com' 
 ORDER BY modwork_ticket.date_created + '0 days' ASC limit 1;


By adding something to the date before you sort, it tricks PostgreSQL into thinking it can't use the date index.

Once v10 of PostgreSQL is released and you upgrade to it, you can create an advanced statistics definition for the functional dependency between the two columns, which might also be enough to get it to choose the better plan.