How eToro Moved a 24/7 Trading Platform to the Cloud Without Losing a Millisecond

eToro isn’t a young company, and it isn’t a small one. With millions of customers trading around the clock — including a heavy volume of cryptocurrency, one of the most volatile asset classes there is — eToro’s infrastructure has to do something most applications never have to think about: turn a flood of orders that stack up overnight and over weekends into near-instant execution the moment markets open.

For nearly 20 years, that meant staying on-premise.

The On-Prem Problem

eToro’s trading platform runs on SQL Server, and SQL Server’s performance comes down to a simple equation: how many CPUs you have, how fast they run, and how well memory and disk can keep up. To hit the response times a trading platform requires, eToro ran on very large physical machines with all-flash storage, delivering sub-millisecond response times.

It worked. But it came with a cost that had nothing to do with the hardware bill.

“It doesn’t matter what SLA you have on your hardware,” says Yitzchak Wahnon, DBA Team Manager at eToro. “If something goes wrong, the engineer comes, a part is missing, and you wait two days to get everything back up.” No amount of on-prem redundancy could match the flexibility the cloud offered — the ability to scale, test, and recover without waiting on a truck.

The catch was that no cloud-native storage option could replicate the performance eToro already had on-prem — which is what eventually led the team to Silk, whose software-defined storage platform is purpose-built to deliver on-prem-class performance inside the public cloud.

Why the Obvious Cloud Option Wasn’t an Option

eToro’s database isn’t just large — it’s effectively a monolith, with all of the platform’s trading activity running through it. That meant any cloud storage solution had to deliver the same fast, high-IOPS, sub-millisecond performance eToro was already getting on-prem, or the migration wasn’t worth doing.

The team tested Azure’s native Elastic SAN (eSAN) option first. It didn’t come close. eToro was pushing roughly 140,000 IOPS, and nothing natively available in Azure could deliver that at the response times the platform needed. Without a way to move the database itself to the cloud, moving application services alone wouldn’t have moved the needle — the latency between an on-prem database and cloud-based services can run up to 20 milliseconds, and at eToro, milliseconds are money.

“If we can’t process the positions fast, then we can lose money,” Wahnon says. “It puts us at enormous risk, especially when the markets are highly volatile.”

Silk was ultimately the option that cleared that bar. By deploying a software layer on top of standard Azure infrastructure, Silk gave eToro’s SQL Server environment the sub-millisecond response times and high IOPS it needed — without eToro having to build or manage specialized hardware itself. That capability is what turned “move the database to the cloud” from a non-starter into a real possibility.

Performance wasn’t the only bar to clear. eToro also had to solve for resilience. In the cloud, VMs disappear, hosts fail and move, and things go wrong in ways that don’t happen on a pair of physical servers sitting in a data center. eToro’s standard was — and still is — no single point of failure, at every level: resource, availability zone, and region.

Testing It the Hard Way

eToro didn’t take Silk’s word for any of this. Before committing production systems, the team put Silk through a proof of concept that lasted more than six months — deliberately working through the kinds of Azure events that could have caused real problems, to see whether the system would actually hold up.

It did. And working closely with Silk’s team surfaced opportunities eToro wouldn’t have found on its own. One example: VM selection. eToro had been running on Azure’s M-series machines — powerful, but expensive. Silk flagged that Azure’s upcoming E-series would be a better fit once generally available, and eToro waited for the official release rather than risk production on a preview version. Once available, the E-series — paired with Silk’s storage layer — let eToro move TempDB off Azure’s costly ephemeral disk entirely, cutting a significant, recurring expense.

eToro rolled the migration out deliberately: storage first, then server by server, starting with lower-tier systems, gathering performance data, and working with Silk’s team to tune configuration along the way. “It’s not plug and play,” Wahnon says. “You can’t just connect it to the electricity and then the storage is there.” The result, in his words, was performance “probably better than expected” — consistently sub-millisecond, with uptime that has held up under real trading conditions, including a period of extreme crypto market volatility.

What Cloud Resilience Actually Looks Like in Production

The real test of a cloud architecture isn’t the demo — it’s what happens when Azure has a bad day. eToro built its systems around Always On availability groups on SQL Server 2022, with primaries protected by careful failover and secondaries kept in constant use for scaling reads. Underlying storage failures — a node replaced, a host issue in Azure — now trigger automatic recovery through Silk: eToro gets an automated email notification, a support case opens on Silk’s end without anyone lifting a finger, and once the issue resolves, the case closes with a summary confirming everything’s back in full working order. No downtime, no 2 a.m. phone calls.

Upgrades have followed the same trajectory. Early on, eToro’s team stayed hands-on during every Silk maintenance window, monitoring closely as Silk’s engineers worked. Today, upgrades run without eToro even connecting — eToro’s IT team grants Silk access, Silk’s team runs the entire upgrade, and eToro’s team runs a quick check afterward to confirm everything is healthy. For a platform where any I/O interruption has a direct cost, that shift — from hands-on vigilance to routine confirmation — reflects a level of trust that took years, not weeks, to build.

eToro’s architecture also plans explicitly around Azure’s own maintenance patterns. Silk’s platform subscribes to Azure’s early-warning signals for both planned and unplanned maintenance events, and eToro architects with availability sets so that the odds of losing multiple resources simultaneously are close to zero. Even in worst-case, no-warning scenarios, Silk is designed to recover automatically, in stride, without degrading the platform.

A Relationship That Didn’t End at Go-Live

Perhaps the most telling detail in eToro’s story isn’t a performance number — it’s who’s using the platform two and a half years later. eToro’s IT team, who work directly with Silk’s platform day to day, were initially skeptical about bringing on a storage supplier at all. Today, that same team — by Wahnon’s own account, not typically the easiest audience to win over — considers working with Silk’s engineers a genuinely positive part of the job.

That’s the throughline in eToro’s cloud journey: the technology mattered, but so did having a partner in Silk that was willing to sit in the architecture discussions, flag opportunities eToro didn’t know existed, and stay engaged well past the signing of a contract. For a platform where milliseconds translate directly into dollars, that ongoing collaboration with Silk — as much as any single technical benchmark — is what’s kept eToro’s trading infrastructure fast, resilient, and quietly out of the headlines.