Revise documentation to emphasize the dynamic query model, replacing references to stored queries with dynamic queries throughout various sections. Update project setup guides for Rust and TypeScript to reflect the new querying approach, and enhance clarity on query authoring and execution workflows. Additionally, add new sections for TypeScript project setup and querying guide, ensuring consistency in terminology and improving user guidance.

Author: xav-db

cli/workflows/helix_cloud.mdx

@@ -7,7 +7,7 @@ icon: "cloud"
 
 > For the complete documentation index optimized for AI agents, see [llms.txt](/llms.txt).
 
-The Helix CLI's V2 Cloud surface covers authentication, workspace/project/cluster selection, instance metadata sync, log retrieval, and dynamic queries against a remote gateway. Cluster provisioning, scaling, and stored-procedure deployment happen in the Helix control plane — not in the CLI.
+The Helix CLI's V2 Cloud surface covers authentication, workspace/project/cluster selection, instance metadata sync, log retrieval, and dynamic queries against a remote gateway. Cluster provisioning and scaling happen in the Helix control plane — not in the CLI.
 
 ## Prerequisites
 

database/architecture.mdx

@@ -23,8 +23,8 @@ storage that can handle concurrent writes to the writer node and allows for virt
 The gateway is the entry point for all client traffic. For high availability, deploy at least
 three gateway instances per cluster. Smaller gateway fleets can be used for non-HA or test
 workloads, but they are not recommended for production. Gateways accept HTTP requests,
-authenticate the caller via Bearer token, resolve a stored query name or accept an inline query
-payload, and route the request to the writer or a reader. Mutations are always routed to the
+authenticate the caller via Bearer token, accept the inline query payload, and route the request
+to the writer or a reader. Mutations are always routed to the
 writer. Read-only queries are distributed across readers and the writer. Gateways handle
 connection management, load balancing, token validation, and the translation from HTTP requests to
 the backend query RPC.
@@ -103,7 +103,7 @@ regardless of cache state; caching affects latency, not correctness.
     Secondary, vector, and text indexes over the property graph.
   </Card>
   <Card title="Querying" icon="magnifying-glass" href="/database/querying">
-    Traversal DSL, stored queries, dynamic queries, and transactions.
+    Traversal DSL, dynamic queries, and transactions.
   </Card>
   <Card title="Guarantees" icon="shield-check" href="/database/guarantees">
     Consistency, durability, and isolation under this architecture.

database/introduction.mdx

@@ -35,14 +35,14 @@ Caches reduce steady-state latency and accelerate cold starts.
   text search artifacts keep hot-path reads fast.
 - **Full ACID transactions.** Every query runs in a serializable snapshot isolation transaction.
   Concurrent reads and writes do not block each other.
-- **Stored query model.** Queries are authored in a Rust DSL, deployed as stored procedures, and
-  invoked by name over HTTP. No query parsing at runtime.
+- **Dynamic query model.** Queries are authored in a Rust or TypeScript DSL and sent to the
+  runtime as dynamic HTTP requests that carry the query inline. No separate deployment step.
 
 ## Next Steps
 
 <CardGroup cols={2}>
   <Card title="Working with Helix Cloud" icon="rocket" href="/database/working-with-enterprise">
-    Deploy-time and runtime workflow for stored and dynamic queries.
+    Authoring and runtime workflow for dynamic queries.
   </Card>
   <Card title="Architecture" icon="sitemap" href="/database/architecture">
     Gateway, writer, readers, object storage, and the cache hierarchy.
@@ -51,7 +51,7 @@ Caches reduce steady-state latency and accelerate cold starts.
     Run the `enterprise-dev` image in-memory or against MinIO.
   </Card>
   <Card title="Querying" icon="magnifying-glass" href="/database/querying">
-    Traversal DSL, stored queries, dynamic queries, and transactions.
+    Traversal DSL, dynamic queries, and transactions.
   </Card>
 </CardGroup>
 

database/limits.mdx

@@ -50,6 +50,6 @@ fundamental architectural boundaries.
 
 | Limit             | Value                                |
 | ----------------- | ------------------------------------ |
-| Query model       | Stored procedures and runtime queries|
+| Query model       | Dynamic queries                      |
 | Query language    | Rust DSL                             |
 | Transaction scope | One transaction per query invocation |

database/local-development.mdx

@@ -13,8 +13,8 @@ database together in a single container. The image supports two storage modes:
 
 In both modes:
 
-- If `PATH_TO_QUERIES` is unset, you can still use dynamic `POST /v1/query` requests.
-- If `PATH_TO_QUERIES` is set, the container loads stored queries from the mounted
+- If `PATH_TO_QUERIES` is unset, send queries as dynamic `POST /v1/query` requests.
+- If `PATH_TO_QUERIES` is set, the container preloads your query bundle from the mounted
   `queries.json` file during startup.
 
 ## Quick Start with the CLI
@@ -118,7 +118,8 @@ services:
       - ./queries.json:/workspace/queries.json:ro
 ```
 
-If you only want dynamic queries, omit `PATH_TO_QUERIES` and the mounted `queries.json` volume.
+To run without a preloaded bundle, omit `PATH_TO_QUERIES` and the mounted `queries.json` volume;
+queries still execute as dynamic `POST /v1/query` requests.
 
 ## On-Disk
 
@@ -194,10 +195,10 @@ itself. Drop `AWS_ENDPOINT` and `AWS_ALLOW_HTTP` to talk to real AWS S3.
 
 <CardGroup cols={2}>
   <Card title="Working with Helix Cloud" icon="rocket" href="/database/working-with-enterprise">
-    Authoring `queries.json`, deploying stored queries, and the runtime workflow.
+    Authoring `queries.json` and the runtime workflow.
   </Card>
   <Card title="Querying" icon="magnifying-glass" href="/database/querying">
-    Traversal DSL, stored queries, dynamic queries, and transactions.
+    Traversal DSL, dynamic queries, and transactions.
   </Card>
   <Card title="CLI Getting Started" icon="terminal" href="/cli/getting-started">
     Install the Helix CLI, scaffold a project, and send your first query.

database/querying-guide/advanced.mdx

@@ -460,9 +460,9 @@ A few notes specific to `forEachParam`:
 
 <CardGroup cols={2}>
   <Card title="Parameters and bundles" icon="gear" href="/database/querying-guide/parameters-bundles">
-    `defineParams`, dynamic requests, stored bundles, typed call helpers.
+    `defineParams`, dynamic requests, bundles, typed call helpers.
   </Card>
   <Card title="Querying overview" icon="book-open" href="/database/querying">
-    The conceptual story: stored vs dynamic queries, transactions, and how the bundle is deployed.
+    The conceptual story: dynamic queries, transactions, and the HTTP surface.
   </Card>
 </CardGroup>

database/querying-guide/overview.mdx

@@ -6,7 +6,7 @@ title: 'Querying Guide: Overview'
 
 This guide is a tutorial walkthrough of the HelixDB query language. Each page builds
 on the last, starting from the simplest possible read and ending at parameter-bound
-stored bundles. Every example shows the **TypeScript**, **Rust**, and **JSON** form
+bundles. Every example shows the **TypeScript**, **Rust**, and **JSON** form
 side by side, so you can pick a client and follow along — or skim across all three to
 see how the surfaces relate.
 
@@ -112,7 +112,7 @@ const aliceFeed = readBatch()
   )
   .returning(["user", "posts"]);
 
-const body = aliceFeed.toDynamicJson(); // POST body for /v1/query
+const request = aliceFeed.toDynamicRequest(); // POST this to /v1/query
 ```
 
 ```rust Rust
@@ -194,40 +194,33 @@ Two things to notice:
 ## Sending the request
 
 The JSON above is the actual body for `POST /v1/query`. Below are the same request
-in three transports — TypeScript using `fetch`, Rust using `reqwest`, and `curl`
+in three transports — TypeScript and Rust using their SDK clients, and `curl`
 straight from the shell. All three are interchangeable; pick whichever fits your
 environment.
 
 <CodeGroup>
 ```ts TypeScript
 // Continuing from the snippet above.
-const response = await fetch("https://helix.example.com/v1/query", {
-  method: "POST",
-  headers: { "content-type": "application/json" },
-  body: aliceFeed.toDynamicJson(),
-});
-
-if (!response.ok) {
-  throw new Error(`Helix returned ${response.status}`);
-}
+import { Client } from "@helix-db/helix-db";
+
+const client = new Client("https://helix.example.com");
 
-const { user, posts } = await response.json();
+const { user, posts } = await client
+  .query<{ user: unknown; posts: unknown }>()
+  .dynamic(request) // from .toDynamicRequest() above
+  .send();
 ```
 
 ```rust Rust
-// alice_feed() returns a ReadBatch; build a DynamicQueryRequest and post it.
-use helix_db::dsl::prelude::*;
+// alice_feed() returns the request to POST to /v1/query.
+use helix_db::Client;
 
-let body = DynamicQueryRequest::read(alice_feed()).to_json_string()?;
+let client = Client::new(Some("https://helix.example.com"))?;
 
-let response = reqwest::Client::new()
-    .post("https://helix.example.com/v1/query")
-    .header("content-type", "application/json")
-    .body(body)
+let response: serde_json::Value = client
+    .query()
+    .dynamic(alice_feed())
     .send()
-    .await?
-    .error_for_status()?
-    .json::<serde_json::Value>()
     .await?;
 
 let user = &response["user"];
@@ -271,11 +264,8 @@ The response is a JSON object keyed by the names from `.returning([...])` — he
 `{ "user": [...], "posts": [...] }`. Each value is the list of rows produced by that
 named binding.
 
-If this query were deployed as a *stored* route under the name `alice_feed`, the
-client would hit `POST /v1/query/alice_feed` with a much smaller body (just the
-parameters object — empty `{}` here, since this query takes none). The
-[Parameters and bundles](/database/querying-guide/parameters-bundles) page walks
-through both shapes.
+The [Parameters and bundles](/database/querying-guide/parameters-bundles) page shows
+how to bind parameters and organize queries into a `queries.json` bundle.
 
 ## How to read this guide
 
@@ -287,9 +277,8 @@ Each page follows the same template:
 3. The **Rust** tab mirrors the TypeScript exactly, with snake-case method names and
    the trailing-underscore convention for Rust keywords (`where_`, `in_`, `as_`).
 4. The **JSON** tab is the serialized AST that either DSL produces. It is the body
-   you would POST to `/v1/query` for a dynamic request; the same object appears
-   inside `queries.json` under `read_routes.<name>` or `write_routes.<name>` for a
-   stored route.
+   you would POST to `/v1/query`; the same object appears inside a generated
+   `queries.json` bundle under `read_routes.<name>` or `write_routes.<name>`.
 
 You can also jump straight to any topic from the list below; the pages do not assume
 strict sequential reading, but anything earlier in the list is fair game later on.
@@ -319,6 +308,6 @@ strict sequential reading, but anything earlier in the list is fair game later o
     `repeat`, `union`, `choose`, `coalesce`, `optional`, `varAsIf`, `forEachParam`.
   </Card>
   <Card title="Parameters and bundles" icon="gear" href="/database/querying-guide/parameters-bundles">
-    `defineParams`, stored bundles, dynamic requests, typed call helpers.
+    `defineParams`, dynamic requests, bundles, typed call helpers.
   </Card>
 </CardGroup>