
Should I switch from Sendgrid to Amazon SES? - petercooper
https://willj.net/2011/01/25/should-i-switch-from-sendgrid-to-amazon-ses/
======
danielcrenna
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.

~~~
kljensen
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.

------
portman
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.

~~~
jonursenbach
The kicker with SES is that you don't have to use it as an API, and you can
easily integrate it with Postfix or Sendmail.

[http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/...](http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/index.html?IntegratingWithServer.html)

~~~
rbranson
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?

------
risotto
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.

~~~
aneth
> Also the free Sendgrid addon for Heroku is a dream for throwaway apps.

Don't they charge separately for every application? I found myself not using
the Heroku add-on so I could combine all my sending into one account.

~~~
steveklabnik
They would, yes. But if you send out < 200 emails per day, then you're not
paying anything at all.

------
grandalf
The real test of this sort of service is how well they manage the reputation
of any IPs that are shared between customers.

------
kno
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.

~~~
sdsdfvsdf
I assume processing incoming emails is a tangible feature SendGrid wins on

~~~
rfugger
You could receive at SendGrid and send at SES to save money.

------
johns
If you want to do incoming handling as well as outbound, you won't be able to
use SES for now. SendGrid has a great incoming parse API:
t<http://wiki.sendgrid.com/doku.php?id=parse_api>

------
KimJangoMail
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.

------
ameyamk
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

~~~
zoomzoom
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.

~~~
rfugger
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?

<http://aws.amazon.com/ses/faqs/#5>

------
patrickgzill
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).

------
danielrhodes
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.

------
jarin
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.

------
wlll
Added memory to the server and added apache workers. Site should be a bit
snappier now. Sorry for the slow response times earlier!

------
sorenbs
You should factor in data transfer cost as well. But for ordinary text-only
emails the cost will still be way lower.

------
bound008
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.

~~~
wlll
The curves seem relevant to me, they show the price you pay for amount of
email you send for different email sending plans.

Regarding the scale, the company I work for sends more mail per month than the
x-axis shows, so not so preposterous.

------
md3
not if your wikileaks

