These two are competing for the same search term and not really for the same customer. Resend is built around one person's first hour: a small SDK, fast domain verification, React Email, and a log view that answers did it send. SendGrid is built around an organisation's next three years: relay for systems nobody owns, a marketing console, a certification pack, a procurement contact. If you are one developer shipping a product, the second list is overhead. If you are a company with a marketing team and a compliance review, the first list is a toy.
At a glance
| Resend | SendGrid | |
|---|---|---|
| What it is | Developer-first email API built on SES | Twilio's email platform — API, SMTP, and marketing |
| Published pricing | Free 3,000/mo (100/day). Pro $20 at 50K and $35 at 100K. Scale starts at $90 for the same 100K and runs to $350 at 500K. Overage $0.65–0.90 per 1,000. Marketing contacts billed separately at $40/mo per 5,000. | Essentials $19.95 at 50K and $34.95 at 100K. Pro $89.95 at 100K, $249 at 300K, $499 at 700K. Dedicated IP is Pro and above; extra IPs $30/mo. Marketing Campaigns is priced as its own plan, not an add-on. |
| Best for | The fastest path from an empty project to a sent email, especially with React Email. | Enterprises wanting one procurement relationship, SMTP everywhere, and marketing in the same console. |
| Watch out for | Logs are purged at 30 days on every non-Enterprise plan, the API is capped at 2 requests per second on all tiers, and suspension during traffic spikes is the complaint that recurs in its public reviews. | The free tier died on 27 May 2025, replaced by a 60-day trial at 100/day. Support latency and abrupt account suspensions dominate its public reviews. |
Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything.
Where they actually differ
Who the product is actually designed for
Resend
One developer, working alone, who wants the email part finished before lunch. Everything follows from that: the SDK surface is deliberately small, the documentation assumes you can read code, domain verification is genuinely quick, and there is no settings page that requires a decision you are not qualified to make. The design succeeds at what it targets. It also means the second and third people who need to touch email — a support agent, a marketer — find much less waiting for them.
SendGrid
An organisation, where email is something several departments do for different reasons. The console reflects that: separate sections for the API user and the campaign user, permission scopes, subusers, an integration catalogue. It is more product than a solo developer needs and the extra surface is the cost of serving everyone from one account. Teams who only ever use the send endpoint experience that breadth purely as friction.
The free tier, which only one of them still has
Resend
Resend has a genuinely usable free allowance with a daily cap alongside the monthly one, and it is the reason a very large number of side projects are on it. The daily ceiling is the thing to check against your traffic shape, because a batch that fits comfortably in the monthly number can still fail on a Tuesday. But it exists, it is permanent, and it costs nothing.
SendGrid
SendGrid's permanent free tier was retired in May 2025 and replaced with a time-boxed trial at a low daily cap. Every internal tool, staging environment and side project that was quietly living there became a paid decision on a deadline. If you are comparing these two because a SendGrid trial is running out, that is not a coincidence — it is the most common reason this comparison gets made at all.
The ceiling you hit first
Resend
Resend caps API requests at two per second on every tier, including the most expensive one, and upgrading does not lift it. For request-response mail triggered by user actions this never matters. For anything batch-shaped — a digest, an announcement, a nightly job — it means a queue and a drip, which is ordinary engineering that nobody estimated and that no amount of money removes. Check the shape of your traffic before the plan price.
SendGrid
SendGrid's throughput is not the constraint people meet; the plan's included volume is. That is a fundamentally different kind of ceiling, because it is a billing event rather than an architectural one. A campaign that goes out faster than expected costs more, rather than taking six hours. Whether that is better depends entirely on whether your problem is the invoice or the clock.
Marketing mail, and how each one handles it
Resend
Resend has broadcasts and an audience concept, with marketing contacts billed separately from sends. That last detail is the one that catches people: a list that grows raises the bill in a month you sent nothing to it, which is a contact-priced model quietly attached to a send-priced product. The campaign tooling itself is deliberately light — enough for an announcement, not enough for a marketing team with a segmentation strategy.
SendGrid
Marketing Campaigns is a full product with lists, segments, a visual designer and campaign reporting, priced as its own plan rather than bundled. It is the better tool for the job by a wide margin, and the reason to notice the pricing structure is that a comparison built on the sending plan alone will understate the invoice by an entire line item. The upside is a shared suppression list across marketing and transactional, which two separate vendors cannot give you.
Templates and where they live
Resend
React Email is maintained by Resend, genuinely good, and lives in your repository so template changes go through review like any other code. It is also not a lock-in, because it renders to HTML any provider will accept. The catch is the same one every code-based template system has: a copy change requires a developer and a deploy, and the marketing person who wants to fix a typo cannot.
SendGrid
A template editor in the console with versioning and test sends, editable by someone who has never opened the codebase. It produces less pleasant HTML than a React renderer and it is much more useful on a Friday afternoon when the person who needs to change a subject line is not an engineer. The two approaches are not really competing on quality; they are competing on who is allowed to make a change.
Legacy systems and the SMTP question
Resend
Resend supports SMTP, and the support is adequate rather than a focus. If your mail comes from application code calling an API, this never comes up. If it comes from a CRM, a ticketing system, a WordPress install and a build server, you are going to be writing your own integration instructions, because nobody else has written them for you yet.
SendGrid
This is SendGrid's quiet moat. Fifteen years as the default relay means a documented path exists for almost any system that sends mail, frequently written by that system's own vendor. When the requirement is get mail out of a platform we are not allowed to modify, the existence of prior art is worth more than a nicer SDK.
What happens when something goes wrong
Resend
Suspension during traffic spikes is the complaint that recurs in Resend's public reviews, and the mechanism is the ordinary one for a shared-pool provider: an unfamiliar surge looks like risk to a platform protecting everyone else, so the conservative move is to pause first. Support is responsive by the standards of a company this size, but there is no severity scale and no contractual response time on the self-serve plans.
SendGrid
Abrupt suspension also dominates SendGrid's reviews, and support latency is the other half of the same complaint. The difference is procedural rather than qualitative: there is a ticket system, a defined severity scale and an escalation path that a customer-success contact can push on at the higher tiers. Neither company comes out of this dimension well; one of them at least has a documented process for the bad day.
Log retention, and what you can still answer next quarter
Resend
Thirty days on every plan short of Enterprise, after which the record is gone. That is enough to debug an integration and not enough for a billing dispute, a compliance request or a year-over-year comparison. Streaming events into your own store from day one fixes it and costs a day of work, and almost nobody does it until the first time somebody asks a question about March.
SendGrid
Activity history is available further back, with the window widening on higher plans and an additional retention product available on top. It is more generous than thirty days and it is still a vendor window on a vendor's terms. The structural point is identical for both: if you need the history to outlive the relationship, it has to land somewhere you own, and neither vendor will do that for you by default.
Pros and cons, side by side
Resend
Strengths
- A permanent free allowance still exists here, with a daily cap sitting alongside the monthly one, which is the reason an enormous number of side projects and staging environments now live on this side of the comparison.
- The SDK is small enough to read in one sitting and domain verification genuinely completes in minutes, so the email portion of a new product is finished before the rest of the afternoon is.
- Templates are React components in your own repository, reviewed like any other code, and they render to plain HTML that any provider will accept — so adopting them commits you to less than it appears.
- There is no settings page asking for a decision you are not qualified to make, which sounds like a small thing until you have spent an hour choosing between four supported ways to do one job.
Trade-offs
- Two API requests per second on every tier, unlifted by any upgrade, so batch-shaped traffic gets a queue rather than a plan change and the queue is permanent.
- Marketing contacts are metered apart from sends — a contact-priced model quietly attached to a send-priced product — so an accumulating list raises the invoice with no campaign behind it.
- SMTP is supported rather than cultivated, so pointing a CRM, a build server and a WordPress install at it means writing the configuration notes that nobody else has written yet.
- Thirty days of log retention on every plan short of Enterprise, in a view designed to debug this week's integration rather than to answer a question about last quarter.
SendGrid
Strengths
- Fifteen years as the default relay, which means whatever appliance, plugin or unloved internal system needs configuring, somebody has already documented pointing it here — usually that product's own vendor.
- A template editor a non-engineer can actually use, with versioning and test sends, so the person who needs to fix a subject line before the weekend does not need a developer or a deploy.
- Subusers give per-tenant credentials, reputation, suppression and reporting beneath one parent account, and for anybody sending on behalf of customers that single feature frequently decides the evaluation.
- The procurement machinery exists and works: a certification pack, a data processing agreement, a defined severity scale and a named escalation contact on the higher tiers.
Trade-offs
- The permanent free tier ended in May 2025 and became a sixty-day trial at a low daily cap, which is the specific event that sends most people to this comparison in the first place.
- Marketing Campaigns runs on its own plan and its own meter, so the promised consolidation happens at the login screen rather than on the invoice.
- Being cut off abruptly and waiting on support are the two themes that dominate its public reviews, and the compliance function responsible for the first is not reachable through the queue handling the second.
- The console carries fifteen years of accumulated surface, and a team that only ever calls the send endpoint experiences every bit of that breadth as friction.
Pick in thirty seconds
Choose Resend if
- You are a small team shipping application email from your own codebase, and time-to-first-send is the metric that actually matters this month.
- Templates as reviewable React components in the repository is how you want them, and a developer changing copy is acceptable.
- Traffic is request-response and comfortably under two API calls a second, with nothing batch-shaped anywhere in the system.
- A permanent free allowance matters, because a side project or a staging environment should not generate an invoice.
Choose SendGrid if
- Mail has to leave systems you do not control, and a documented relay integration for each of them is worth more than a pleasant SDK.
- A marketing team needs segmentation and a visual designer, and you would rather they shared a suppression list with the transactional side than ran a second vendor.
- Procurement needs a certification pack, a data processing agreement and a named support escalation before anything ships.
- A campaign going out fast is a billing question rather than an architecture question, because the rate ceiling is not something you can engineer around.
What actually moves when you switch
In roughly the order you would do it. The expensive parts of an email migration are never the send call.
- Measure the traffic shape against the rate ceiling before committing to anything else. Two requests per second on every tier is the one constraint here that money cannot remove, and a nightly job that loops over a list making one call per recipient will meet it on the first run. Batch endpoints taking several recipients per call are the mitigation; rewriting the send loop is the work.
- Export all four SendGrid suppression collections — global unsubscribes, bounces, spam reports and blocks — and import them before the first message goes out. They sit behind separate endpoints, and a partial export is precisely how a migration re-mails everybody who previously complained.
- Re-implement the dynamic templates as components. The handlebars-style substitution is evaluated inside SendGrid and does not travel; the HTML does. This is usually the largest single chunk of the project, and unusually for a migration task it leaves the codebase better than it found it.
- Settle where the campaign mail lives. Broadcasts and an audience concept exist on the destination and are deliberately lighter than Marketing Campaigns — no segmentation engine, no visual designer. If a marketing team is working in that console today, have the conversation before the sending cutover rather than the week after it.
- Inventory every SMTP sender and cost each one on its own. Anything currently pointed at SendGrid through a documented integration has to be re-pointed using instructions nobody has written yet, and the awkward ones — an appliance, a legacy plugin, a vendor that only knows one relay — are where the schedule actually slips.
- Rewrite the event consumer. SendGrid posts a batched array of events to one URL; the destination posts individually signed payloads with a different vocabulary, so every alert and report derived from the old shape has to be re-derived before anybody trusts the new numbers.
- Plan around thirty days of history rather than whatever you had. The destination purges at thirty days on every plan short of Enterprise, so if any process depends on older records, building the event pipeline into your own store belongs inside this migration rather than on the list after it.
- Warm the new identity before moving the mail that matters. The dedicated IP and everything the mailbox providers learned about it stay behind, so begin on a subdomain with low-stakes traffic, watch the complaint and bounce rates settle, and move password resets last.
Questions to ask before you sign
Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number.
- Does anything in our system send in batches, and has somebody counted API calls per second at peak rather than on a monthly average?
- Who edits email copy today — an engineer or somebody in marketing — and what does that person's Friday afternoon look like after the switch?
- How many of our senders are systems we cannot modify, and does a written integration path exist for each of them on the side we are moving to?
- Do we send on behalf of customers, and if so does the destination offer per-tenant credentials, suppression and reporting, or would we be building that ourselves?
- What is our current invoice actually made of — one plan, or a sending plan plus a marketing plan plus dedicated IP charges nobody folded into the comparison?
- Will procurement accept the new vendor's certification posture, and has anybody asked them before the engineering work started rather than after?
- How far back do we need delivery records to reach, and does that answer survive a thirty-day window?
Common questions
Why is Resend so much cheaper at small volume?
Partly because it sends through Amazon SES rather than operating its own network, so the underlying delivery cost is low and the product is the layer above it. Partly because it is not carrying the cost of a marketing platform, a certification programme or an enterprise sales organisation. The gap narrows considerably at volume and once marketing contacts are billed alongside sends, so a comparison drawn at a thousand messages a month will not predict the one at a million.
Can I move from SendGrid to Resend without changing my templates?
The HTML moves fine, since both accept a rendered string. What does not move is anything using SendGrid's dynamic template system with its handlebars-style substitution, because those templates live in SendGrid and are evaluated there. You either re-implement them as React Email components or keep rendering them yourself and send finished HTML. Budget for the second option; it is the one most teams end up on regardless of what they planned.
Does the two-requests-per-second limit apply to bulk sends?
It applies to API requests, so a batch endpoint that accepts multiple recipients in one call goes considerably further than sending one message per call. The constraint bites hardest on architectures that loop over a list making individual calls, which is the shape most application code arrives in. The point worth internalising is that no plan removes the ceiling, so if your traffic is batch-shaped the queue is permanent rather than temporary.
Which one is better for deliverability?
Neither, in any way that generalises. Both run shared pools, both have public complaints about suspension during spikes, and both will deliver well for a sender with clean list practices and correct authentication. The variable that actually predicts your placement is your own sending behaviour — engagement, bounce rate, complaint rate, DMARC alignment — and it dominates the difference between these two vendors by a wide margin.
Is SendGrid's free tier really gone?
Yes. It ended in May 2025 and was replaced by a sixty-day trial with a low daily cap, after which a paid plan is required. This is worth stating plainly because a large amount of the writing comparing these two predates the change and still describes an allowance that no longer exists, and because it is the specific event that pushed a great many small projects into running this comparison in the first place.
Does Resend have an equivalent of SendGrid subusers?
Not in the same shape. SendGrid's subusers are a genuine multi-tenancy primitive: each one carries its own credentials, its own sending reputation, its own suppression list and its own reporting, all underneath a parent account somebody administers. Resend's model is an account with domains and API keys, which serves a single product well and does not give an agency or a platform per-customer isolation. If you send on behalf of other businesses, price rebuilding that isolation honestly, because it is not a feature request you can wait out.
We pay for a dedicated IP on SendGrid. Does it come with us?
No, in the same way that no dedicated address travels anywhere: the IP is the vendor's asset and the reputation attached to it is a record mailbox providers keep about that address, not about your domain. What you are really giving up is the calendar — weeks of gradually increasing volume that somebody already served. Resend offers dedicated addresses on its higher tiers, so the capability exists, but you start the schedule again. For most senders below a few hundred thousand messages a month the shared pool is the better place to be anyway.
What can Resend's broadcasts actually do?
Send a message to an audience, with a basic contact record and unsubscribe handling. That covers a product announcement, a changelog mail or a newsletter with one list. What it does not cover is behavioural segmentation, a visual designer a marketer would choose to work in, branching automations, or campaign analytics beyond opens and clicks. Teams treating it as a Marketing Campaigns replacement generally discover the gap during the first campaign somebody in marketing owns, which is a bad time to discover it.
How long does a migration between these two realistically take?
The send path is days. The schedule is set by three other things: re-implementing dynamic templates, re-pointing the SMTP senders you do not control, and warming a new identity. The first two are estimable once you have counted them, and the third cannot be compressed — you are raising volume gradually while watching complaint and bounce rates, which takes weeks at meaningful volume. Run both providers in parallel on separate subdomains and budget for two invoices during the overlap, because that cost arrives whether or not anybody planned it.