Tigris beat Amazon S3 on uploads in one test. Downloads told a different story

Dropbox knows how to store files. Its planned Tigris acquisition is a bet on developer relationships, while…

Tigris beat Amazon S3 on uploads in one test. Downloads told a different story

The short version

  • Dropbox’s planned $350 million Tigris acquisition targets an established developer storage business, not merely additional storage capacity.
  • Dropbox says its AI experience reached more than 70,000 teams; included-credit usage does not establish sustained adoption.
  • DBX Agent Cloud’s S3 compatibility supports evaluation, but developers still need workload tests, published terms and an exit rehearsal.

Dropbox can store the bytes. Tigris brings the buyers.

Dropbox knows how to store files. The Tigris deal interests me for what more storage can’t buy: developers who already trust it with their applications.

Bar chart comparing current figures against their baselines: Mistral Large 4 score on DeepFinance’s… 22 % versus 58 %, Share of cloud-provider mentions naming… 1 % versus 98 %, STACKIT's share of European-provider… 55 % versus 16 %, European providers' estimated share of… 15 % versus 70 %.

The price is about $350 million in cash, subject to adjustments and closing conditions, versus the $230 million Crunchbase News puts on HelloSign, Dropbox’s previous largest disclosed acquisition. That’s a substantial bet on a different customer from someone sharing a project folder.

Dropbox wants AI-generated work back in its collaboration product; DBX Agent Cloud would sell infrastructure to AI developers. Separate buying decisions. I’d happily trial an assistant on a project document while refusing to move my application’s storage until somebody shows me the bill.

My model can change. My working files shouldn’t have to.

The folder named “final” usually contains evidence otherwise. Dropbox’s proposed advantage starts there: the project context and reviewers already exist. I haven’t tested the experience; I’m assessing the workflow Dropbox describes.

According to the company’s engineering account, I submit a request through Dropbox; a trusted host sends it to an agent in an isolated workspace with installed software. Dropbox identifies relevant content. Broad requests require plan approval before the agent can request permission to change files. External permission checks govern access: the workspace doesn’t decide its own authority. Structured activity updates show its work; version history supports review and undo for supported changes. I can inspect the result without reconstructing the task from a chat transcript and a mysterious attachment.

Fernando Alvarez framed the trust requirement this way:

AI creates lasting value only when enterprises can trust it within their operations.

For supported external tools, Dropbox names connections with ChatGPT, Claude and Muse: work with existing content without repeated uploads, then return the results to Dropbox. Convenient. But I still want to know where processing happens. A connection reveals little about my data’s full route.

Running an agent worker on my own server should settle that, right? DataStudios and Shubham Sharma’s reviews of Mistral’s agents serve mode describe a distinction: the worker runs on customer infrastructure, but sessions remain stored with Mistral. A fully customer-hosted Studio deployment is a separate arrangement. For me, worker location isn’t a privacy guarantee without the rest of the data-flow diagram.

Dropbox also says customers can switch supported models within a session, keeping their working context. That saves me rebuilding the project brief in another chat window, though the announcement promises neither identical results nor identical costs across models.

I’m watching what happens after the free credits

Dropbox says the experience reached more than 70,000 teams in its initial rollout, focused on eligible Standard and Advanced teams in the US, UK and Australia, starting in English. That doesn’t mean every paid account has access or every recipient has used the AI.

The earnings call offers a narrower signal: more than 20% of recipient teams had started using their included AI credits. I count that as first use. Without usage intensity, one curious employee and a useful weekly team process look identical.

The habit I care about starts when a colleague opens the output. An external AI tool produces a draft; a supported connection returns it to Dropbox. Someone checks it against the original brief in the same project folder, revises it, shares it and leaves a usable version. Repeat that, and Dropbox stays involved even when another company supplies the model. Each completed task gives the team another reason to keep project material there. An unopened upload has less business value, however impressive the earnings-call chart.

Management reported more than two million weekly uploads from AI tools, versus more than 600,000 per week in September. Those are upload events, not unique users or paid adoption. The evidence doesn’t isolate the new rollout’s contribution to growth.

Dropbox product chief Ashraf Alkarmi captured the ambition on the earnings call:

More agents, better Dropbox.

I like the commercial logic. But included credits encourage experimentation, which can stop when novelty fades or credits run out. Do those teams return without another promotional nudge? The supplied disclosures leave the eligible-team denominator and usage intensity unknown, with no independently measured retention or revenue improvement.

Gualtiero Bazzana described the broader industrial AI challenge:

Most industrial AI projects still stall at the pilot stage.

A closed cream project folder with a button-and-string fastening lies among orange, violet and cream confetti in hard sunlight.

Two buying decisions belong on the whiteboard: a team testing AI actions on existing Dropbox files, and a developer evaluating standalone application storage. The workplace rollout is underway; DBX Agent Cloud’s pricing and general availability date remain unpublished.

Production customers are expensive to build from scratch

I initially gave Dropbox’s storage experience too much credit. Of course it knows how to store files. Selling developer infrastructure means earning relationships an internal storage operation never needs.

Dropbox says Tigris brings a commercial product running in production, an experienced team and established developer relationships. Eric Webster made that case in the acquisition coverage. I find that more convincing than Dropbox needing another place to hold bytes.

An internal infrastructure team designs around its colleagues’ application. A commercial provider must expose behavior outside developers can understand and trust, inside products whose assumptions it doesn’t control. When something fails, support becomes part of the product. Repeated use and feedback teach the provider which promises to protect. Buying Tigris could shorten that learning because people already depend on it. Dropbox must preserve those relationships through an acquisition, when familiar support contacts and product priorities can become somebody’s integration spreadsheet.

“We could build that ourselves” always makes me wary. Usually, yes. The interesting questions come after the demo, when somebody else’s customer finds a failure mode your application never encountered.

Dropbox’s operating experience gives it a credible basis for a storage business. Tigris could gain resources it would take longer to build independently. I wouldn’t dismiss that just because acquisitions turn simple product decisions into recurring meetings.

But the supplied disclosures lack the revenue breakdown and customer-concentration data I need to value those developer relationships. The price tells me what Dropbox agreed to pay, not whether those relationships will survive integration or grow afterward.

The agreement still has closing conditions. Dropbox’s filing also flags losing key personnel or failing to realize expected benefits. My first check after closing: are the people who earned developers’ trust still there?

There’s a product boundary, too. Tigris describes one storage endpoint across compute environments, with filesystem access and content processing planned later. Dropbox hasn’t explained the technology integration, and the supplied sources give no delivery dates for those capabilities.

I want an exit rehearsal before a migration

S3 compatibility earns DBX Agent Cloud an evaluation. Dropbox says developers can use familiar tools and supported applications built for Amazon S3 with its standalone storage offering. That makes trials easier than rewriting code before discovering whether a service fits.

I start with my application’s storage calls. Familiar clients mean less connection code to reconsider, but I must still check support for the operations my workload needs. Then failure testing: a successful upload says little about a bad afternoon. I measure latency where my compute runs, rather than borrowing somebody else’s benchmark. Commercial terms determine whether growing traffic stays economical. Finally, I export representative data and check the moving cost. Compatibility starts the evaluation; the application and contract decide whether I finish it.

The available performance comparison warns against headline shopping. ComputeSDK’s November 6 test measured median uploads of a 10 MB object at about 390 milliseconds on Tigris versus about 550 milliseconds on AWS S3. Tigris won that upload workload.

Downloads reversed it: about 170 milliseconds for Tigris versus about 130 milliseconds for S3. Which operation keeps my application waiting? That’s my comparison.

The supplied excerpt specifies neither hardware nor test location, and says nothing about other regions or object sizes. These are Tigris-versus-S3 measurements under one reported workload, not a DBX Agent Cloud performance promise.

I wouldn’t transplant commercial terms between product announcements, either. Tigris’s existing-customer assurances belong in their stated context. StorageReview’s November 8 report says DBX Agent Cloud had no published pricing, egress terms or availability date. Until those arrive, I can prepare a test, not a credible migration bill.

Here I make the salesperson mildly uncomfortable. Show me how pricing can change. Show me the support commitment for the failure I tested. Then let me move the test data to another provider and reconcile the invoice against the contract.

That exit rehearsal comes before production migration, while I still have an unsigned customer’s leverage. The onboarding demo gets a meeting. The exit invoice gets my signature.

Frequently asked questions

Has Dropbox completed its acquisition of Tigris?

Dropbox announced a planned acquisition of Tigris for about $350 million in cash, subject to adjustments and closing conditions. The agreement is not a completed purchase. Dropbox says Tigris brings a production storage product, an experienced team and established developer relationships, but retaining personnel and realizing expected benefits remain risks.

Does DBX Agent Cloud’s S3 compatibility make migration straightforward?

DBX Agent Cloud’s announced S3 compatibility supports evaluation with familiar tools and supported applications built for Amazon S3. It does not establish workload suitability, performance or migration economics. Developers still need to test required operations, failures, latency and data exports. The cited reporting says pricing, egress terms and availability remain unpublished.

How does Dropbox control what its AI agents can change?

According to Dropbox’s engineering account, broad requests require plan approval before an agent can request permission to change files. External permission checks govern access rather than the workspace itself. Structured activity updates show the agent’s work, while version history supports review and undo for supported changes. Supported models can change within a session.

Sources

Related reading

Luca

Luca

Luca by the way is the personal blog of Los Angeles based entrepreneur Luca Capula. A true Italian who lives between Torino and LA.

More posts →