3 ms·
The maximum size will increase to at least 1GB in the near future, enabled by our recent rewrite of the underlying storage layer. Perhaps we can push it further
by kentonv 3y ago
The maximum size will increase to at least 1GB in the near future, enabled by our recent rewrite of the underlying storage layer. Perhaps we can push it further, even, we'll see.
But yes, I think the next step is then some sort of sharding. Sharding by user would be an obvious approach for many apps. I think we should build a framework to help manage this, so apps would only need to provide some callbacks e.g. to compute shard key for a particular query.
Alternatively, apps that want full control will be able to use Durable Objects directly. We'll soon (in a few months, probably?) enable the new storage engine for all Durable Objects which means every object will have a private SQLite database.
(I'm the tech lead for Workers in general, and currently focused on this project in particular.)
- no_wizard 3y agodo you think you will have any API driven access to the data held in these services? IE, I don't per se want to have to use a worker to arbitrage between the Cloudflare platform and HTTP access to the data within Cloudflare systems. Much like R2 has an S3 compat API as well as a way to retrieve files outside of workers (IIRC) will this be true of all forms of storage on the platform? Sometimes it'd be nice to prime the cache with KV for example, without having to invoke a worker
- elithrar 3y ago> do you think you will have any API driven access to the data held in these services? IE, I don't per se want to have to use a worker to arbitrage between the Cloudflare platform and HTTP access to the data within Cloudflare systems. For D1, yes — on the roadmap is a native HTTP API. KV has a HTTP API as well, so you can write directly.
- tebbers 3y agoAwesome, thanks for the info! We are building more and more features on Cloudflare and absolutely love the whole experience, faultless.