Get all the details on how Storj is doing what its CTO has called "the impossible," with a helping hand from CockroachDB.Watch the talk
It’s not easy for a startup to take on giants like the major cloud storage providers.
Yet, Storj is doing it. The company has built a globally distributed enterprise-ready object storage platform that’s S3 compatible – no small feat in and of itself. But perhaps more importantly, it actually outperforms S3 in several areas, achieving a goal that CTO Jacob Willoughby, who spoke at CockroachDB’s RoachFest 2023 conference, once called “impossible.”
The quick pitch for Storj is that it’s like AirBnB for data storage. “Most of the storage around the world is under-utilized,” Willioughby says. There are millions and millions of internet-connected storage drives all over the world, and most of them are less than half full. Storj uses that excess capacity and turns it into a cohesive storage layer, which in turn enables it to offer global cloud storage for 80-90% less cost than the big players, with a much smaller carbon footprint due to eliminating the need to build, maintain and cool new data centers to meet surging demand.
Storj encrypts the data and breaks files into small pieces before distributing them, ensuring security and also allowing for CDN-like global performance. And because only a fraction of the pieces are required to retrieve a file, Storj can deliver enterprise-grade availability and durability without the need to replicate and pay to store multiple copies..
Orchestrating a distributed data storage system this complex at scale requires a heavy reliance on metadata. Going into building the application, Storj knew that this would require a database that could offer:
Ultimately, Willoughby says, their decision also hinged on a few additional factors:
The Storj team considered a wide variety of databases, including traditional Postgres, sharded Postgres (Citus), NoSQL databases, Spanner, Yugabyte, TiDB, and CockroachDB. Of those, the only one that ticked all of their boxes was CockroachDB.
Storj has been a CockroachDB user for years, and the results speak for themselves. The company is now deploying CockroachDB across nine separate cloud regions – three in the US, three in Europe, and three in Asia. As of this fall, one of its larger CockroachDB clusters contained over five billion rows, and was handling an average of 5k read ops and 1.2k write ops per second, “with bursts, of course, much higher than that,” Willoughby says.
It is a testament to both the quality of Storj’s engineering team and the features of CockroachDB that Storj has realized massive growth in the years since adopting CockroachDB without experiencing a major “success disaster”. “We’ve delivered on the promise of horizontal scalability,” Willoughby says. “It’s really nice when you have those 10x events that just kind of sneak up on you as your company grows, and you don’t notice because all you did is [go] into your managed CockroachDB cluster and click scale up, and then you were fine.”
Willoughby also noted at RoachFest: “by the end of , we’ll have had another 2x or 3x load increase.” That kind of load increase isn’t a big deal for Storj’s operations team, he says, in part because their choice of CockroachDB’s managed service allows Storj to “focus on building and delivering our product, rather than managing and scaling a database.”
The end result? Willoughby shared a slide comparing performance downloading a 1GB file from AWS, Azure, and Storj. It shows that while AWS and Azure performed faster when downloading from location close to the cloud region where the data is located, as the distance increases the performance of the traditional cloud providers degrades, whereas Storj does not:
Learn more about how Storj works and how CockroachDB has helped them “do the impossible,” in the words of Jacob Willoughby:
Modernizing the data layer in your stack can be hugely beneficial. But it can also be difficult and, if approached in …Read more
When was the last time you carried cash? If you’re anything like alot of us, it has probably been awhile.
The whole …