momoGood Messaging, formerly Tatango, is a marketing automation platform for nonprofits. momoGood supports more than 3,200 nonprofits and organizations, with over $2.4 billion raised through the platform, funding that these organizations' missions depend on. Nonprofits use momoGood Messaging to send SMS campaigns to millions of donors at once, and in a high-volume month, momoGood Messaging sends around 200 million texts on their behalf.
That volume doesn't arrive evenly. It arrives in bursts: quiet for stretches, then all at once, when a natural disaster hits, a news story breaks, or a giving deadline approaches and a nonprofit needs to reach everyone who hasn't donated yet, often within minutes. Retargeting is critical to the business, and it only works if momoGood knows in near real time who already responded and who didn't. That makes the data behind each campaign – who got texted, who replied, who gave – both hard to keep up with and impossible to get wrong.
It relies on Artie to actually deliver the data to us as fast as humanly possible. The faster it delivers the data, the faster the test will run, catch it, and we'll be able to service our customers better.
When Matt Powers joined momoGood as CTO four years ago, the business was scaling faster than the data infrastructure underneath it. Today momoGood Messaging is an 85-person company with a 25-person engineering team, and Matt's organization is responsible for making sure bursty, high-volume replication holds up on the two days of the year when it matters most: Giving Tuesday, December 1, and New Year's Eve, December 31.
| Company Website | momogood.com/messaging |
| Switched from | AWS DMS |
| Switched | October 2024 |
| Use case | Postgres + MySQL → Redshift |
Before Artie: replication that couldn't keep up with the business
momoGood's transactional data lived in two databases, Postgres and MySQL, each replicated into the warehouse using AWS DMS and each needing its own tuning. Neither pipeline held up against the data traffic pattern: quiet for days, then a single nonprofit campaign pushing ten million rows through in an hour.
DMS was like sitting in the cockpit of a plane and not being a pilot. You have no idea what button does what and how it affects things and how it might help.
When traffic spiked, DMS would lag badly or stop replicating entirely. Restarts gave no signal about whether they'd helped, and outright failures meant data loss and a manual backfill, every time. Amazon's top support tier couldn't debug the outages: support engineers didn't understand momoGood's traffic, so the standard fix was to adjust a setting and wait to see if the problem resolved. But millions of messages can go out within minutes. By the time anyone knew whether the setting worked, the spike had passed, and the next answer from AWS was 24 hours away.
What was breaking
Reporting had never worked reliably at momoGood. By Matt's count, it had been broken for years. When replication lagged, sometimes for a full day, it broke three things nonprofits depend on: retargeting, reporting, and billing.
Nonprofits use momoGood Messaging to reach people who haven't donated yet, often within a narrow window after a specific event. When the warehouse fell behind, that donation window closed before the data caught up.
The team's workaround was manual: when the warehouse looked wrong, someone ran a custom query and sent the customer their numbers by hand. Fixing a data failure took days, every time. All told, data firefighting and cleanup ate about 80 hours of developer time a month. The manual fixes kept the business running, but they weren't sustainable. momoGood's revenue grew 500% in a single year, and the technical debt kept compounding underneath it.
The New Year's Eve that forced the issue
Then came the New Year's Eve before Artie: the platform's highest-traffic day of the year, and the day everything broke at once. Replication lag stretched past 24 hours. The warehouse was a full day behind, and the only place with fresh numbers was the production database itself. The team spent all of New Year's Day running custom reports by hand. On the days that mattered most, nonprofits needed to re-engage donors while they were still engaged, and batch replication meant the data arrived when the moment had already passed.
Then the invoices went out.
The numbers had to be rerun by hand, handed back to finance, and the affected invoices reissued: days of cleanup, like every data failure before it.
The post-holiday lull gave Matt his window. He had until the next New Year's Eve to make sure it never happened again.
Imagine what happens when you send out an invoice to a customer at the end of the month based on their sending data. But on New Year's Eve, you lag so bad that it doesn't correct itself for 24 hours. Now you have a billing problem to deal with because the invoices that just went out are wrong.
Alternatives considered
Matt had already ruled out most of the field. He'd used Stitch before, and it had the same failure modes as DMS. He knew the team behind Airbyte and knew their focus was breadth of integrations, not replication speed. He eliminated Fivetran without a pilot, not wanting to land momoGood in a support queue, the same problem he already had with AWS.
Building in-house was never seriously on the table.
Matt ran a pilot of Artie against live production traffic for about six weeks to see whether the latency held under momoGood's worst-case load.
If it's not core to your business, you should never be building it in-house, because you have to go and support it.
How a decision was made
Matt wasn't choosing between Artie and a strong alternative. He was choosing between Artie and the status quo. Matt says the deciding factor was how directly his questions got answered and how confident that made him feel about the architecture.
The rollout itself surprised him. He went in expecting hiccups from a fast-growing but small startup. Instead: “It was smoother than I definitely thought it was going to be.”
For me, as an engineer, being able to talk to another engineer about technical specs made me feel comfortable about the architecture. There was a level of confidence they had that put a level of confidence in me.
What changed after Artie
| Before: AWS DMS | After: Artie |
|---|---|
| Reporting lagged past 24 hours on peak days | Minute-level replication, even on momoGood's biggest sending days |
| 10M-row bursts broke replication without warning | 600–800M rows replicated in a peak month, on up to 200M messages sent |
| No visibility into whether a fix worked | Root cause and lag visible without guesswork |
| Manual backfills after data loss | No manual backfills for day-to-day operation |
| Billing errors, invoices reissued by hand | Billing accurate on the first invoice |
| Days to recover from each failure | Incidents rare enough the team forgets how to debug them |
Matt has built internal workflows on top of the data Artie delivers, including automated data quality monitoring. Roughly a thousand data quality tests run against the warehouse every ten minutes, and an AI agent triages every failure before a human looks at it: which customer is affected, how urgent it is, and what context matters. The entire loop is only as fast as the data arriving underneath it.
The reclaimed capacity went into a growing fleet of internal agents: one that turns company-wide dogfooding feedback in Slack into categorized, prioritized tickets; one that answers “how does the product work” questions from the codebase and docs, with a human approving each answer; and an intake agent, in progress, that classifies inbound feature requests and can hand small wins straight to a coding agent that opens a PR.
All of this starts with the data being able to be replicated very, very quickly.
The clearest sign came mid-interview, when Matt checked the previous day's volume: millions of messages had gone out. Before Artie, a day like that meant DMS alarms firing, error codes to decipher, lagging dashboards, and customer complaints. This time, the messages just went out. Nobody had to manage a thing.
About Artie: Artie is a real-time data replication solution for databases and data warehouses. Artie leverages change data capture (CDC) and stream processing to perform data syncs in a more efficient way, which enables sub-minute latency and helps optimize compute costs. With Artie, any company can set up streaming pipelines in minutes.
About momoGood Messaging: momoGood Messaging is a marketing automation platform for nonprofits, helping organizations raise donations through high-volume SMS campaigns. momoGood supports more than 3,200 nonprofits and organizations and has powered over $2.4 billion in fundraising. When nonprofits need to reach donors fast around moments like Giving Tuesday or a breaking news story, momoGood Messaging sends and tracks those messages at scale.