We've released PG Relay Notifier, a PostgreSQL extension that turns database events into durable, replayable email — with SMTP, Microsoft 365, and webhook support today, and SMS, Teams, Slack, Jira and ServiceNow on the roadmap. It also gives Oracle migrations a proper UTL_MAIL replacement, no C compiler required.
If you've ever migrated an Oracle system to PostgreSQL, you've hit this one: the application, or a trigger, or a stored procedure, needs to send an email. Maybe it's an order confirmation. Maybe it's an alert that a batch job failed. Maybe it's a PL/SQL package that's been quietly calling `UTL_MAIL.SEND` for the last decade and nobody wants to touch it.
In Oracle, that was built in. In PostgreSQL, it isn't — and the workarounds people reach for tend to cause more problems than they solve. A function that opens an SMTP connection directly from inside a transaction will happily hang your transaction if the mail server is slow. If the transaction rolls back after the email's already gone out, your customer gets a confirmation for an order that never actually completed. If you're running multiple write nodes, "which node sends the email" becomes its own little design problem. And if the mail server is briefly unavailable, you generally just... lose the message.
None of that is a PostgreSQL problem specifically — it's what happens any time you mix "talk to something outside the database" with "inside a database transaction." We wanted a proper fix, not a workaround, so we built one.
PG Relay Notifier is a PostgreSQL extension that lets your database code — application code, triggers, stored procedures — hand off a message for delivery, and then get on with its life. You write the notification (recipients, subject, body, attachments) into a table using a straightforward function call, your transaction commits, and delivery happens afterwards, outside your transaction, handled by a separate process that's built for exactly this job.
It's not a mail client bolted onto PostgreSQL. It's built on top of pg_relay, our durable job-queue extension, which is what gives it the properties that actually matter in production:
In plain terms: your database says "this needs to go out," commits, and moves on — and something durable and resilient makes sure it actually happens, with a full record of what was sent, when, and whether it worked.
Version 1.0 sends real email, and it does it several ways, so you can use whatever your organisation already has:
And email is just the start. The underlying design isn't "an email extension" — it's a general-purpose way of turning a row of data into an outbound message on whatever platform you need. SMS, Microsoft Teams, Slack, Jira, and ServiceNow are all on the roadmap. If you've got data sitting in PostgreSQL that needs to become a message, a ticket, or a notification somewhere else, this is the pattern we think you should be using — today for email, and soon for a lot more.
Not every notification should go out the same way. An order confirmation might go through your transactional email provider. An internal alert to the ops team might go through a shared mailbox in Microsoft 365. A partner notification might need a different sending domain entirely, with an attachment (an invoice PDF, a report) as well.
PG Relay Notifier handles this with profiles — named, reusable configurations that bundle up a transport, its connection details, and sensible defaults like sender address and reply-to. Your code just says "use this profile," or nothing at all and takes the sensible default, and the extension handles the rest, attachments included. Add a new profile for a new use case without touching a single line of application code. It's the difference between "email is hardcoded into this one function" and "email is a service the rest of the database can just use."
If you've come to PostgreSQL from Oracle, UTL_MAIL.SEND is a familiar name — and it's usually one of the more annoying things to replace, because so much existing PL/SQL just calls it and expects it to work.
There's an existing option in the PostgreSQL world, orafce_mail's UTL_MAIL compatibility layer — but it's implemented in C, which means it has to be compiled against your exact PostgreSQL version, and that's a real obstacle on a lot of managed and cloud database platforms where you simply can't install a C extension, and sometimes a genuine security review headache even where you can.
Our UTL_MAIL compatibility layer sits on top of PG Relay Notifier and is pure SQL and PL/pgSQL — no C compiler, no C code, nothing to build. It implements UTL_MAIL.SEND and the attachment variants with the same signatures your existing PL/SQL is already calling, so migrated code keeps working with little to no change. But because it's sitting on top of PG Relay Notifier rather than trying to fire an email off inline the way the original Oracle package (and orafce's version of it) does, you also get everything described above for free: it's durable, it's out of your transaction, it retries properly, and every send is logged and traceable. That's a meaningfully better outcome than the Oracle original ever provided, not just a like-for-like replacement.
It's also a better outcome than the Python-based UTL_MAIL replacement we published back in May 2026 (Sending Email from PostgreSQL After an Oracle Migration). That approach worked, and there are migrations running it successfully — but it depended on an external Python process sitting alongside the database, which is one more moving part to deploy, monitor, and keep patched. Whilst the Python version was built specifically to get email working, this one gives you every send destination described above — SMTP, Microsoft 365, webhook providers, and everything coming after — through the exact same migrated code path. Same familiar Oracle-shaped function calls, considerably more capability behind them.
PG Relay Notifier isn't a one-off. It's the latest in a family of extensions we're building on top of pg_relay, our durable queueing engine for PostgreSQL, because we think "reliably do something outside the database in response to something that happened inside it" is a pattern worth solving properly once rather than reinventing per project.
Building and releasing extensions like these matters to us beyond the tools themselves. Every one we build and put into the community makes us better at PostgreSQL — not just at the DBA layer of "keep the database up," but at the development layer of "how do you actually build reliable systems on top of it" and the tuning layer of "how do you make it fast under real load." That's the same depth of knowledge we bring when we're migrating a client's Oracle database — and everything built on top of it — across to PostgreSQL. It's a genuinely compatible, extremely capable alternative to Oracle, and for most organisations we work with, the return on investment is not a close call. The more of PostgreSQL's ecosystem we build, contribute to, and understand from the inside, the better we get at making that move smooth for the next client.
PG Relay Notifier is available now, requires pg_relay 1.1 or later, and installs in a few minutes on a standard PostgreSQL instance — with a documented path for managed cloud platforms (AWS RDS, Azure, Google Cloud SQL) where CREATE EXTENSION isn't available for third-party extensions. Full documentation, including the UTL_MAIL compatibility layer, is available in the project docs.
If you're migrating from Oracle and UTL_MAIL is on your list of things to sort out, or you've simply never had a proper, reliable way to send notifications out of PostgreSQL, get in touch — we'd like to help.
Full documentation: https://pg-relay-notifier.pebbleit.com.au/latest/
Gitlab Repository: https://gitlab.com/pebble-it/pg_relay_notifier
