new blog for parallel chunk uploads

src/lib/generated/github-stars.json

@@ -1,4 +1,4 @@
 {
-    "stars": 55973,
-    "fetchedAt": "2026-05-04T21:03:24.879Z"
-}
+  "stars": 55982,
+  "fetchedAt": "2026-05-05T10:41:28.857Z"
+}

src/routes/blog/post/faster-storage-uploads-parallel-chunks/+page.markdoc

@@ -0,0 +1,131 @@
+---
+layout: post
+title: "Up to 2x faster Appwrite Storage uploads with parallel chunks"
+description: Appwrite SDKs now upload Storage chunks in parallel on runtimes with native concurrency, tuned for real browsers and networks, often roughly 2x faster, with no API changes.
+date: 2026-05-05
+cover: /images/blog/faster-storage-uploads-parallel-chunks/cover.png
+timeToRead: 9
+author: eldad-fux
+category: announcement
+featured: false
+---
+
+Uploading large files to [Appwrite Storage](/docs/products/storage) should feel snappy on a good connection and **bearable on real-world networks**. Until now, SDKs typically sent file chunks **one after another**. That approach is simple and reliable, but it leaves performance on the table. Each chunk waits for the previous one, so you rarely saturate bandwidth or use the browser's ability to run several HTTP requests in parallel.
+
+We are releasing updated **Appwrite SDKs** that upload **multiple chunks at the same time**, with defaults tuned for **how browsers and HTTP clients actually behave**. In our benchmarks, uploads are often **about twice as fast** - and in many cases we see gains in the **roughly 100-200%** range depending on file size, latency, and network conditions.
+
+We are adding this behavior to **all Appwrite SDKs that run on platforms with native concurrency support** - environments where the runtime can keep **several HTTP requests in flight at once** (for example overlapping requests via **async I/O** in JavaScript, Python, and Dart, or **goroutines** and similar primitives in other server stacks). If a target environment **cannot** overlap network calls in a supported way, the SDK continues to upload chunks **sequentially**, which remains correct but does not unlock the same throughput.
+
+# Why sequential chunks cap your speed
+
+Chunked uploads exist so large files do not need to live entirely in memory and so failures can be retried at chunk granularity. The tradeoff is that **strictly sequential** chunking means **underused bandwidth** (the connection often sits idle while the client waits on the next chunk), **latency stacked in series** (every chunk pays its own round trip one after another), and **browser limits left unused** (browsers allow multiple connections per origin, but a single in-flight upload does not use that capacity).
+
+The server must accept chunks in a well-defined way and assemble a complete file safely. Making uploads parallel required **both** smarter clients **and** a backend that could handle **out-of-order** and **concurrent** chunk writes without corrupting metadata or final assembly.
+
+# What we shipped
+
+The same **establish-then-parallelize** pattern is implemented **everywhere the host runtime supports it**. Each SDK uses that language's native concurrency primitives so multiple chunk requests run together without blocking each other on the wire. The updated SDKs establish the upload - for example, by sending the **first chunk** in a controlled way to obtain an upload identifier - then upload **remaining chunks concurrently** up to a **fixed maximum parallelism**. We intentionally avoid "as many requests as possible," which can hurt performance or run into browser and server limits.
+
+For **JavaScript-family** SDKs (Web, Node, React Native), testing under throttling and more realistic network conditions pointed to a **concurrency of eight** as a practical sweet spot. Higher concurrency is not always better. Beyond a point you contend for connections, CPU, and memory without gaining throughput. Other languages pick limits that fit their **runtime defaults and HTTP stacks**. The goal is the same everywhere - use **native concurrency** where it exists, instead of bolting on fragile custom thread pools at the application layer.
+
+On the server, parallel uploads only work in production if the stack can accept chunks **in any order** (within the rules of the API), **assemble** the final file correctly when multiple workers are involved, and keep **metadata consistent** when several requests touch the same upload state at nearly the same time. We hardened the platform for exactly that. Chunk data can flow concurrently while **short, scoped critical sections** protect the small amount of state that must stay atomic - so you get **parallel throughput** without sacrificing **correctness** under load.
+
+All of this stays **fully inside the Appwrite SDK**. Your integration keeps the same Storage upload calls and patterns as today; chunking, concurrency, and ordering on the wire are implementation details you do not configure or branch on. **Update to the latest Appwrite SDK** for your language or runtime and you inherit the faster uploads without rewriting upload code.
+
+The examples below are the same **`createFile`** calls you use today. Point them at a large file, bump the SDK and server, and uploads get faster with **no extra parameters** for parallelism. Use the drop-down to switch between Web, Node.js, Python, and Flutter.
+
+{% multicode %}
+```client-web
+import { Client, Storage, ID } from 'appwrite';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>');
+
+const storage = new Storage(client);
+
+const uploaded = await storage.createFile({
+    bucketId: 'videos',
+    fileId: ID.unique(),
+    file: document.getElementById('uploader').files[0]
+});
+```
+```server-nodejs
+import { Client, Storage, ID } from 'node-appwrite';
+import { InputFile } from 'node-appwrite/file';
+
+const client = new Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>')
+    .setKey('<API_KEY>');
+
+const storage = new Storage(client);
+
+const uploaded = await storage.createFile({
+    bucketId: 'videos',
+    fileId: ID.unique(),
+    file: InputFile.fromPath('./large-video.mp4', 'large-video.mp4')
+});
+```
+```server-python
+from appwrite.client import Client
+from appwrite.services.storage import Storage
+from appwrite.id import ID
+from appwrite.input_file import InputFile
+
+client = Client()
+client.set_endpoint('https://<REGION>.cloud.appwrite.io/v1')
+client.set_project('<PROJECT_ID>')
+client.set_key('<API_KEY>')
+
+storage = Storage(client)
+
+uploaded = storage.create_file(
+    bucket_id='videos',
+    file_id=ID.unique(),
+    file=InputFile.from_path('./large-video.mp4'),
+)
+```
+```client-flutter
+import 'package:appwrite/appwrite.dart';
+
+final client = Client()
+    .setEndpoint('https://<REGION>.cloud.appwrite.io/v1')
+    .setProject('<PROJECT_ID>');
+
+final storage = Storage(client);
+
+final uploaded = await storage.createFile(
+    bucketId: 'videos',
+    fileId: ID.unique(),
+    file: InputFile.fromPath(
+        path: './large-video.mp4',
+        filename: 'large-video.mp4',
+    ),
+);
+```
+{% /multicode %}
+
+# Numbers that match "real internet," not just localhost
+
+Local benchmarks are misleading. Everything feels fast until you add **latency**, **loss**, and **variable bandwidth**. We focused on **throttled** and **staging-style** runs to approximate what your users see.
+
+One representative large-file case is a **~256 MB** upload that dropped from on the order of **two minutes** to under **a minute** with parallel chunks and tuned concurrency - **in the ballpark of 2x faster** in that scenario. Across different file sizes and setups, we repeatedly saw improvements in the **~100-200%** range relative to the older sequential behavior.
+
+Your mileage will vary with region, device, bucket location, and network. The consistent story is **materially faster uploads** without asking application developers to hand-roll concurrency.
+
+# What you need to do
+
+1. **Upgrade** your Appwrite SDKs to the latest release that includes parallel chunked uploads (see the changelog for your language). No API migration - same methods and flows as before.
+2. **Ensure your Appwrite instance** is on a release that includes the server-side support for concurrent and out-of-order chunk handling (self-hosters should upgrade the platform, not only the SDK).
+
+# Why this matters everywhere you upload
+
+Whether the uploader runs in a **browser**, on a **phone**, or in a **backend job**, the wins show up whenever the SDK can use the runtime's **native concurrency** to overlap chunk uploads. You do not need different strategies per platform beyond upgrading the SDK and server. The same Storage API keeps working, with smarter client-side scheduling.
+
+Faster uploads mean snappier dashboards, quicker backups, and less time staring at progress bars in mobile and web apps. By combining **parallel chunk uploads** in the SDKs with **realistic per-runtime concurrency limits** and a **server built for concurrent assembly**, we are delivering a clear step forward in performance - measured in **real-world conditions**, not only ideal lab networks.
+
+# More resources
+
+- [Appwrite Storage documentation](/docs/products/storage)
+- [The easiest way to add file uploads to your app](/blog/post/easiest-file-uploads)

src/routes/changelog/(entries)/2026-05-05.markdoc

@@ -0,0 +1,15 @@
+---
+layout: changelog
+title: "Up to 2x faster Appwrite Storage uploads with parallel chunks"
+description: Appwrite SDKs now upload Storage chunks in parallel on runtimes with native concurrency, often roughly 2x faster, with no API changes for developers.
+date: 2026-05-05
+cover: /images/blog/faster-storage-uploads-parallel-chunks/cover.png
+---
+
+Appwrite **SDKs** now upload **Storage** file chunks **in parallel** where the host runtime supports overlapping HTTP requests (for example Web, Node, React Native, Python, Dart, and other server SDKs). Chunking, concurrency limits, and ordering are handled **inside the client**; your **`createFile`** calls stay the same.
+
+Self-hosted projects should run an Appwrite release that supports **concurrent and out-of-order** chunk assembly on the server. After that, **upgrade the SDK** to the latest version for your platform to pick up the faster uploads automatically.
+
+{% arrow_link href="/blog/post/faster-storage-uploads-parallel-chunks" %}
+Read the announcement
+{% /arrow_link %}

src/routes/docs/apis/rest/+page.markdoc

@@ -151,9 +151,9 @@ Learn more in the [user impersonation docs](/docs/products/auth/impersonation).
 
 # Files {% #files %}
 
-Appwrite implements resumable, chunked uploads for files larger than 5MB. Chunked uploads send files in chunks of 5MB to reduce memory footprint and increase resilience when handling large files. [Appwrite SDKs](/docs/sdks) will automatically handle chunked uploads, but it is possible to implement this with the REST API directly.
+Appwrite implements resumable, chunked uploads for files larger than 5MB. Each chunk is up to **5MB**, which reduces memory footprint and increases resilience when handling large files. [Appwrite SDKs](/docs/sdks) split uploads, attach the headers below, and on runtimes with native concurrency they may also **send multiple chunk requests in parallel** for higher throughput, while your high-level upload code stays unchanged. You can still implement chunked uploads with the REST API directly.
 
-Upload endpoints in Appwrite, such as [Create File](/docs/references/cloud/client-web/storage#createFile) and [Create Deployment](/docs/references/cloud/server-nodejs/functions#createDeployment), are different from other endpoints. These endpoints take multipart form data instead of JSON data. To implement chunked uploads, you will need to implement the following headers. If you wish, this logic is already available in any of the [Appwrite SDKs](/docs/sdks).
+Upload endpoints in Appwrite, such as [Create File](/docs/references/cloud/client-web/storage#createFile) and [Create Deployment](/docs/references/cloud/server-nodejs/functions#createDeployment), are different from other endpoints. These endpoints take multipart form data instead of JSON data. To implement chunked uploads over REST, send **one HTTP request per chunk** using the headers in the tables below. The **first** request establishes the file; every later chunk must repeat the same file **id** in `X-Appwrite-ID` and set `Content-Range` to the byte span carried in that request. After the first response, you may **issue the remaining chunk requests sequentially or in parallel** (for example from a thread pool or async tasks), as long as each byte of the file is uploaded **exactly once** and each part stays within the maximum chunk size. For Storage-specific guidance (including SDK behavior), see [Upload and download](/docs/products/storage/upload-download#large-files).
 
 {% table %}
 

src/routes/docs/references/[version]/[platform]/[service]/descriptions/storage.md

@@ -1,5 +1,7 @@
 The Storage service allows you to manage your project files. Using the Storage service, you can upload, view, download, and query all your project files.
 
+Large files are uploaded in 5MB chunks. Appwrite SDKs handle chunking for you and, on runtimes with native concurrency, can upload multiple chunks in parallel for faster throughput without changing your `createFile`-style calls.
+
 Files are managed using buckets. Storage buckets are similar to Tables we have in our [Databases](/docs/products/databases) service. The difference is, buckets also provide more power to decide what kinds of files, what sizes you want to allow in that bucket, whether or not to encrypt the files, scan with antivirus and more.
 
 Using Appwrite permissions architecture, you can assign read or write access to each bucket or file in your project for either a specific user, team, user role, or even grant it with public access (`any`). You can learn more about [how Appwrite handles permissions and access control](/docs/advanced/platform/permissions).

src/routes/docs/tooling/command-line/buckets/+page.markdoc

@@ -95,7 +95,7 @@ appwrite storage [COMMAND] [OPTIONS]
 * Get a list of all the user files. You can use the query params to filter your results.
 ---
 * `create-file [options]`
-* Create a new file. Before using this route, you should create a new bucket resource using either a [server integration](https://appwrite.io/docs/server/storage#storageCreateBucket) API or directly from your Appwrite console. Larger files should be uploaded using multiple requests with the [content-range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) header to send a partial request with a maximum supported chunk of '5MB'. The 'content-range' header values should always be in bytes. When the first request is sent, the server will return the **File** object, and the subsequent part request must include the file's **id** in 'x-appwrite-id' header to allow the server to know that the partial upload is for the existing file and not for a new one. If you're creating a new file using one of the Appwrite SDKs, all the chunking logic will be managed by the SDK internally.
+* Create a new file. Before using this route, you should create a new bucket resource using either a [server integration](https://appwrite.io/docs/server/storage#storageCreateBucket) API or directly from your Appwrite console. Larger files should be uploaded using multiple requests with the [content-range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Range) header to send a partial request with a maximum supported chunk of '5MB'. The 'content-range' header values should always be in bytes. When the first request is sent, the server will return the **File** object, and the subsequent part request must include the file's **id** in 'x-appwrite-id' header to allow the server to know that the partial upload is for the existing file and not for a new one. If you're creating a new file using one of the Appwrite SDKs, all the chunking logic will be managed by the SDK internally, including sending multiple chunk requests in parallel when the runtime supports it.
 ---
 * `get-file [options]`          
 * Get a file by its unique ID. This endpoint response returns a JSON object with the file metadata.