# Brevo vs Scaleway Transactional Email Source: https://wraps.dev/versus/brevo-vs-scaleway-tem Two European options that answer a residency requirement from opposite ends: a full marketing and messaging platform, and a cloud provider's bare sending endpoint with almost nothing above it. People compare these two for one reason: somebody has decided that email must not leave European infrastructure, and the American vendors are therefore off the list. Once that constraint is fixed, the remaining field is small and unusually polarised. One of these is a complete messaging platform with campaigns, automation and a light customer database. The other is a sending endpoint from a cloud provider with essentially nothing built on top. There is very little in between, and the choice is really about how much you intend to build. ## At a glance |   | Brevo | Scaleway Transactional Email | | --- | --- | --- | | What it is | EU marketing platform with a transactional API attached | European cloud provider's SES equivalent | | Published pricing | Priced on send volume rather than contacts. Starter runs from roughly $9/mo at 5,000 emails to roughly $69/mo at 100,000; the Business tier is roughly double at each volume and is where automation and A/B testing live. | Free 300/mo, then €0.25 per 1,000 on Essential with no monthly fee. The Scale plan bundles 100K plus a dedicated IP, with €0.20 per additional 1,000. | | Best for | Small EU teams wanting email, SMS, and a light CRM on one invoice. | EU data residency with no US cloud in the path, at near-SES pricing. | | Watch out for | The headline tier is not the one you need — automation and removing the Brevo logo are both a step up. Shared-pool deliverability draws mixed reports. | European footprint only, a much smaller ecosystem than AWS, and effectively no tooling above the endpoint. | 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 ### Platform against primitive Brevo Brevo is a full platform: campaigns, automation, a contact database, forms, SMS and a transactional API at the edge of it. For a small company that wants one European supplier for everything it sends, that breadth is the reason to be here, and the transactional API is a component of a marketing product rather than the point of it. Scaleway Transactional Email Scaleway Transactional Email is a send call and a console. There is no campaign builder, no contact storage, no automation and no template design surface worth the name. It is the European equivalent of raw cloud sending, priced accordingly, and everything a person would want to click on is something you will build. ### What European actually means in each case Brevo A European company with European infrastructure and a data protection posture built for that market, which is what most procurement questionnaires are asking about. The detail worth checking against your specific obligation is the subprocessor list, because a platform this broad integrates with many services and the edges of it are where non-European processing tends to appear. Scaleway Transactional Email A European cloud provider running the service in its own regions, which is about as unambiguous as this gets — the sending infrastructure belongs to the same company as the data centre. For an organisation whose requirement is written as no American cloud anywhere in the path, this is a much shorter conversation than any platform answer can be. ### How the price is counted Brevo By send volume rather than by contacts stored, which is friendlier than the contact-priced marketing platforms and means a large dormant list does not sit on the invoice. The tier you need is usually not the headline one, because automation and removing the vendor's own branding both sit a step up. Scaleway Transactional Email Per thousand messages with no monthly platform fee, and a higher plan that bundles volume with a dedicated address. It is close to raw cloud sending economics and it is the cheapest credible European option for anyone sending a meaningful volume, provided the absent tooling really is absent from your requirements. ### Reputation and isolation Brevo A shared pool serving a very large number of small senders, including a great many with marketing lists of uneven quality. Public reports on Brevo deliverability are mixed for exactly that reason, and the mitigations available to you are the ordinary ones: authenticate properly, keep your list clean, and separate transactional from campaign traffic by subdomain. Scaleway Transactional Email Also shared by default, with a dedicated address available on the higher plan, which is a straightforward path to isolation that the platform side does not match as cleanly. Fewer senders overall and a more technical customer base tend to make for a quieter pool, though there is no published record to check that against. ### Consent, unsubscribes and the compliance surface Brevo Brevo ships the machinery a European marketing programme needs: consent capture, preference handling, unsubscribe management and audit-friendly records. If your residency requirement came from the same conversation as your consent requirement, having both handled by one vendor is a real reduction in work. Scaleway Transactional Email None of that exists. Unsubscribe links, consent records and preference management are entirely yours to build and store, which is fine for purely transactional sending where none of it applies, and a significant amount of work the moment anything you send is marketing. ### Tooling above the endpoint Brevo A complete interface that non-engineers use daily, which is the product. The trade is the one every platform makes: your templates, segments and automations live in their system rather than in your repository, and exporting the shape of that logic is not something any platform makes easy. Scaleway Transactional Email A console for configuration and basic visibility, and that is all. Everything else — templates, previews, searchable history, analytics, suppression beyond the basics — is yours. If you are already building an internal tool this is a virtue, because there is nothing to fight with. If you expected a product, it is a surprise. ### Beyond email Brevo SMS, chat and a light customer relationship manager are part of the same account, which matters more in Europe than the feature list suggests, because consolidating suppliers is often part of the same procurement decision that created the residency requirement in the first place. Scaleway Transactional Email Email only, sitting inside a broader cloud that has compute, storage and databases. Different kind of consolidation: one supplier for your infrastructure rather than one supplier for your messaging, and which of those is the useful consolidation depends on who in your organisation asked the question. ### What happens as volume grows Brevo The plan ladder is designed for marketing volumes, and a transactional workload with high message counts and low contact counts sits slightly awkwardly on it. Model your actual shape against the tiers rather than trusting the headline, because the fit is better for a company sending campaigns than for one sending receipts. Scaleway Transactional Email The economics improve with scale in the ordinary metered way, which is the main structural argument for a primitive over a platform. What does not improve is the tooling, so the operational cost of the missing features grows alongside the volume, and eventually somebody is maintaining an internal email console nobody planned to own. ## Pros and cons, side by side ### Brevo Strengths - Consent capture, preference handling and unsubscribe machinery arrive built, which is most of what a lawful European marketing programme actually consists of. - Somebody who does not write code can operate the whole thing daily, which for a great many organisations is the requirement rather than a convenience. - Text messaging and a small customer database remove another supplier from a procurement list that was already the slow part of the project. - Volume rather than stored contacts is what the meter counts, so an audience you inherited and rarely write to accrues no monthly rent. Trade-offs - The subprocessor list is where a broad platform's European story frays, because breadth means integrations and integrations are where processing wanders across a border. - There is no clean route to an isolated sending address, so a sender who outgrows a shared pool finds nothing on the price list to buy. - Templates, segments and automations live in the supplier's system, and the shape of that logic is not something any platform makes portable. - The plan ladder was drawn for campaign volumes, and a workload of many messages against few contacts sits awkwardly across it. ### Scaleway Transactional Email Strengths - The sending infrastructure and the data centre belong to the same European company, which is the shortest answer available to a sovereignty requirement. - An isolated sending address is a step on the published plan ladder rather than an enterprise negotiation, which is unusual at this end of the market. - There is nothing above the send call to argue with, which is exactly right for a team that was going to build internal tooling anyway. - It sits inside a cloud that also has compute, storage and databases, so the supplier relationship may already exist and already be approved. Trade-offs - Consent records, preference pages and unsubscribe handling do not exist, and each one is yours to build and then to keep running indefinitely. - There is no template surface, no preview across clients and no searchable history, so the first support question arrives with no screen that answers it. - The console covers configuration, which means somebody in your company ends up owning an internal email tool nobody planned to write. - Nothing about the product improves as your volume grows, so the operational cost of the absent pieces rises alongside the traffic. ## Pick in thirty seconds ### Choose Brevo if - You need campaigns, automation and consent handling as well as transactional sending, from a single European supplier. - Non-engineers will use the product daily and the interface is therefore part of the requirement. - SMS or a light customer database on the same account removes another supplier from your procurement list. - Your sending is mostly marketing, where the compliance tooling is worth considerably more than the per-message rate. ### Choose Scaleway Transactional Email if - The requirement is precisely that no American cloud sits anywhere in the sending path, and you want the shortest possible answer to it. - You send transactional mail only, so consent machinery and campaign tooling are features you would never open. - You are already building your own internal tooling and want a plain endpoint underneath it rather than a platform to work around. - Volume is high enough that metered pricing without a platform fee is a material difference. ## 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. 1. Obtain the actual wording of the obligation before shortlisting anything, because three different requirements get described with the same phrase. Storage location is answered by a region. Corporate nationality — who could be compelled to hand data over — is answered by ownership and is unaffected by where a server sits. A chain-of-subprocessors requirement is answered by neither and needs a list. Get the sentence from whoever wrote it, decide which of the three you are holding, and only then look at suppliers, because the three readings produce three different shortlists. 2. Map each candidate's subprocessor list against that sentence, properly, rather than reading the marketing page. A platform is broad because it integrates, and integrations are precisely where processing outside your intended jurisdiction turns up: a deliverability service, an analytics dependency, a support tool whose staff can see message content. A bare endpoint from a cloud provider has a much shorter list for the uninteresting reason that it does much less. Neither fact is a verdict. The list is the evidence, and somebody has to read both of them. 3. Write down everything you will build to replace a console, then find the person who will still own it in two years. A template surface with previews, a searchable history of what was sent, an unsubscribe endpoint, a bounce and complaint handler, and suppression beyond the supplier's minimum are each a few days of work and together are a product. The days are not the risk. The risk is that nothing on that list ever gets a maintainer, so it rots quietly until the first time somebody urgently needs to know what a customer received. 4. Build the opt-out before the first campaign rather than after the first complaint, because on the primitive side none of it exists. That means an unsubscribe header mailbox providers will honour, a landing page that works without a login, a stored record of who opted out and when, and a check in your own sending path that consults it. For purely transactional traffic none of this applies and the primitive is genuinely simpler. The moment one message counts as marketing, this list becomes the project and the send call becomes the easy part. 5. Decide now whether an isolated sending address is part of the requirement, because the two sides offer very different routes to one. On the primitive it is a step on the published plan ladder, which is unusually accessible. On the platform there is no clean path at all, so a sender who grows past the point where a shared pool is comfortable has nothing to buy and has to change supplier instead. That is the one ceiling on this page which arrives with no warning, and it arrives as a delivery problem rather than as a larger bill. 6. Plan the DNS estate in both directions, including its removal. Both sides need authentication records, and a platform additionally wants a tracking hostname and a custom return path, which means records pointing at a supplier you may later leave. Those outlive the account: a dangling hostname aimed at a service nobody pays for any more is a small security problem and a permanent source of confusion. Record each entry as you create it, with an owner beside it, so the teardown is a checklist rather than an archaeology exercise. 7. Choose where your event history will live on the day you integrate, not after the first dispute. A primitive hands you a webhook and a short window of visibility, which is honest and is not somewhere to answer a question about four months ago. If you will ever need to show that a message was accepted, or to explain a pattern of bounces to somebody who is annoyed, those events have to be landing in a store you control from the very first send. Retrofitting the pipeline is easy; retrofitting the four months you did not keep is impossible. 8. Find out who in your organisation actually answers a security questionnaire, and put both suppliers' documentation in front of them before you commit. A cloud provider produces an infrastructure compliance pack written for an auditor. A messaging platform produces a data protection page written for a customer. Those are different documents at different depths, and the distance between what your reviewer expects and what the supplier publishes is where an approved project stalls for a quarter. Finding the shape of that gap is a one-hour conversation worth having first. ## 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. 1. What does our obligation actually say — where the data sits, who owns the company holding it, or which subprocessors touch it? 2. Has anybody read both subprocessor lists end to end, and which entries fall outside the jurisdiction we care about? 3. Which console features are we taking for granted that we would be building ourselves, and who maintains them in two years? 4. Who writes the unsubscribe page, stores the opt-out record, and checks it before each send goes out? 5. If our shared pool becomes uncomfortable, is there an isolated sending address to buy, or only another migration? 6. Which DNS records would point at this supplier, who owns them, and what removes them on the day we leave? 7. Where will delivery events be stored from day one, and could we answer a question about a message sent four months ago? ## A third shape of answer If the constraint driving this page is residency rather than features, it is worth noticing that the constraint is about where infrastructure runs and not about who writes the software on top of it. Sending through a cloud account you own in a European region satisfies the same requirement while leaving you free to choose tooling on its merits, and that is a third shape neither column here describes. Wraps is one way to do it, and the honest caveats are specific: you need an AWS account and SES production access, an approval on AWS's schedule rather than ours, our SDKs are TypeScript and Python only, we are not SOC 2 certified, and while sending and delivery events stay inside your own AWS region, contacts, templates and workflow state live in our database — which is a question you would need to put to your own data protection assessment rather than take on our word. Wraps publishes this page. We are not one of the two vendors being compared here, and this note is on it because the tension above is one owning the AWS account actually addresses — not because it is on every page. ## Common questions ### Does EU hosting satisfy a data residency requirement on its own? It depends entirely on how the requirement is written, and this is where evaluations go wrong. Some obligations concern where personal data is stored, which EU hosting answers directly. Others concern who can be compelled to access it, which turns on corporate ownership rather than server location, and a European data centre operated by an American company may not satisfy that reading. Get the actual wording before shortlisting, because the two readings produce different shortlists. ### Can I send marketing email through a transactional-only endpoint? Technically yes, since it is a send call and it does not inspect your intent. Practically it is a poor idea, because you would be building consent records, unsubscribe handling and preference management yourself, and because mixing campaign traffic into the same sending identity as your receipts is the classic way to damage transactional delivery. If you do it, use a separate subdomain and treat the compliance work as a real project. ### Is a smaller European provider worse for deliverability? Not necessarily, and the variables are different from the ones people assume. Smaller pools have fewer senders to be dragged down by, which helps, and less accumulated goodwill with the large mailbox providers, which hurts. What matters far more is your own authentication, your list quality and whether you separate traffic types. Test with seed addresses at the major providers before committing, rather than reasoning about it from company size. ### What do I lose by choosing the primitive? Everything that is not the send call: a template editor with previews, searchable delivery history, analytics, suppression management beyond the basics, and any interface a non-engineer could use. Each is a few days of work and together they are a product somebody has to own indefinitely. That is a reasonable trade if you were building internal tooling anyway, and a bad one if you assumed the vendor would cover it. ### How do I keep the option of changing my mind? Send from your own domain, keep your own copy of the suppression list, and keep templates in your repository rather than only in a vendor's editor. Those three habits cost very little while you are happy and they are what make a future migration a code change rather than an archaeology project. They also protect you against the more common outcome, which is not that you leave but that you add a second provider for one traffic class. ### Can I get an isolated sending address on either of these? On one of them it is a published plan step, and on the other there is no clean route to one, which is an unusual inversion of what the prices would lead you to expect. The cheaper, barer product treats an address of your own as a normal thing a growing sender buys. The broader platform expects you to live in its shared pool, and the pool is very large and contains a great many small senders whose list hygiene is unknowable to you. That matters less than people think at low volume, where a dedicated address is actually worse — there is not enough traffic to hold a reputation warm, and a quiet address looks suspicious. It starts to matter above the point where your own sending is steady and significant enough to stand on its own, and the awkward part is that the transition is not signalled by an invoice. You find out because delivery gets worse for reasons you cannot trace to anything you did. If you can already see that point coming, let the availability of isolation be part of the decision now rather than the trigger for a migration later. ### What do I have to build to send a lawful marketing email from a bare endpoint? More than the send call, and the list is knowable in advance rather than discovered. You need a way to record consent with a timestamp and a source, because the question is never whether somebody is on the list but how they got there. You need an unsubscribe mechanism that works from the message itself, including the header that lets a mailbox provider offer a one-click opt-out, plus a landing page that functions for somebody who is not logged in. You need storage for the opt-outs and a check in the sending path that consults it every time, including from the background job somebody writes later. You need to handle bounces and complaints arriving on a webhook and to act on them rather than merely log them. And you need a record of what was sent to whom, because a regulator's question and a customer's question have the same shape. None of these is hard. Together they are a small internal product, and the honest framing is that choosing a primitive means choosing to own it. ### Who answers a procurement questionnaire about subprocessors? Somebody at your company, using documents the supplier publishes — which is why it is worth looking at those documents before you are under time pressure. A cloud provider tends to publish an infrastructure-shaped compliance pack: certifications, audit scope, a list of the regions a service runs in. A messaging platform tends to publish a data protection page aimed at a customer rather than an auditor, plus a subprocessor list that changes as its integrations do. Reviewers find different things missing from each. The pattern worth avoiding is a project that is technically finished and commercially approved and then sits for a quarter while somebody chases a document that was never going to exist in the form requested. Show your reviewer both suppliers' published material early, ask what they would still need, and get that question to the vendor while you are still a prospect rather than a customer. ### Can I use the platform for campaigns and the endpoint for receipts? Yes, and for a European company with both kinds of traffic it is often the right answer rather than a compromise. Marketing mail wants consent machinery, a template surface and somebody non-technical operating it; transactional mail wants a cheap, plain, reliable send call and nothing else. Splitting them also gives you the separation of sending reputations that you should want anyway, because a campaign to a stale list should not be able to degrade the delivery of a password reset. Two things to settle before you do it. First, which system holds the authoritative record of who opted out, because two systems each with an opinion is how somebody unsubscribes from a newsletter and stops receiving invoices. Second, who can answer what a given customer has been sent, given that the answer now lives in two places — usually solved by streaming both sides' events into one store of your own. Neither is difficult, and both are much easier to decide now than to reconstruct in eighteen months.