Observations from the benchmark:

| Concurrency | R2 p50 | R2 p95 | R2 OK | Railway p50 | Railway p95 | Railway OK | Railway slowdown vs R2 |

| --- | --- | --- | --- | --- | --- | --- | --- |

| 1x | 20.1s | 20.1s | 1/1 | 20.6s | 20.6s | 1/1 | 1.0x |

| 10x | 18.8s | 33.8s | 10/10 | 29.3s | 35.4s | 10/10 | 1.6x |

| 25x | 17.4s | 24.1s | 25/25 | 57.8s | 72.6s | 25/25 | 3.3x |

| 50x | 18.3s | 24.4s | 50/50 | 115.6s | 149.3s | 50/50 | 6.3x |

| 100x | 20.9s | 25.3s | 100/100 | 142.2s | 203.3s | 70/100 | 6.8x |

At 100x concurrency, Cloudflare R2 stayed around 21s p50 and completed 100/100 calls. Railway Object Storage rose to 142s p50, 203s p95, and only completed 70/100 calls. The Railway failures were Vertex/Gemini URL fetch timeouts/deadlines while attempting to fetch the signed Railway Object Storage URL.

GitHub repo with harness, README, and raw output:

https://github.com/shahaayush1999/railway-tigris-vs-cf-r2

Context:

I ran into this while debugging import tasks in my application. Customers import data into their CRM during setup, and under high concurrency I was seeing failures and very long-running tasks. Everything on my side looked fine: local behavior was fine, the app logic was fine, and the issue only appeared when many imports were happening concurrently.

Looking through failure logs, I saw cases where Google/Gemini was not able to download files from object storage due to fetch timeouts. That pointed suspicion toward the object storage provider rather than my application. I moved away from Railway Object Storage to Cloudflare R2 for this reason, because customers were seeing high failure rates and excessive latency.

This is not tied to one current Railway service. I am no longer using Railway Object Storage in production, so there is no active service I can attach as the affected service. I have also created Railway Object Storage buckets at different times, including more than a month apart, and saw the same class of issue. I previously discussed this with Jake, who said Railway did not see provider-side issues internally. I rebuilt the benchmark later in a more formal repo, at my own cost, and the result still shows the same pattern, so this does not look transient.

Benchmark methodology:

The benchmark uploads the same PDF to both Railway Object Storage and Cloudflare R2. For each provider it creates signed S3-compatible GET URLs, then sends those URLs to Gemini as file inputs. Gemini fetches the file from the provider and does almost no model work: it is prompted to simply reply "Hi".

This is intentionally not a local download benchmark. I do not have, and do not want to rent, a fleet of servers with high-end network cards just to test object storage concurrency. Using Gemini URL inputs gives me a neutral external downloader and a practical proxy for many isolated remote workers. Increasing concurrency creates many independent Gemini requests, with downloads happening on Google's side rather than on my laptop. That avoids my local network, machine, and disk being the bottleneck.

I understand this is not a perfect benchmark. Gemini/Vertex adds some noise, especially at low concurrency. But at higher concurrency the trend is very clear: Railway Object Storage deteriorates heavily while R2 remains mostly flat. This causes real product issues: long-running imports, timeout failures, retries, and poor customer experience.

What I would like Railway to investigate:

• Please benchmark Railway Object Storage/Tigris under high concurrent downloads from outside Railway's network.
• Ideally test with a fleet of isolated download workers, strong network, and enough disk/CPU headroom that the client side is not the bottleneck.
• Please compare against a known external S3-compatible provider such as Cloudflare R2.
• Please specifically look at signed URL GET behavior and timeout/deadline failures under concurrency.
• I am not asking you to debug a specific app service; I am reporting a provider-level degradation pattern that I had to work around by migrating storage providers.