@mastra/pg 1.22.2 → 1.22.3-alpha.1

package/dist/docs/SKILL.md

@@ -3,7 +3,7 @@ name: mastra-pg
 description: Documentation for @mastra/pg. Use when working with @mastra/pg APIs, configuration, or implementation.
 metadata:
   package: "@mastra/pg"
-  version: "1.22.2"
+  version: "1.22.3-alpha.1"
 ---
 
 ## When to use
@@ -16,32 +16,32 @@ Read the individual reference documents for detailed explanations and code examp
 
 ### Docs
 
-- [Workers](references/docs-deployment-workers.md) - Separate background processing from the API layer by running workflow execution, cron schedules, and background tasks in dedicated worker processes.
-- [Semantic recall](references/docs-memory-semantic-recall.md) - Learn how to use semantic recall in Mastra to retrieve relevant messages from past conversations using vector search and embeddings.
-- [Working memory](references/docs-memory-working-memory.md) - Learn how to configure working memory in Mastra to store persistent user data, preferences.
-- [Storage](references/docs-storage.md) - Configure storage for Mastra to persist runtime state across agents, workflows, observability, evals, schedules, and memory.
+- [Workers](references/docs-deployment-workers.md) - Run Mastra workflow orchestration, schedules, and long-running background tasks in dedicated workers to keep API processes responsive under load.
+- [Semantic recall](references/docs-memory-semantic-recall.md) - Retrieve relevant messages from past Mastra conversations with semantic recall, vector search, embeddings, metadata filters, and configurable storage.
+- [Working memory](references/docs-memory-working-memory.md) - Persist user profiles, preferences, and application data with Mastra working memory using resource- or thread-scoped templates and storage adapters.
+- [Storage](references/docs-storage.md) - Configure Mastra storage to persist memory, workflow state, observability data, evals, schedules, and long-running agent state across restarts.
 
 ### Integrations
 
-- [DynamoDB](references/integrations-databases-dynamodb.md) - Documentation for the DynamoDB storage implementation in Mastra, using a single-table design with ElectroDB.
-- [Neon Postgres](references/integrations-databases-neon.md) - Use Neon Postgres as a Mastra storage and vector backend.
-- [PostgreSQL](references/integrations-databases-postgresql.md) - Documentation for the PostgreSQL storage implementation in Mastra.
+- [DynamoDB](references/integrations-databases-dynamodb.md) - Persist Mastra data in Amazon DynamoDB with a single-table ElectroDB design, configurable indexes, TTL support, credentials, and table initialization.
+- [Neon Postgres](references/integrations-databases-neon.md) - Connect Mastra to Neon Postgres with PostgresStore, pooled production connections, schema initialization, vector search, and Neon agent skills.
+- [PostgreSQL](references/integrations-databases-postgresql.md) - Persist Mastra application data in PostgreSQL with PostgresStore, configure connections and pools, initialize schemas, and enable observability.
 
 ### Reference
 
-- [Reference: Memory class](references/reference-memory-memory-class.md) - Documentation for the `Memory` class in Mastra, which provides a reliable system for managing conversation history and thread-based message storage.
-- [Reference: MessageHistory](references/reference-processors-message-history-processor.md) - Documentation for the MessageHistory processor in Mastra, which handles retrieval and persistence of conversation history.
-- [Reference: SemanticRecall](references/reference-processors-semantic-recall-processor.md) - Documentation for the SemanticRecall processor in Mastra, which enables semantic search over conversation history using vector embeddings.
-- [Reference: WorkingMemory](references/reference-processors-working-memory-processor.md) - Documentation for the WorkingMemory processor in Mastra, which injects persistent user/context data as system instructions.
-- [Chunking and embedding documents](references/reference-rag-chunking-and-embedding.md) - Guide on chunking and embedding documents in Mastra for efficient processing and retrieval.
-- [Reference: Metadata filters](references/reference-rag-metadata-filters.md) - Documentation for metadata filtering capabilities in Mastra, which allow for precise querying of vector search results across different vector stores.
-- [RAG (Retrieval-Augmented Generation) in Mastra](references/reference-rag-overview.md) - Overview of Retrieval-Augmented Generation (RAG) in Mastra, detailing its capabilities for enhancing LLM outputs with relevant context.
-- [Retrieval, semantic search, reranking](references/reference-rag-retrieval.md) - Guide on retrieval processes in Mastra's RAG systems, including semantic search, filtering, and re-ranking.
-- [Storing embeddings in a vector database](references/reference-rag-vector-databases.md) - Guide on vector storage options in Mastra, including embedded and dedicated vector databases for similarity search.
-- [Reference: Composite storage](references/reference-storage-composite.md) - Documentation for combining multiple storage backends in Mastra.
-- [Reference: Storage retention (prune)](references/reference-storage-retention.md) - API reference for retention policies and prune() on Mastra storage.
-- [Reference: createVectorQueryTool()](references/reference-tools-vector-query-tool.md) - Documentation for the Vector Query Tool in Mastra, which facilitates semantic search over vector stores with filtering and reranking capabilities.
-- [Reference: PG vector store](references/reference-vectors-pg.md) - Documentation for the PgVector class in Mastra, which provides vector search using PostgreSQL with pgvector extension.
+- [Reference: Memory class](references/reference-memory-memory-class.md) - The Memory class provides a reliable system for managing conversation history and thread-based message storage in Mastra.
+- [Reference: MessageHistory](references/reference-processors-message-history-processor.md) - The MessageHistory is a hybrid processor that handles both retrieval and persistence of message history.
+- [Reference: SemanticRecall](references/reference-processors-semantic-recall-processor.md) - The SemanticRecall is a hybrid processor that enables semantic search over conversation history using vector embeddings.
+- [Reference: WorkingMemory](references/reference-processors-working-memory-processor.md) - The WorkingMemory is an input processor that injects working memory data as a system message.
+- [Chunking and embedding documents](references/reference-rag-chunking-and-embedding.md) - Chunk documents with MDocument, generate embeddings through the AI SDK, and prepare text and metadata for vector storage and RAG retrieval.
+- [Reference: Metadata filters](references/reference-rag-metadata-filters.md) - Mastra provides a unified metadata filtering syntax across all vector stores, based on MongoDB/Sift query syntax.
+- [RAG (Retrieval-Augmented Generation) in Mastra](references/reference-rag-overview.md) - RAG in Mastra helps you enhance LLM outputs by incorporating relevant context from your own data sources, improving accuracy and grounding responses in real information.
+- [Retrieval, semantic search, reranking](references/reference-rag-retrieval.md) - After storing embeddings, you need to retrieve relevant chunks to answer user queries.
+- [Storing embeddings in a vector database](references/reference-rag-vector-databases.md) - After generating embeddings, you need to store them in a database that supports vector similarity search.
+- [Reference: Composite storage](references/reference-storage-composite.md) - MastraCompositeStore can compose storage domains from different providers. Use it when you need different databases for different purposes.
+- [Reference: Storage retention (prune)](references/reference-storage-retention.md) - prune() deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable).
+- [Reference: createVectorQueryTool()](references/reference-tools-vector-query-tool.md) - The createVectorQueryTool() function creates a tool for semantic search over vector stores.
+- [Reference: PG vector store](references/reference-vectors-pg.md) - The PgVector class provides vector search using PostgreSQL with pgvector extension. It provides reliable vector similarity search capabilities within your existing PostgreSQL database.
 
 
 Read [assets/SOURCE_MAP.json](assets/SOURCE_MAP.json) for source code references.

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.22.2",
+  "version": "1.22.3-alpha.1",
   "package": "@mastra/pg",
   "exports": {},
   "modules": {}

package/dist/docs/references/docs-deployment-workers.md

@@ -27,7 +27,7 @@ Mastra has three built-in worker types. Each handles a specific kind of backgrou
 
 ### Orchestration worker
 
-Subscribes to workflow events on the [PubSub](https://mastra.ai/docs/server/pubsub) bus and executes workflow steps. Every `workflow.start`, step transition, and lifecycle event flows through this worker.
+This worker subscribes to workflow events on the [PubSub](https://mastra.ai/docs/server/pubsub) bus and executes workflow steps. It handles each `workflow.start` and lifecycle event together with every step transition.
 
 In a split deployment, the orchestration worker pulls events from a distributed PubSub backend and delegates step execution back to the API over HTTP. In-process, it runs steps directly.
 
@@ -377,7 +377,7 @@ If the API crashes while a step is executing, that work can be lost and the work
 
 - **No dead-letter queue**: Failed events are nacked and retried, but there's no DLQ for events that fail after all retries.
 - **Scheduler is single-instance**: Running multiple scheduler processes causes duplicate schedule fires.
-- **Runs stuck in "running" after API crash**: If the API process crashes while executing a workflow step, the run remains in `running` status with no automatic retry. For [durable agents](https://mastra.ai/docs/harness/durable-agents), set `recovery.durableAgents` to `'auto'` in the Mastra config to automatically re-drive orphaned runs on server restart. See [Crash recovery](https://mastra.ai/docs/harness/durable-agents) for details.
+- **Runs stuck in "running" after API crash**: A crash during workflow-step execution leaves the run in `running` status without an automatic retry. For [durable agents](https://mastra.ai/docs/harness/durable-agents), configure `recovery.durableAgents: 'auto'` so a server restart automatically re-drives orphaned runs. See [Crash recovery](https://mastra.ai/docs/harness/durable-agents) for details.
 
 ## Related
 

package/dist/docs/references/docs-memory-semantic-recall.md

@@ -14,8 +14,6 @@ Semantic recall is RAG-based search that helps agents maintain context across lo
 
 It uses vector embeddings of messages for similarity search and integrates with vector stores, plus has configurable context windows around retrieved messages.
 
-![Diagram showing Mastra Memory semantic recall](/assets/images/semantic-recall-fd7b9336a6d0d18019216cb6d3dbe710.png)
-
 When it's enabled, new messages are used to query a vector DB for semantically similar messages.
 
 After getting a response from the LLM, all new messages (user, assistant, and tool calls/results) are inserted into the vector DB to be recalled in later interactions.

package/dist/docs/references/docs-memory-working-memory.md

@@ -275,7 +275,7 @@ Schema-based working memory uses **merge semantics**, meaning the agent only nee
 ## Choosing between template and schema
 
 - Use a **template** (Markdown) if you want the agent to maintain memory as a free-form text block, such as a user profile or scratchpad. Templates use **replace semantics**: the agent must provide the complete memory content on each update.
-- Use a **schema** if you need structured, type-safe data that can be validated and programmatically accessed as JSON. The `workingMemory.schema` field accepts any `PublicSchema`-compatible schema (including Zod v3, Zod v4, JSON Schema, or already-standard schemas). Schemas use **merge semantics**: the agent only provides fields to update, and existing fields are preserved.
+- Use a **schema** for structured, type-safe JSON data that supports validation and programmatic access. The `workingMemory.schema` field accepts any `PublicSchema`-compatible schema, such as Zod v3 or v4. JSON Schema and already-standard schemas are also supported. **Merge semantics** preserve existing fields when the agent provides only the fields to update.
 - Only one mode can be active at a time: setting both `template` and `schema` isn't supported.
 
 ## Example: Multi-step retention

package/dist/docs/references/reference-processors-working-memory-processor.md

@@ -130,7 +130,7 @@ const processor = new WorkingMemory({
 
 4. Generates system instructions based on mode:
 
-   - **Normal mode**: Includes guidelines for storing/updating information, template structure, and current data
+   - **Normal mode**: Includes guidelines for storing and updating information, along with the template structure and current data
    - **Read-only mode** (`readOnly: true`): Includes only the current data as context without update instructions
 
 5. Adds the instruction as a system message with `source: 'memory'` tag

package/dist/docs/references/reference-rag-vector-databases.md

@@ -35,11 +35,11 @@ MongoDB Vector Search is a good solution for teams who want to consolidate vecto
 
 ### Using VoyageAI with MongoDB
 
-MongoDB works seamlessly with VoyageAI's embedding models, which are optimized for retrieval tasks. For complete examples and specialized models, see the [VoyageAI embeddings documentation](https://mastra.ai/models/embeddings) and [MongoDB vector reference](https://mastra.ai/reference/vectors/mongodb).
+MongoDB works directly with VoyageAI's embedding models, which are optimized for retrieval tasks. For complete examples and specialized models, see the [VoyageAI embeddings documentation](https://mastra.ai/models/embeddings) and [MongoDB vector reference](https://mastra.ai/reference/vectors/mongodb).
 
 ### Hybrid Search (Vector + Full-Text)
 
-MongoDB supports hybrid search that fuses vector similarity with BM25 full-text search using server-side `$rankFusion` (requires MongoDB >= 8.0; generally available from 8.1, and enabled on MongoDB Atlas 8.0.x). This is useful when you want to combine semantic and keyword-based retrieval:
+MongoDB supports hybrid search that combines vector similarity with BM25 full-text search through server-side `$rankFusion`. It requires MongoDB 8.0 or later, is generally available from 8.1, and is enabled on MongoDB Atlas 8.0.x. Use it to combine semantic retrieval with keyword-based results:
 
 ```ts
 await store.createSearchIndex({ indexName: 'myCollection', fields: ['text'] })
@@ -107,7 +107,7 @@ await store.upsert({
 
 ### Using Oracle Database Vector Search
 
-OracleDB stores embeddings in native `VECTOR` columns and metadata in Oracle JSON. Exact search is the default; HNSW and IVF indexes can be configured for tuned deployments.
+OracleDB stores embeddings in native `VECTOR` columns and metadata in Oracle JSON. Exact search is the default. HNSW and IVF indexes can be configured for tuned deployments.
 
 **Pinecone**:
 
@@ -239,8 +239,8 @@ const store = new UpstashVector({
   token: process.env.UPSTASH_TOKEN,
 })
 
-// There is no store.createIndex call here, Upstash creates indexes (known as namespaces in Upstash) automatically
-// when you upsert if that namespace does not exist yet.
+// Upstash creates indexes (known as namespaces) automatically, so no store.createIndex call is needed here
+// when you upsert if that namespace doesn't exist yet.
 await store.upsert({
   indexName: 'myCollection', // the namespace name in Upstash
   vectors: embeddings,
@@ -426,20 +426,20 @@ Collection and index names must:
 
 - Start with a letter or underscore
 - Be up to 120 bytes long
-- Contain only letters, numbers, underscores, or dots
-- Cannot contain `$` or the null character
+- Contain only letters, numbers, underscore characters, or dots
+- Can't contain `$` or the null character
 - Example: `my_collection.123` is valid
-- Example: `my-index` is not valid (contains hyphen)
-- Example: `My$Collection` is not valid (contains `$`)
+- Example: `my-index` isn't valid (contains hyphen)
+- Example: `My$Collection` isn't valid (contains `$`)
 
 **PgVector**:
 
 Index names must:
 
 - Start with a letter or underscore
-- Contain only letters, numbers, and underscores
+- Contain only letters, numbers, and underscore characters
 - Example: `my_index_123` is valid
-- Example: `my-index` is not valid (contains hyphen)
+- Example: `my-index` isn't valid (contains hyphen)
 
 **OracleDB**:
 
@@ -466,7 +466,7 @@ Index names must:
 - Have a combined length (with project ID) under 52 characters
 
   - Example: `my-index-123` is valid
-  - Example: `my.index` is not valid (contains dot)
+  - Example: `my.index` isn't valid (contains dot)
 
 **Qdrant**:
 
@@ -482,7 +482,7 @@ Collection names must:
 
 - Example: `my_collection_123` is valid
 
-- Example: `my/collection` is not valid (contains slash)
+- Example: `my/collection` isn't valid (contains slash)
 
 **Chroma**:
 
@@ -490,11 +490,11 @@ Collection names must:
 
 - Be 3-63 characters long
 - Start and end with a letter or number
-- Contain only letters, numbers, underscores, or hyphens
+- Contain only letters, numbers, underscore characters, or hyphens
 - Not contain consecutive periods (..)
 - Not be a valid IPv4 address
 - Example: `my-collection-123` is valid
-- Example: `my..collection` is not valid (consecutive periods)
+- Example: `my..collection` isn't valid (consecutive periods)
 
 **Astra**:
 
@@ -502,18 +502,18 @@ Collection names must:
 
 - Not be empty
 - Be 48 characters or less
-- Contain only letters, numbers, and underscores
+- Contain only letters, numbers, and `_` characters
 - Example: `my_collection_123` is valid
-- Example: `my-collection` is not valid (contains hyphen)
+- Example: `my-collection` isn't valid (contains hyphen)
 
 **libSQL**:
 
 Index names must:
 
 - Start with a letter or underscore
-- Contain only letters, numbers, and underscores
+- Contain only letters, numbers, and `_` characters
 - Example: `my_index_123` is valid
-- Example: `my-index` is not valid (contains hyphen)
+- Example: `my-index` isn't valid (contains hyphen)
 
 **Upstash**:
 
@@ -532,7 +532,7 @@ Namespace names must:
 
 - Example: `MyNamespace123` is valid
 
-- Example: `_namespace` is not valid (starts with underscore)
+- Example: `_namespace` isn't valid (starts with underscore)
 
 **Cloudflare**:
 
@@ -543,19 +543,19 @@ Index names must:
 - Contain only lowercase ASCII letters, numbers, and dashes
 - Use dashes instead of spaces
 - Example: `my-index-123` is valid
-- Example: `My_Index` is not valid (uppercase and underscore)
+- Example: `My_Index` isn't valid (uppercase and underscore)
 
 **OpenSearch**:
 
 Index names must:
 
 - Use only lowercase letters
-- Not begin with underscores or hyphens
+- Not begin with underscore characters or hyphens
 - Not contain spaces, commas
 - Not contain special characters (e.g. `:`, `"`, `*`, `+`, `/`, `\`, `|`, `?`, `#`, `>`, `<`)
 - Example: `my-index-123` is valid
-- Example: `My_Index` is not valid (contains uppercase letters)
-- Example: `_myindex` is not valid (begins with underscore)
+- Example: `My_Index` isn't valid (contains uppercase letters)
+- Example: `_myindex` isn't valid (begins with underscore)
 
 **Elasticsearch**:
 
@@ -563,29 +563,29 @@ Index names must:
 
 - Use only lowercase letters
 - Not exceed 255 bytes (counting multi-byte characters)
-- Not begin with underscores, hyphens, or plus signs
+- Not begin with underscore characters, hyphens, or plus signs
 - Not contain spaces, commas
 - Not contain special characters (e.g. `:`, `"`, `*`, `+`, `/`, `\`, `|`, `?`, `#`, `>`, `<`)
 - Not be "." or ".."
 - Not start with "." (deprecated except for system/hidden indices)
 - Example: `my-index-123` is valid
-- Example: `My_Index` is not valid (contains uppercase letters)
-- Example: `_myindex` is not valid (begins with underscore)
-- Example: `.myindex` is not valid (begins with dot, deprecated)
+- Example: `My_Index` isn't valid (contains uppercase letters)
+- Example: `_myindex` isn't valid (begins with underscore)
+- Example: `.myindex` isn't valid (begins with dot, deprecated)
 
 **S3 Vectors**:
 
 Index names must:
 
 - Be unique within the same vector bucket
-- Be 3–63 characters long
+- Be between 3 and 63 characters long
 - Use only lowercase letters (`a–z`), numbers (`0–9`), hyphens (`-`), and dots (`.`)
 - Begin and end with a letter or number
 - Example: `my-index.123` is valid
-- Example: `my_index` is not valid (contains underscore)
-- Example: `-myindex` is not valid (begins with hyphen)
-- Example: `myindex-` is not valid (ends with hyphen)
-- Example: `MyIndex` is not valid (contains uppercase letters)
+- Example: `my_index` isn't valid (contains underscore)
+- Example: `-myindex` isn't valid (begins with hyphen)
+- Example: `myindex-` isn't valid (ends with hyphen)
+- Example: `MyIndex` isn't valid (contains uppercase letters)
 
 ### Upserting Embeddings
 

package/dist/docs/references/reference-storage-composite.md

@@ -255,7 +255,7 @@ const thread = await memoryStore?.getThreadById({ threadId: '...' })
 
 ## Closing connections
 
-`close()` releases the connections of the stores a composite was built from: the `default` and `editor` stores, plus any domain that owns its own client. Each store is closed once, even when it backs several domains. When passed to the Mastra class, `close()` is called by `shutdown()`:
+`close()` releases connections for the stores used by a composite, including the `default` and `editor` stores and any domain with its own client. Each store closes once even if it backs several domains. When the composite is passed to the Mastra class, `shutdown()` calls `close()`:
 
 ```typescript
 import { MastraCompositeStore } from '@mastra/core/storage'

package/dist/docs/references/reference-storage-retention.md

@@ -4,7 +4,7 @@
 
 # Storage retention
 
-Storage grows without bound by default. Retention is an opt-in, age-based cleanup system: you declare per-table `maxAge` policies in the `retention` config, then call `storage.prune()` to delete rows older than their configured age. Anything you don't configure is kept forever, so there is no behavior change until you opt in.
+Because storage grows without bound by default, Mastra provides an opt-in, age-based retention system. Declare per-table `maxAge` policies in the `retention` config, then call `storage.prune()` to delete rows older than their configured age. Unconfigured data is kept forever, so behavior doesn't change until you opt in.
 
 `prune()` deletes rows. It caps growth and is safe to run against large tables (batched, bounded, resumable, cancellable). It never reclaims disk: on SQLite/libSQL the freed pages are reused by future writes so the file stops growing, but handing disk back to the OS (for example a `VACUUM`) is left to the underlying database and the operator to manage.
 
@@ -37,7 +37,7 @@ const storage = new LibSQLStore({
 const results = await storage.prune()
 ```
 
-`retention` is fully typed. Keys must be real domain keys, and each table key must be one the domain declares as retention-eligible. Passing the object straight into a store config type-checks it; if you build it standalone, use `satisfies RetentionConfig` so unknown domains or tables are compile errors:
+`retention` is fully typed. Domain keys must exist, and their table keys must be declared retention-eligible. Store configs type-check objects passed directly. When building an object separately, use `satisfies RetentionConfig` so unknown domains or tables produce compile errors:
 
 ```typescript
 import type { RetentionConfig } from '@mastra/core/storage'
@@ -67,7 +67,7 @@ Set the `retention` field on the store config.
 
 ### Retention-eligible tables
 
-Each domain declares which of its tables can be age-pruned and which timestamp column anchors the comparison. The anchor is chosen so `maxAge` means what you'd expect for that data. Append-only logs use creation time, and live state uses last activity. Jobs and runs use completion time, so in-flight work is never pruned.
+Each domain specifies its age-prunable tables and the timestamp column that anchors comparison, chosen so `maxAge` matches the meaning of the data. Append-only logs use creation time, live state uses last activity, and jobs or runs use completion time so in-flight work isn't pruned.
 
 | Domain            | Table key          | Anchor column    | `maxAge` measures                                                |
 | ----------------- | ------------------ | ---------------- | ---------------------------------------------------------------- |
@@ -158,7 +158,7 @@ interface PruneResult {
 
 ## Running prune on a schedule
 
-`prune()` has no built-in scheduler: you decide when it runs. Because it's bounded, a single call may not delete everything. When any result has `done: false`, eligible rows remain and you call again on the next tick. This keeps each invocation short and lets a large backlog drain over several runs.
+`prune()` has no built-in scheduler, so you decide when it runs. A bounded call may leave eligible rows, indicated by any result with `done: false`. Call it again on the next tick. Short invocations let a large backlog drain over several runs.
 
 ```typescript
 // Runs on your own cron (node-cron, a workflow schedule, an external job, etc.).

package/dist/index.cjs

@@ -20751,6 +20751,8 @@ function rowToDefinition(row) {
 	if (stateSchema !== void 0 && stateSchema !== null) def.stateSchema = stateSchema;
 	const requestContextSchema = parseJsonResilient(row.requestContextSchema);
 	if (requestContextSchema !== void 0 && requestContextSchema !== null) def.requestContextSchema = requestContextSchema;
+	const schedule = parseJsonResilient(row.schedule);
+	if (schedule !== void 0 && schedule !== null) def.schedule = schedule;
 	if (row.authorId != null) def.authorId = String(row.authorId);
 	return def;
 }
@@ -20808,6 +20810,11 @@ var WorkflowDefinitionsPG = class WorkflowDefinitionsPG extends _mastra_core_sto
 			tableName: _mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS,
 			schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS]
 		});
+		await this.#db.alterTable({
+			tableName: _mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS,
+			schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_WORKFLOW_DEFINITIONS],
+			ifNotExists: ["schedule"]
+		});
 		await this.createDefaultIndexes();
 		await this.createCustomIndexes();
 	}
@@ -20829,6 +20836,7 @@ var WorkflowDefinitionsPG = class WorkflowDefinitionsPG extends _mastra_core_sto
 				stateSchema: input.stateSchema ?? null,
 				requestContextSchema: input.requestContextSchema ?? null,
 				graph: input.graph,
+				schedule: "schedule" in input ? input.schedule ?? null : null,
 				status: "active",
 				source: "storage",
 				authorId: "authorId" in input ? input.authorId ?? null : null,
@@ -20859,6 +20867,7 @@ var WorkflowDefinitionsPG = class WorkflowDefinitionsPG extends _mastra_core_sto
 		if ("stateSchema" in input && input.stateSchema !== void 0) data.stateSchema = input.stateSchema;
 		if ("requestContextSchema" in input && input.requestContextSchema !== void 0) data.requestContextSchema = input.requestContextSchema;
 		if ("graph" in input && input.graph !== void 0) data.graph = input.graph;
+		if ("schedule" in input && input.schedule !== void 0) data.schedule = input.schedule;
 		if ("status" in input && input.status !== void 0) data.status = input.status;
 		if ("authorId" in input && input.authorId !== void 0) data.authorId = input.authorId;
 		await this.#db.update({