3 ms·

Heavy SG user here and while it's still pretty functional and not problematic enough to move away from, it's not as good as it used to be. Before being acquire

Heavy SG user here and while it's still pretty functional and not problematic enough to move away from, it's not as good as it used to be. Before being acquired, SG's support was fantastic. There are also various oddities that have cropped up, such as how they're currently hitting our webhook endpoint with the same event every 20 seconds for the past 8 days (a similar problem occurred last year too). They also seem to have suffered some dings to their IP reputation in numerous places due to, I assume, this: https://krebsonsecurity.com/2020/08/sendgrid-under-siege-from-hacked-accounts/ https://krebsonsecurity.com/2020/08/sendgrid-under-siege-fro... .. I continue to encounter numerous systems that flat out refuse any email from any IP I can muster at Sendgrid and we have a bunch on different subnets. So anyone who works at Red Hat, Packt, Akqa, Zendesk, etc.. they're not getting our mail. We use Postmark as a fallback for users when we get the inevitable error messages back, and they have been pretty good, although I find their API a little too slow to move everything over to them and SG has a fantastic "delayed send" feature which is a must for deliverability to iCloud addresses. Pragmatically I prefer Sendgrid, but Postmark is very good and feels somewhat more wholesome to use, particularly if your levels are low. I'd use Postmark for the same reason I'd rather use a local bakery than buy presliced at a supermarket.

pascal07 5y ago
> although I find their API a little too slow to move everything over to them Postmark product manager here... I'd love to know more about this. We publish our API response times on our status page (https://status.postmarkapp.com/ https://status.postmarkapp.com/), so this is a surprising comment. Can you email support@postmarkapp.com with your account details and we'll look into this for you?
- petercooper 5y ago
  To clarify for the benefit of any onlookers, I do not mean to say that Postmark's API is slow absolutely, but that it is slow(er) for how we use an email sending API relative to SG. Our email system is custom and does all of its own merging on a per subscriber basis, so we send a distinct request for every email, so even an otherwise minor difference between a 30ms and 85ms round trip "feels" slow at scale. I believe PM has a "batch" call available, but this requires some extra dev time at our end if it would resolve our issues (and it may!) I will get in touch, though, in case there are ways to help mitigate this problem or if the batch mechanism will solve it all. We have previously encountered similar performance issues with SG from time to time due to DNS sending us to unsuitable endpoints, etc. so it can be a universal problem to some extent based on how we've approached the problem. (Edit: Actually, that status page maybe demonstrates what I'm talking about, since the average API response time shown is 437ms. Even with 5 concurrent threads that would take 2.42 hrs to send 100,000 emails - so I am guessing the batch API is the way to go with PM :-))
  - pascal07 5y ago
    Yep /batch is definitely the way to go! But feel free to reach out to support and we can take it from there.

pascal07 5y ago

> although I find their API a little too slow to move everything over to them Postmark product manager here... I'd love to know more about this. We publish our API response times on our status page (https://status.postmarkapp.com/ https://status.postmarkapp.com/), so this is a surprising comment. Can you email support@postmarkapp.com with your account details and we'll look into this for you?

petercooper 5y ago
To clarify for the benefit of any onlookers, I do not mean to say that Postmark's API is slow absolutely, but that it is slow(er) for how we use an email sending API relative to SG. Our email system is custom and does all of its own merging on a per subscriber basis, so we send a distinct request for every email, so even an otherwise minor difference between a 30ms and 85ms round trip "feels" slow at scale. I believe PM has a "batch" call available, but this requires some extra dev time at our end if it would resolve our issues (and it may!) I will get in touch, though, in case there are ways to help mitigate this problem or if the batch mechanism will solve it all. We have previously encountered similar performance issues with SG from time to time due to DNS sending us to unsuitable endpoints, etc. so it can be a universal problem to some extent based on how we've approached the problem. (Edit: Actually, that status page maybe demonstrates what I'm talking about, since the average API response time shown is 437ms. Even with 5 concurrent threads that would take 2.42 hrs to send 100,000 emails - so I am guessing the batch API is the way to go with PM :-))
- pascal07 5y ago
  Yep /batch is definitely the way to go! But feel free to reach out to support and we can take it from there.