I'm leading Postmark's API development. Amazon SES is clearly going to be the low cost provider; nobody's going to compete on price. Time will tell what their actual deliverability rates are, what their spam handling really looks like, etc. I agree that price is a weak argument in any market. Now that we're at bottom, we'll see lots of innovation in this space, and everybody will win as a result. We have a great roadmap ahead with Postmark.
Postmark is amazing, particularly the service from Natalie and Chris. Whenever I have an issue they respond within 20 minutes.
It's unclear to me reading the SES docs how their spam handling will be; what they will be doing to police those with whom I share an IP address; and many other things. However, what is clear is that at no point will anybody respond to my support request at 11pm as your staff did the other night.
This analysis completely ignores the cost of time in switching.
For me personally:
SendGrid is completely transparent to my application since it's just an SMTP server.
SES is a web services API, so I need to either (a) rewrite my app to take advantage of it, or (b) write my own SMTP wrapper. Either way, it's code, and I can't imagine ever writing code to save a few dozen dollars per month.
If Amazon offered an SMTP server like SendGrid does, then I could imagine switching, but until then, the monthly savings are negligible.
So run a postfix/sendmail gateway to fork a perl script to send email through the SES API? Doesn't this seem like kind of a kludge? Why not just send mail through the original SMTP server if you're going to take the time to set it up and maintain it?
You're right, if you have a lot of code already committed to the SendGrid API then it makes sense that the saving would have to be large to warrant developer time, but at some number of emails/month you reach a tipping point.
I think a large part of his point is that most software support's "the SendGrid API" by default, since it's SMTP. Ever for news apps that reduces the number of libraries easily available.
Possibly, but you still need to background process the email sending for most apps even if you are sending via SMTP, and at that point an API call isn't too much to add, IMO.
no you don't, you run an mta bound to 127.0.0.1 and smarthost out sendgrid/whatever-your-outbound-relay-is. this has been standard practice forever. if you quiz 10 sysadmins to name a single config variable for sendmail, most will answer "DS".*
mta's have been doing asynchronous message queuing loooooong before it was cool with web developers.
*note, the ones who go off on a tangent about mta holy war's are the bad ones
I think I have more than 20 components using Sendgrid. I forget what and where because it's been working like magic for so long.
Also the free Sendgrid addon for Heroku is a dream for throwaway apps.
My time is quite valuable, and the costs of Sendgrid aren't even a drop in the bucket compared to other costs. So I don't plan on switching any time soon.
It’s a steep hill for SendGrid and any other email service provider to compete against Amazon SES. If the price if your only factor you are a loser in this fight; if you cannot justify the price difference with tangible features you are also a loser.
We were looking around for an email service early this month; Amazon SES seems like the reasonable choice for us; hard to beat.
I work for JangoSMTP, a transactional email service provider. Amazon SES certainly has the lowest price out there, but as you mentioned, there are a lot of reasons to choose a service provider for transactional emails, and only one is price. If you are looking for a minimalist service for the lowest price, then the Amazon SES may make sense for you. JangoSMTP is more robust, in that it has both API and SMTP relay options, along with bounce and unsubscribe management, open and click tracking and advanced reporting (Google Analytics, logging, etc.).
From what we have learned, Amazon SES does little more than send out emails. If you have the resources to implement your own list management, campaign management, DKIM signing, reporting, etc., then it's a great choice. If you need a company to do this for you though, you'll still want to go with a service like JangoSMTP.
When it comes to analysis, you really need to think about your ultimate goals first. If you are looking for a minimalist service for the best price, then Amazon SES may make sense for you.
I work for JangoSMTP and we get a lot of clients coming to us from other transactional email providers because they need more. Deliverability is a major issue that comes up. You may be able to send out mass quantites of email, but without an experienced email marketing provider you may struggle to reach people's inboxes. Delivery is as much an art as it is a science, and it takes constant focus to stay on top.
Also, Amazon only offers an API. JangoSMTP gives you the option to send through an SMTP server as well as API. We also offer open and click tracking, as well as advanced reporting (Google Analytics, logging, etc.). If reporting is important to you, you will want to consider a service like JangoSMTP that is more advanced than Amazon SES.
Due to Amazon’s lax policies, the EC2 IP blocks have been blacklisted due to spam and the like. If they maintain this lax policy, it will only be a matter of time before SES gets blacklisted and becomes largely unreliable if you actually want the e-mail you send to get to the recipient.
-useful comment on the blog page, and missing from HN comments
There may be many problems with SES, but I do not think that blacklisted IP's will be one of them. Nobody sends more emails than Amazon - they know how to do delivery.
Do they know how to keep spammers off their servers? Because if not, it doesn't matter what they know about delivery, they're going to be blacklisted.
On the other hand, if their "in-house content filtering technologies" prove effective at stopping spammers, how many legitimate users will get banned as false-positives?
Not yet, would be my advice. Let other pioneers get the arrows in their backs...
How much would you really save, assuming for your use case that Amazon is a lot cheaper, by waiting for 90 days? After all, you have to re-write and test your code to use the SES API anyways (maybe; or you can use their special script).
I've tried SES. The implementation is the difference between making a call to SMTP and making an API call, which is quite trivial.
The other thing to consider is deliverability from Amazon. I would hope that they run on a different IP range than EC2, but besides that they have a different risk profile than other SMTP hosts. Amazon is able to make it as cheap as they do because their risk is based on implementing quotas based on reputation in addition to making you verify the sender address (both making it quite difficult to use the service to send spam).
So far that makes it pretty solid. The only thing I haven't been able to figure out so far is how to set DKIM keys.
setformarriage.com is currently running through Sendgrid. While they have had great support and do have some very cool features (all of the ones we actually use have an SES equivalent), I think we're gonna have to switch once our AppSumo deal runs out. I imagine someone will have created a Rubygem for it by then, but if not it looks like it will be pretty easy to whip one up.
This may be my new favorite chart on the entire internet. None of the curves are relevant, and the scale required to demonstrate the point is almost preposterous.
