@mastra/pg 1.20.0 → 1.20.1-alpha.0

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # @mastra/pg
 
+## 1.20.1-alpha.0
+
+### Patch Changes
+
+- Improved workflow run list performance in `@mastra/pg` when filtering by workflow name. The default index avoids sorting the ordered result query for workflows with large run histories. Paginated requests still use a separate count query. ([#21308](https://github.com/mastra-ai/mastra/pull/21308))
+
+- Updated dependencies [[`7e096f0`](https://github.com/mastra-ai/mastra/commit/7e096f02f0dddbf09b85d306458351245ed2f886), [`8f0a332`](https://github.com/mastra-ai/mastra/commit/8f0a3321bf180368d76fe7b36aa1a8f60f00b6de), [`b098de9`](https://github.com/mastra-ai/mastra/commit/b098de9d7cb9f672e0883a5c716465a3a689693d), [`ef6e295`](https://github.com/mastra-ai/mastra/commit/ef6e295b59bc25a5b61b633a89c97bcfce9fb465), [`208e1b3`](https://github.com/mastra-ai/mastra/commit/208e1b39f30f4b386e494394e9d71d96f0f90241), [`c938d34`](https://github.com/mastra-ai/mastra/commit/c938d34739936c8ecbabd67ad6a4a4396f41c4c6), [`1d9a0ea`](https://github.com/mastra-ai/mastra/commit/1d9a0ea4a9901baee6cd56737243bd6d1f631ac0), [`3667679`](https://github.com/mastra-ai/mastra/commit/3667679db057edfb086846d13369fdda4902ad65), [`49696e8`](https://github.com/mastra-ai/mastra/commit/49696e8e42f870674a0a58f5abcd22cc54dd2864), [`512100a`](https://github.com/mastra-ai/mastra/commit/512100a7d8b7e9c920f2590c6b3612f5de0d3cff), [`9ef432b`](https://github.com/mastra-ai/mastra/commit/9ef432b6faa534b57b0d182a610e13dd9a7123ff), [`b9cf308`](https://github.com/mastra-ai/mastra/commit/b9cf30846f97f99ac1906ee8a68f4f2d117b0378)]:
+  - @mastra/core@1.60.0-alpha.2
+
 ## 1.20.0
 
 ### Minor Changes

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.20.0"
+  version: "1.20.1-alpha.0"
 ---
 
 ## When to use
@@ -19,7 +19,7 @@ Read the individual reference documents for detailed explanations and code examp
 - [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 overview](references/docs-storage-overview.md) - Configure storage for Mastra to persist runtime state across agents, workflows, observability, evals, schedules, and memory.
+- [Storage](references/docs-storage-overview.md) - Configure storage for Mastra to persist runtime state across agents, workflows, observability, evals, schedules, and memory.
 
 ### Integrations
 

package/dist/docs/assets/SOURCE_MAP.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.20.0",
+  "version": "1.20.1-alpha.0",
   "package": "@mastra/pg",
   "exports": {},
   "modules": {}

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

@@ -106,19 +106,266 @@ Run the same build artifact in multiple containers, each with a different [`MAST
 
 Split deployments require a distributed PubSub backend ([`RedisStreamsPubSub`](https://mastra.ai/reference/pubsub/redis-streams) or [`GoogleCloudPubSub`](https://mastra.ai/reference/pubsub/google-cloud-pubsub)), a shared [storage backend](https://mastra.ai/reference/workers/overview), and network connectivity between the orchestration worker and the API.
 
-The [worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers) walks through this setup with Docker Compose and Kubernetes examples.
+### Select workers
+
+Set [`MASTRA_WORKERS`](https://mastra.ai/reference/workers/overview) to control which workers run in each process:
+
+| Value                           | Behavior                                                                       |
+| ------------------------------- | ------------------------------------------------------------------------------ |
+| `false`                         | Disable all workers. Use this for the API process in a fully split deployment. |
+| `orchestration`                 | Start the orchestration worker.                                                |
+| `scheduler`                     | Start the scheduler worker.                                                    |
+| `backgroundTasks`               | Start the background task worker.                                              |
+| `orchestration,backgroundTasks` | Start multiple workers from a comma-separated allowlist.                       |
+
+You can also pass a worker name to the CLI. The command sets `MASTRA_WORKERS` in the spawned process:
+
+```bash
+mastra worker start orchestration
+```
 
 ## Network architecture
 
-Workers are internal infrastructure. They're not exposed to end users and don't need their own subdomain, public URL, or inbound HTTP route.
+Workers are internal infrastructure. They're not exposed to end users and don't need their own subdomain or public URL, including an inbound HTTP route.
 
 In a split deployment:
 
-- **The API server is the only public-facing process**: It serves all client HTTP requests, including REST endpoints, agent interactions, workflow triggers, and any custom routes.
+- **The API server is the only public-facing process**: It serves all client HTTP requests. These requests include REST endpoints and agent interactions, plus workflow triggers and custom routes.
 - **Workers connect outbound only**: They pull events from the distributed PubSub backend and read/write to the shared storage database. They don't accept inbound traffic from clients.
 - **The orchestration worker calls the API internally**: It sends step execution requests to the API over the container network using `MASTRA_STEP_EXECUTION_URL`. This is internal service-to-service communication, not a public endpoint.
 
-All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. If a worker-related feature needs an HTTP route (for example, token minting for a voice integration), that route runs on the API server, not on the worker process.
+All three worker types (orchestration, scheduler, background task) sit behind the API on a private network. They share access to the PubSub backend and storage database but never receive traffic directly from clients. HTTP routes for worker-related features run on the API server rather than the worker process. One example is token minting for a voice integration.
+
+## Deploy split workers
+
+Build the API and worker artifacts:
+
+```bash
+mastra build
+mastra worker build --output-dir .mastra/worker
+```
+
+`mastra build` creates the API artifact in `.mastra/output/`. [`mastra worker build`](https://mastra.ai/reference/cli/mastra) creates a worker artifact in `.mastra/worker/`. The following Dockerfile accepts either directory:
+
+```dockerfile
+FROM node:22-alpine
+
+ARG MASTRA_OUTPUT=.mastra/output
+
+WORKDIR /app
+
+COPY ${MASTRA_OUTPUT}/package.json ${MASTRA_OUTPUT}/.npmrc* ./
+RUN npm install --omit=dev
+
+COPY ${MASTRA_OUTPUT}/ .
+
+EXPOSE 4111
+CMD ["node", "index.mjs"]
+```
+
+See [Deploy a Mastra server](https://mastra.ai/docs/deployment/mastra-server) for more information about the build output.
+
+### Docker Compose
+
+The following configuration runs PostgreSQL, Redis, the API, and one process for each worker type. Every process uses shared infrastructure, and the worker processes use the worker artifact.
+
+```yaml
+x-worker: &worker
+  build:
+    context: .
+    args:
+      MASTRA_OUTPUT: .mastra/worker
+
+x-mastra-environment: &shared-environment
+  DATABASE_URL: postgres://mastra:${POSTGRES_PASSWORD}@postgres:5432/mastra
+  REDIS_URL: redis://redis:6379
+
+services:
+  postgres:
+    image: postgres:16-alpine
+    environment:
+      POSTGRES_USER: mastra
+      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
+      POSTGRES_DB: mastra
+    volumes:
+      - pgdata:/var/lib/postgresql/data
+    healthcheck:
+      test: ['CMD-SHELL', 'pg_isready -U mastra']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  redis:
+    image: redis:7-alpine
+    healthcheck:
+      test: ['CMD', 'redis-cli', 'ping']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  api:
+    build:
+      context: .
+      args:
+        MASTRA_OUTPUT: .mastra/output
+    ports:
+      - '4111:4111'
+    environment:
+      <<: *shared-environment
+      WORKER_TOKEN: ${WORKER_TOKEN}
+      MASTRA_WORKERS: 'false'
+    depends_on:
+      postgres:
+        condition: service_healthy
+      redis:
+        condition: service_healthy
+    healthcheck:
+      test: ['CMD', 'wget', '-qO-', 'http://localhost:4111/api/agents']
+      interval: 5s
+      timeout: 3s
+      retries: 5
+
+  orchestration-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: orchestration
+      MASTRA_STEP_EXECUTION_URL: http://api:4111/api
+      MASTRA_WORKER_AUTH_TOKEN: ${WORKER_TOKEN}
+    depends_on:
+      api:
+        condition: service_healthy
+
+  scheduler-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: scheduler
+    depends_on:
+      api:
+        condition: service_healthy
+
+  background-task-worker:
+    <<: *worker
+    environment:
+      <<: *shared-environment
+      MASTRA_WORKERS: backgroundTasks
+    depends_on:
+      api:
+        condition: service_healthy
+
+volumes:
+  pgdata:
+```
+
+Set the secrets next to `docker-compose.yml`, along with any model provider credentials your application needs:
+
+```bash
+POSTGRES_PASSWORD=your-secure-password
+WORKER_TOKEN=your-shared-secret-token
+```
+
+Configure the API auth provider to accept `WORKER_TOKEN` before exposing the deployment. The orchestration worker sends the same value through `MASTRA_WORKER_AUTH_TOKEN`. The scheduler and background task workers don't call the step execution endpoint in this pull-based topology, so they don't need that variable.
+
+Start the stack and verify that the containers and API are available:
+
+```bash
+docker compose up -d
+docker compose ps
+curl http://localhost:4111/api/agents
+```
+
+### Kubernetes
+
+Create separate Deployments for the API, orchestration worker, scheduler worker, and background task worker. Use the same image and Secret for each Deployment. Set only the role-specific environment variables directly on each container.
+
+The orchestration worker Deployment has the following shape:
+
+```yaml
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: orchestration-worker
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: orchestration-worker
+  template:
+    metadata:
+      labels:
+        app: orchestration-worker
+    spec:
+      containers:
+        - name: worker
+          image: your-registry/mastra-workers:latest
+          env:
+            - name: MASTRA_WORKERS
+              value: orchestration
+            - name: MASTRA_STEP_EXECUTION_URL
+              value: http://api:4111/api
+          envFrom:
+            - secretRef:
+                name: mastra-secrets
+          resources:
+            requests:
+              cpu: 250m
+              memory: 256Mi
+```
+
+Use `MASTRA_WORKERS: scheduler` and `MASTRA_WORKERS: backgroundTasks` for the other worker Deployments. Set `MASTRA_WORKERS: 'false'` on the API Deployment and expose the API with a Service. Give every process access to the same database and PubSub backend. Configure the API auth provider with a worker token, then expose that token to the orchestration worker as `MASTRA_WORKER_AUTH_TOKEN`. See [Deploy Mastra to Kubernetes](https://mastra.ai/integrations/deploy/kubernetes) for the base Kubernetes resources.
+
+Apply the manifests, then verify the pods and API:
+
+```bash
+kubectl apply -f k8s/
+kubectl get pods
+kubectl port-forward svc/api 4111:4111
+```
+
+In a separate terminal, request an API route:
+
+```bash
+curl http://localhost:4111/api/agents
+```
+
+### Step execution URL
+
+In a fully split deployment, the orchestration worker delegates workflow step execution to the API over HTTP. Set `MASTRA_STEP_EXECUTION_URL` to the API's internal URL, including the `/api` prefix:
+
+```bash
+MASTRA_STEP_EXECUTION_URL=http://api:4111/api
+```
+
+Without this variable, the orchestration worker attempts to execute steps in its own process, which doesn't have access to the full Mastra runtime in a split deployment.
+
+The endpoint uses the server's normal auth pipeline. If the API has an auth provider, set `MASTRA_WORKER_AUTH_TOKEN` to a bearer token that provider accepts. Mastra forwards the value as an `Authorization: Bearer` credential. The configured auth provider validates the token. See [Worker authentication](https://mastra.ai/docs/server/auth/workers) for server configuration and other credential formats.
+
+### Scale workers
+
+The orchestration and background task workers can scale horizontally. PubSub consumer groups distribute events across their instances:
+
+```bash
+docker compose up -d --scale orchestration-worker=3
+docker compose up -d --scale background-task-worker=2
+```
+
+For Kubernetes, change the Deployment replica count manually or use a HorizontalPodAutoscaler:
+
+```bash
+kubectl scale deployment/orchestration-worker --replicas=3
+kubectl scale deployment/background-task-worker --replicas=2
+```
+
+Run exactly one scheduler worker. Multiple schedulers polling the same storage can publish duplicate events for a schedule.
+
+### Crash recovery
+
+A distributed PubSub backend persists unacknowledged events, which lets orchestration and background task workers resume after a restart. When the API is unavailable, a failed step-execution request causes the event to be delivered again. Because an event can be processed more than once, handlers should be idempotent when possible.
+
+The scheduler calculates the next fire time from the current time after it restarts. It doesn't replay schedules that elapsed while it was unavailable.
+
+If the API crashes while a step is executing, that work can be lost and the workflow run can remain in a `running` state. See [known limitations](#known-limitations) and [durable agent crash recovery](https://mastra.ai/docs/long-running-agents/durable-agents).
 
 ## Known limitations
 
@@ -129,7 +376,6 @@ All three worker types (orchestration, scheduler, background task) sit behind th
 
 ## Related
 
-- [Worker deployment guide](https://mastra.ai/guides/deployment/mastra-workers): Docker Compose and Kubernetes examples
 - [Worker authentication](https://mastra.ai/docs/server/auth/workers): Secure worker-to-API communication
 - [Workers reference](https://mastra.ai/reference/workers/overview): Details about worker environment variables and types, with a list of supported storage backends
 - [CLI reference](https://mastra.ai/reference/cli/mastra): `mastra worker build` and `mastra worker start`

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

@@ -270,7 +270,7 @@ Supported embedding models:
 
 - **OpenAI**: `text-embedding-3-small`, `text-embedding-3-large`, `text-embedding-ada-002`
 - **Google**: `gemini-embedding-001`
-- **OpenRouter**: Access embedding models from various providers
+- **OpenRouter**: Access embedding models from multiple providers
 
 ```ts
 import { Agent } from '@mastra/core/agent'

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

@@ -1,6 +1,6 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Working Memory
+# Working memory
 
 While [message history](https://mastra.ai/docs/memory/message-history) and [semantic recall](https://mastra.ai/docs/memory/semantic-recall) help agents remember conversations, working memory allows them to maintain persistent information about users across interactions.
 
@@ -213,7 +213,7 @@ const paragraphMemory = new Memory({
 
 ## Structured working memory
 
-Working memory can also be defined using a structured schema instead of a Markdown template. This allows you to specify the exact fields and types that should be tracked, using a [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.). When using a schema, the agent will see and update working memory as a JSON object matching your schema.
+Working memory can also be defined using a structured schema instead of a Markdown template. A [Standard JSON Schema](https://standardschema.dev/json-schema) ([Zod](https://zod.dev/), [Valibot](https://valibot.dev/), [ArkType](https://arktype.io/), etc.). When using a schema, the agent will see and update working memory as a JSON object matching your schema.
 
 **Requirement:** You must specify either `template` or `schema`, but not both.
 

package/dist/docs/references/docs-storage-overview.md

@@ -1,6 +1,6 @@
 > Discover all available pages from the documentation index: https://mastra.ai/llms.txt
 
-# Storage overview
+# Storage
 
 Storage is the persistence layer for the Mastra runtime. It keeps memory, workflow state, observability data, eval results, schedules, and long-running agent state available after a process restarts.
 
@@ -188,25 +188,26 @@ You can also route `observability` to a dedicated analytics backend. See the [ob
 
 ## Supported providers
 
-Each provider page includes installation instructions, configuration parameters, and usage examples:
+Each provider page includes installation instructions, configuration parameters, and usage examples. libSQL is the fastest path for local development because it doesn't require running a separate database server.
 
+- [Aurora DSQL](https://mastra.ai/integrations/databases/aurora-dsql)
+- [ClickHouse](https://mastra.ai/integrations/databases/clickhouse)
 - [Cloudflare D1](https://mastra.ai/integrations/databases/cloudflare-d1)
-- [Cloudflare KV & Durable Objects](https://mastra.ai/integrations/databases/cloudflare-kv)
+- [Cloudflare KV](https://mastra.ai/integrations/databases/cloudflare-kv)
 - [Convex](https://mastra.ai/integrations/databases/convex)
+- [DuckDB](https://mastra.ai/integrations/databases/duckdb)
 - [DynamoDB](https://mastra.ai/integrations/databases/dynamodb)
 - [Google Cloud Spanner](https://mastra.ai/integrations/databases/spanner)
 - [LanceDB](https://mastra.ai/integrations/databases/lancedb)
 - [libSQL](https://mastra.ai/integrations/databases/libsql)
-- [Microsoft SQL Server](https://mastra.ai/integrations/databases/mssql)
 - [MongoDB](https://mastra.ai/integrations/databases/mongodb)
+- [MSSQL](https://mastra.ai/integrations/databases/mssql)
 - [Neon Postgres](https://mastra.ai/integrations/databases/neon)
 - [OracleDB](https://mastra.ai/integrations/databases/oracledb)
 - [PostgreSQL](https://mastra.ai/integrations/databases/postgresql)
 - [Redis](https://mastra.ai/integrations/databases/redis)
 - [Upstash](https://mastra.ai/integrations/databases/upstash)
 
-> **Tip:** libSQL is the fastest path for local development because it doesn't require running a separate database server.
-
 ## Next steps
 
 - [Composite storage](https://mastra.ai/reference/storage/composite)

package/dist/docs/references/integrations-databases-postgresql.md

@@ -407,8 +407,9 @@ PostgreSQL storage creates composite indexes during initialization for common qu
 - `mastra_ai_spans_name_startedat_idx`: (name, startedAt DESC)
 - `mastra_ai_spans_scope_startedat_idx`: (scope, startedAt DESC)
 - `mastra_scores_trace_id_span_id_created_at_idx`: (traceId, spanId, createdAt DESC)
+- `mastra_workflow_snapshot_name_createdat_idx`: (workflow\_name, createdAt DESC)
 
-These indexes improve performance for filtered queries with sorting, including `dateRange` filters on message queries.
+These indexes improve performance for filtered queries with sorting, including `dateRange` filters on message queries and Studio's workflow runs-list.
 
 ### Configuring Indexes
 
@@ -521,11 +522,11 @@ const stats = await storage.db.one(`
 
 PostgreSQL offers different index types optimized for specific scenarios:
 
-| Index Type          | Best For                                | Storage    | Speed                      |
-| ------------------- | --------------------------------------- | ---------- | -------------------------- |
-| **btree** (default) | Range queries, sorting, general purpose | Moderate   | Fast                       |
-| **hash**            | Equality comparisons only               | Small      | Very fast for `=`          |
-| **gin**             | JSONB, arrays, full-text search         | Large      | Fast for contains          |
-| **gist**            | Geometric data, full-text search        | Moderate   | Fast for nearest-neighbor  |
-| **spgist**          | Non-balanced data, text patterns        | Small      | Fast for specific patterns |
-| **brin**            | Large tables with natural ordering      | Very small | Fast for ranges            |
+| Index Type          | Best For                                | Storage size | Speed                      |
+| ------------------- | --------------------------------------- | ------------ | -------------------------- |
+| **btree** (default) | Range queries, sorting, general purpose | Moderate     | Fast                       |
+| **hash**            | Equality comparisons only               | Small        | Very fast for `=`          |
+| **gin**             | JSONB, arrays, full-text search         | Large        | Fast for contains          |
+| **gist**            | Geometric data, full-text search        | Moderate     | Fast for nearest-neighbor  |
+| **spgist**          | Non-balanced data, text patterns        | Small        | Fast for specific patterns |
+| **brin**            | Large tables with natural ordering      | Very small   | Fast for ranges            |

package/dist/docs/references/reference-rag-chunking-and-embedding.md

@@ -127,7 +127,7 @@ const { embeddings } = await embedMany({
 })
 ```
 
-> **Vector Database Compatibility:** When storing embeddings, the vector database index must be configured to match the output size of your embedding model. If the dimensions don't match, you may get errors or data corruption.
+> **Vector Database Compatibility:** When storing embeddings, configure the vector database index to match the output size of your embedding model to avoid errors or data corruption from mismatched dimensions.
 
 ## Example: Complete pipeline
 

package/dist/docs/references/reference-rag-metadata-filters.md

@@ -201,7 +201,7 @@ const results = await store.query({
 ### Amazon S3 Vectors
 
 - Equality values must be primitives (string/number/boolean). `null`/`undefined`, arrays, objects, and Date aren't allowed for equality. Range operators accept numbers or Date (Dates are normalized to epoch ms).
-- `$in`/`$nin` require **non-empty arrays of primitives**; Date elements are allowed and normalized to epoch ms. **Array equality** isn't supported.
+- `$in`/`$nin` require **non-empty arrays of primitives**. Date elements are allowed and normalized to epoch ms. **Array equality** isn't supported.
 - Implicit AND is canonicalized (`{a:1,b:2}` → `{$and:[{a:1},{b:2}]`). Logical operators must contain field conditions and use non-empty arrays. They may appear only at the root or within other logical operators (not inside field values).
 - Keys listed in `nonFilterableMetadataKeys` at index creation are stored but not filterable. This setting is immutable.
 - $exists requires a boolean value.

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

@@ -234,7 +234,7 @@ const storage = new MongoDBStore({
 
 `prune()` deletes rows but doesn't shrink the database file. On SQLite/libSQL the freed pages go on a freelist and are reused by future writes, so the file stops growing: for most users this alone solves the unbounded-growth problem.
 
-Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself in a maintenance window. A full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically; a manual `VACUUM FULL` is only needed if you must return disk to the OS.
+Handing that free space back to the OS is a separate concern that Mastra doesn't manage. If you specifically need to shrink the file, run the underlying database's compaction (for example `VACUUM` on self-hosted libSQL) yourself in a maintenance window. A full `VACUUM` locks the file and needs roughly twice the file size in free disk. On PostgreSQL, autovacuum reclaims dead tuples for reuse automatically. A manual `VACUUM FULL` is only needed if you must return disk to the OS.
 
 For MongoDB, deleted documents are reused by future insertions. To reclaim disk space, run [`db.runCommand({ compact: "collection_name" })`](https://www.mongodb.com/docs/manual/reference/command/compact/) during a maintenance window.
 

package/dist/docs/references/reference-tools-vector-query-tool.md

@@ -353,7 +353,7 @@ const response = await agent.generate('Find information about deployment', {
 })
 ```
 
-This approach allows you to:
+Runtime configuration supports these use cases:
 
 - Switch between environments (dev/staging/prod)
 - Adjust performance parameters based on load

package/dist/docs/references/reference-vectors-pg.md

@@ -350,7 +350,7 @@ The `PgVector` class exposes its underlying PostgreSQL connection pool as a publ
 pgVector.pool // instance of pg.Pool
 ```
 
-This enables advanced usage such as running direct SQL queries, managing transactions, or monitoring pool state. When using the pool directly:
+Direct pool access supports advanced operations such as direct SQL queries, transactions, or pool-state monitoring. When using the pool directly:
 
 - You are responsible for releasing clients (`client.release()`) after use.
 - The pool remains accessible after calling `disconnect()`, but new queries will fail.

package/dist/index.cjs

@@ -19382,33 +19382,47 @@ var WorkflowsPG = class WorkflowsPG extends _mastra_core_storage.WorkflowsStorag
 			updatedAt: new Date(row.updatedAtZ || row.updatedAt)
 		};
 	}
+	static getDefaultIndexDefs(schemaPrefix) {
+		return [{
+			name: `${schemaPrefix}mastra_workflow_snapshot_name_createdat_idx`,
+			table: _mastra_core_storage.TABLE_WORKFLOW_SNAPSHOT,
+			columns: ["workflow_name", "createdAt DESC"]
+		}];
+	}
 	/**
 	* Returns all DDL statements for this domain: table with unique constraint.
 	* Used by exportSchemas to produce a complete, reproducible schema export.
 	*/
 	static getExportDDL(schemaName) {
 		const statements = [];
+		const parsedSchema = schemaName ? (0, _mastra_core_utils.parseSqlIdentifier)(schemaName, "schema name") : "";
+		const schemaPrefix = parsedSchema && parsedSchema !== "public" ? `${parsedSchema}_` : "";
 		statements.push(generateTableSQL({
 			tableName: _mastra_core_storage.TABLE_WORKFLOW_SNAPSHOT,
 			schema: _mastra_core_storage.TABLE_SCHEMAS[_mastra_core_storage.TABLE_WORKFLOW_SNAPSHOT],
 			schemaName,
 			includeAllConstraints: true
 		}));
+		for (const idx of WorkflowsPG.getDefaultIndexDefs(schemaPrefix)) statements.push(generateIndexSQL(idx, schemaName));
 		return statements;
 	}
 	/**
 	* Returns default index definitions for the workflows domain tables.
-	* Currently no default indexes are defined for workflows.
 	*/
 	getDefaultIndexDefinitions() {
-		return [];
+		const schemaPrefix = this.#schema !== "public" ? `${this.#schema}_` : "";
+		return WorkflowsPG.getDefaultIndexDefs(schemaPrefix);
 	}
 	/**
 	* Creates default indexes for optimal query performance.
-	* Currently no default indexes are defined for workflows.
 	*/
 	async createDefaultIndexes() {
 		if (this.#skipDefaultIndexes) return;
+		for (const indexDef of this.getDefaultIndexDefinitions()) try {
+			await this.#db.createIndex(indexDef);
+		} catch (error) {
+			this.logger?.warn?.(`Failed to create index ${indexDef.name}:`, error);
+		}
 	}
 	async init() {
 		await this.#db.createTable({