So all DOs have 1GB of disk even if you aren't using the SQLite but want to save something else on i
So all DOs have 1GB of disk even if you aren't using the SQLite but want to save something else on it?
INo, SQLite storage is seperate. DOs don't have disk, they have SQLite (1GB) or DO KV storage.
IIn general you shouldn't think about it as "disk" but more like "I have a SQLite DB that can have a maximum size of 1GB"
IAll of the underlying hardware resources like disk/memory/cpu are managed by Cloudflare.
Lso it's like Workers and the Browser API which lives in a different machine
INo, it lives on the same machine.
Lyeah, i meant on the fact that you cannot use the resources of the API for doing other stuff
IYeah.
Lwell, i think you could potentially still use the sqlite as an object storage and dumping raw binary files in it
IYes you could. Keep in mind that there is no streaming of SQLite values so it would be held in memory.
I(unlike alternatives such as R2)
Lso is this SQLite better than a Redis
EHow long do we think it'll be until the alarms issue is with the sqlite is resolved?
Built something cool locally and then saw the warning in the docs
Built something cool locally and then saw the warning in the docs
LRedis is key-value oriented so in that sense it's more like Workers KV or the DO KV API. However, it has more functionality than a simple KV store including things like pub/sub and atomic operations like appending to a string or incrementing a value (although you can also do the latter atomicly with the DO KV API. Redis is often used as an in-memory distributed cache (think alternative to memcache) but it also has persistence.
The most obvios difference to SQLite is... well... SQL. SQLite is embedded not distributed (although read-replicas are implemented by some systems which is going to be the case for Cloudflare's D1) which limits scalability. Redis is distributed and scales up well.
The DO SQLite API though has another huge advantage beyond vanilla SQLite. With input gates, output gates, and write coalescing, you can essentially write stored procedures in JavaScript with atomicity, consistency, isolation, and durability (ACID). This means that during a single request where you never await, any combination of reads followed by any combination of writes are executed without worrying about another request changing anything from underneath you and where you can be sure that either all writes will succeed or all writes will fail. Caveat that I haven't confirmed that if you get an error back from an SQL write operation all the writes before that will be rolled back but I suspect that's the case and I intend to verify that experimentally shortly.
Note, these "stored procedures" run not only on the same machine but in the same memory space and thread making them very efficient and fast per request.
The tradeoff is that a single DO instance has a max throughput of about 1000 requests per second. The scaling model is to have many DOs so depending upon your application, there could be some coding complexity on your part and efficiency costs to coordinate between them. That said, many applications have natural boundaries across which little coordination is needed.
The most obvios difference to SQLite is... well... SQL. SQLite is embedded not distributed (although read-replicas are implemented by some systems which is going to be the case for Cloudflare's D1) which limits scalability. Redis is distributed and scales up well.
The DO SQLite API though has another huge advantage beyond vanilla SQLite. With input gates, output gates, and write coalescing, you can essentially write stored procedures in JavaScript with atomicity, consistency, isolation, and durability (ACID). This means that during a single request where you never await, any combination of reads followed by any combination of writes are executed without worrying about another request changing anything from underneath you and where you can be sure that either all writes will succeed or all writes will fail. Caveat that I haven't confirmed that if you get an error back from an SQL write operation all the writes before that will be rolled back but I suspect that's the case and I intend to verify that experimentally shortly.
Note, these "stored procedures" run not only on the same machine but in the same memory space and thread making them very efficient and fast per request.
The tradeoff is that a single DO instance has a max throughput of about 1000 requests per second. The scaling model is to have many DOs so depending upon your application, there could be some coding complexity on your part and efficiency costs to coordinate between them. That said, many applications have natural boundaries across which little coordination is needed.
S@tobias not official driver but i got it working sort of https://x.com/sadsciencee/status/1842714039719432404
successfully duct taped @DrizzleORM onto the new @CloudflareDev durable objects sqlite api
technically DO sqlite is synchronous, i used drizzle's http proxy which requires async. but im gonna let someone smarter than me figure that part out ¯\_(ツ)_/¯
technically DO sqlite is synchronous, i used drizzle's http proxy which requires async. but im gonna let someone smarter than me figure that part out ¯\_(ツ)_/¯
10/5/24, 11:50 PM
TI tried the same thing but got random errors hahah
THave you tried the query syntax?
Sya - tbh havent done any relational or joins yet. but basic findFirst/findMany works
working on streaming in bulk import files to battle test writes rn, ill have enough of a db to try some more complex queries after that
working on streaming in bulk import files to battle test writes rn, ill have enough of a db to try some more complex queries after that
L@kenton , does it also apply when the request exits with an uncaught runtime JavaScript error? Do the ones coalesced so far not get executed?
KNo, not necessarily. If you want to roll back on exceptions, you should wrap your code in
this.ctx.storage.transactionSync(() => {...}).LThanks. I don't see
.transactionSync() in the docsLDoes native replica support in SQLite change anything for SQLite-in-DO? https://sqlite.org/draft/rsync.html
LWill multiple DOs be able to sync with eachother?
HNo, afaik, since DO SQLite doesn't use the default SQLite storage engine anyway
Mjust reading the sqlite blog post that talks about N+1 selects and suggests with sync not to worry with joins - just query the db for every row of data in a seperate sqlite query
if this is the case, why not just stick to kv storage? what type of advantage does using sqlite-backed storage offer here?
if this is the case, why not just stick to kv storage? what type of advantage does using sqlite-backed storage offer here?
LFor most of this answer, I'm going to assume you mean the DO KV API but just in case you meant Workers KV the huge difference are the network round trips.
So, back to SQL vs DO KV...
First, just because N+1 selects can be as efficient as joins, doesn't mean you won't use joins some or even most of the time. For simple joins like inner and natural the syntax is easy to comprehend and it may even be more efficient. For complex joins like outer and cross as well as SQL with subqueries or aggregations it's less about efficiency and more about making sure that the next developer (and even yourself at a later date) can make sense of what's going on. Doing it in JavaScript may be a better alternative from this perspective. Note, neither @kenton nor the SQLite docs say that you should use N+1 selects, just that if you want, you shouldn't worry about efficiency because there is no network round trip or even CPU context switching cost.
Second, SQL isn't just about joins. Indexes in particular are a feature missing from KV that's super helpful but there are also triggers, constraints, aggregations, etc. that you may want to take advantage of.
So, back to SQL vs DO KV...
First, just because N+1 selects can be as efficient as joins, doesn't mean you won't use joins some or even most of the time. For simple joins like inner and natural the syntax is easy to comprehend and it may even be more efficient. For complex joins like outer and cross as well as SQL with subqueries or aggregations it's less about efficiency and more about making sure that the next developer (and even yourself at a later date) can make sense of what's going on. Doing it in JavaScript may be a better alternative from this perspective. Note, neither @kenton nor the SQLite docs say that you should use N+1 selects, just that if you want, you shouldn't worry about efficiency because there is no network round trip or even CPU context switching cost.
Second, SQL isn't just about joins. Indexes in particular are a feature missing from KV that's super helpful but there are also triggers, constraints, aggregations, etc. that you may want to take advantage of.
FI'm wondering the same, hope someone can answer
DPlease avoid pinging people in every message
KYes, embarrassingly we forgot to document it before launch, and worse, if you try to use
BEGIN TRANSACTION, the error message is not helpful, so some people came off thinking we don't support transactions at all. Will get that fixed soon.KFunny you should ask. I have been building a DO-based app of my own (to organize LAN parties...), and I actually decided I was happier with KV rather than SQL because I liked the ergonomics of just shoving whole JS objects into storage. It's a legitimate choice.
That said, as Larry points out, one big thing you'll lose that way is secondary indexes. In my case I had to hand-roll one or two secondary indexes, which was a bit of a pain.
Also note that even if you are using the KV API, you are still getting most of the benefits described in the blog post, since we're actually storing your KV data in SQLite under the hood. It's a bit harder to reason about sync/async though -- the KV interface appears to be async, but it's actually effectively synchronous when backed by SQLite.
That said, as Larry points out, one big thing you'll lose that way is secondary indexes. In my case I had to hand-roll one or two secondary indexes, which was a bit of a pain.
Also note that even if you are using the KV API, you are still getting most of the benefits described in the blog post, since we're actually storing your KV data in SQLite under the hood. It's a bit harder to reason about sync/async though -- the KV interface appears to be async, but it's actually effectively synchronous when backed by SQLite.
KAll of the data is on local disk from the start. With the old implementation, we were actually issuing queries to a big distributed database over the network for each read (well, unless it was in cache). That database was not optimized for this sort of use case; it was designed to expect that every key could have many clients transacting against it.
USo now that the KV backed storage is the sqlite (or will be at somepoint?) will the KV storage cost be cheaper going forward? Not sure if I overlooked it in the blog as I did a quick glance but it seems nothing has changed there
HWould it be possible to make KV synchronous too for SQLite-backed DOs? It shouldn't break any existing apps, since
awaiting it should still succeed
LSame here! Is there any ETA for the alarms to be available on SQLite DOs?
LYeah, that's one thing I'll miss if we switch to the SQL API. SQLite has JSON support but the DO KV API supports anything that is supported by the structured clone algorithm which includes native JS Date(), Set(), Map(), etc. as well as references including circular ones. I'm now noodling on whether it's worth it to split my references out to M:M tables.
I still think I'll probably do it because of indexes. Right now, we jump through hoops keeping indexes updated incrementally in memory and rely upon the DO only rarely being ejected from memory so we don't incur the cost of rehydrating those manual indexes on every request. I think we'll be able to let our DOs be completely stateless (from a memory perspective) if we switch to the SQL API.
I still think I'll probably do it because of indexes. Right now, we jump through hoops keeping indexes updated incrementally in memory and rely upon the DO only rarely being ejected from memory so we don't incur the cost of rehydrating those manual indexes on every request. I think we'll be able to let our DOs be completely stateless (from a memory perspective) if we switch to the SQL API.
KYeah, we might do that with a compat flag, or by introducing
getSync() or something... just changing it would break anyone who is using .then() instead of await.HOoh, good point
KI think we enabled it last Friday.
HShould have set an alarm… 
KWe re-enabled it on Friday, should work now.
KWe re-enabled it on Friday, should work now. I see the docs weren't updated yet, will fix.
EWoo awesome
DDid getAlarm calls end up being counted as a row read?
Kright now in beta we are not billing for rows read or written. I think the plan is to make getAlarm not count before we start billing but it hasn't been finalized yet.
Kof course reads are soooooooo cheap it's hard to imagine it making a difference....
Dfair enough, I just remembered seeing the discussion in GH
Dso long as it's documented, I wouldn't mind it being billed - not that I would be able to notice haha
HWith the move to a new storage engine, do you think it would be possible to add a way to schedule multiple alarms, with attached metadata?
HYou can do that manually now, but it requires a bit of legwork
Mhttps://developers.cloudflare.com/durable-objects/platform/changelog/#2024-10-07
- changelog (Alarms for SQLite backed DOs are now re-enabled)
