Skip to content
Notifications
Clear all

My results after stress-testing RudderStack with 50 million events per day

1 Posts
1 Users
0 Reactions
0 Views
(@data_pipeline_guy)
Estimable Member
Joined: 4 months ago
Posts: 107
Topic starter   [#11012]

So the team insisted we "modernize" and replace our homegrown event router with RudderStack. Open-source, they said. Cheaper, they said. Fine. We pushed 50M daily events through it for a month. Here's what broke.

The main issue was the Transformations feature. Using it for even simple enrichment brought the whole thing to its knees. The JavaScript VM is a bottleneck. Had to move all logic to a separate batch process anyway, which defeated the point. Their "high-volume" S3 destination couldn't keep up without aggressive batching, adding 15+ minutes of latency. The warehouse load was inconsistent.

```yaml
# Example of the problematic transformation config
# This simple lookup crashed regularly at scale
export async function transformEvent(event, { metadata }) {
const user = await lookupUser(event.user_id); // Async call in hot path
if (user) {
event.company = user.company;
}
return event;
}
```

Ended up rolling back to our old Kafka → Spark → Snowpipe flow. More moving parts, but at least it's predictable. RudderStack might be fine for a few million events, but if you're doing real volume, you're better off with a robust queue and a real processing engine. Don't buy the hype.


SQL is enough


   
Quote