pm edits for sqlite ga

Author: vy-ton

src/content/docs/durable-objects/best-practices/access-durable-objects-storage.mdx

@@ -14,10 +14,28 @@ A Durable Object's [in-memory state](/durable-objects/reference/in-memory-state/
 
 ## Access storage
 
-By default, a <GlossaryTooltip term="Durable Object class">Durable Object class</GlossaryTooltip> leverages a SQLite storage backend.
+We recommend all new <GlossaryTooltip term="Durable Object class">Durable Object classes</GlossaryTooltip> use the SQLite storage backend. Key-value storage backend remains for backwards compatibility, and a migration path from key-value storage to SQL storage for existing Durable Object classes will be offered in the future. 
 
 [Storage API methods](/durable-objects/api/storage-api/#methods) are available on `ctx.storage` parameter passed to the Durable Object constructor. Storage API has SQL APIs and key-value APIs. Only Durable Object classes with a SQLite storage backend can access SQL API.
 
+### Wrangler configuration for SQLite-backed Durable Objects
+
+Use `new_sqlite_classes` on the migration in your Worker's Wrangler file:
+
+<WranglerConfig>
+
+```toml
+[[migrations]]
+tag = "v1" # Should be unique for each entry
+new_sqlite_classes = ["MyDurableObject"] # Array of new classes
+```
+
+</WranglerConfig>
+
+[SQL API](/durable-objects/api/sql-storage/#exec) is available on `ctx.storage.sql` parameter passed to the Durable Object constructor.
+
+### Initialize instance variables from storage 
+
 A common pattern is to initialize a Durable Object from [persistent storage](/durable-objects/api/storage-api/) and set instance variables the first time it is accessed. Since future accesses are routed to the same Durable Object, it is then possible to return any initialized values without making further calls to persistent storage.
 
 ```ts
@@ -42,38 +60,23 @@ export class Counter extends DurableObject {
   }
 }
 ```
+
 ### Remove a Durable Object's storage
 
 A Durable Object fully ceases to exist if, when it shuts down, its storage is empty. If you never write to a Durable Object's storage at all (including setting <GlossaryTooltip term="alarm">alarms</GlossaryTooltip>), then storage remains empty, and so the Durable Object will no longer exist once it shuts down.
 
 However if you ever write using [Storage API](/durable-objects/api/storage-api/), including setting alarms, then you must explicitly call [`storage.deleteAll()`](/durable-objects/api/storage-api/#deleteall) to empty storage. It is not sufficient to simply delete the specific data that you wrote, such as deleting a key or dropping a table, as some metadata may remain. The only way to remove all storage is to call `deleteAll()`. Calling `deleteAll()` ensures that a Durable Object will not be billed for storage.
 
-## Wrangler configuration for SQLite Durable Objects
-
-Use `new_sqlite_classes` on the migration in your Worker's Wrangler file:
-
-<WranglerConfig>
-
-```toml
-[[migrations]]
-tag = "v1" # Should be unique for each entry
-new_sqlite_classes = ["MyDurableObject"] # Array of new classes
-```
-
-</WranglerConfig>
-
-[SQL API](/durable-objects/api/sql-storage/#exec) is available on `ctx.storage.sql` parameter passed to the Durable Object constructor.
-
-## Examples
+## SQL API Examples
 
 <Render file="durable-objects-sql" />
 
-<Render file="durable-objects-vs-d1" />
-
-## Index for SQLite Durable Objects
+## Indexes in SQLite
 
 Creating indexes for your most queried tables and filtered columns reduces how much data is scanned and improves query performance at the same time. If you have a read-heavy workload (most common), this can be particularly advantageous. Writing to columns referenced in an index will add at least one (1) additional row written to account for updating the index, but this is typically offset by the reduction in rows read due to the benefits of an index.
 
+<Render file="durable-objects-vs-d1" />
+
 ## Related resources
 
 * [Zero-latency SQLite storage in every Durable Object blog post](https://blog.cloudflare.com/sqlite-in-durable-objects)

src/content/docs/durable-objects/get-started.mdx

@@ -52,7 +52,7 @@ Move into your new directory:
 cd durable-object-starter
 ```
 
-## 2. Write a Durable Object class
+## 2. Write a Durable Object class using SQL API
 
 Before you create and access a Durable Object, its behavior must be defined by an ordinary exported JavaScript class.
 

src/content/docs/durable-objects/index.mdx

@@ -13,21 +13,21 @@ head:
 import { Render, CardGrid, Description, Feature, LinkTitleCard, Plan, RelatedProduct, LinkButton } from "~/components"
 
 <Description>
-Create collaborative applications, real-time chat, multiplayer games and more without needing to coordinate state or manage infrastructure.
+Create AI agents, collaborative applications, real-time interactions like chat or multiplayer games, and more without needing to coordinate state or manage infrastructure.
 </Description>
 
 <Plan type="workers-all" />
 
 Durable Objects provide a building block for stateful applications and distributed systems.
 
-Use Durable Objects to build applications that need coordination among multiple clients, like collaborative editing tools, interactive chat, multiplayer games, and deep distributed systems, without requiring you to build serialization and coordination primitives on your own.
+Use Durable Objects to build applications that need coordination among multiple clients, like collaborative editing tools, interactive chat, multiplayer games, live notifications, and deep distributed systems, without requiring you to build serialization and coordination primitives on your own.
 
 <LinkButton href="/durable-objects/get-started/">Get started</LinkButton>
 
 :::note
-SQLite-backed Durable Objects have now reached GA.
+SQLite-backed Durable Objects are now available on the Workers Free plan with these [limits](/durable-objects/platform/pricing/). 
 
-You can use SQLite-backed Durable Objects with the Workers Free plan.
+SQLite storage and [SQL API](/durable-objects/api/sql-storage/) have moved from beta to general availability. New Durable Object classes should use wrangler configuration for [SQLite storage](/durable-objects/best-practices/access-durable-objects-storage/#wrangler-configuration-for-sqlite-durable-objects).
 :::
 
 ### What are Durable Objects?

src/content/partials/durable-objects/storage-intro-text.mdx

@@ -4,8 +4,8 @@
 
 The Durable Object Storage API comes with several methods, including key-value (KV) API, SQL API, and point-in-time-recovery (PITR) API.
 
-- Durable Object classes with the default, [SQLite storage backend](/durable-objects/best-practices/access-durable-objects-storage/#sqlite-storage-backend) can use KV API, SQL API, and PITR API. KV API methods like `get()`, `put()`, `delete()`, or `list()` store data in a hidden SQLite table.
+- Durable Object classes with the recommended, [SQLite storage backend](/durable-objects/best-practices/access-durable-objects-storage/#sqlite-storage-backend) can use KV API, SQL API, and PITR API. KV API methods like `get()`, `put()`, `delete()`, or `list()` store data in a hidden SQLite table.
 - Specifically for Durable Object classes with SQLite storage backend, KV operations which were previously asynchronous (for example, [`get`](/durable-objects/api/storage-api/#get), [`put`](/durable-objects/api/storage-api/#put), [`delete`](/durable-objects/api/storage-api/#delete), [`deleteAll`](/durable-objects/api/storage-api/#deleteall), [`list`](/durable-objects/api/storage-api/#list)) are synchronous, even though they return promises. These methods will have completed their operations before they return the promise.
-- Durable Object classes with the key-value storage backend can use KV API.
+- Durable Object classes with the key-value storage backend can only use KV API.
 
 Each method is implicitly wrapped inside a transaction, such that its results are atomic and isolated from all other storage operations, even when accessing multiple key-value pairs.