Source profileQuality 96/100

awslabs/agent-plugins/plugins/databases-on-aws/skills/dsql/SKILL.md

dsql

Build with Aurora DSQL — manage schemas, execute queries, handle migrations, diagnose query plans, diagnose cluster performance, load data, and develop applications with a serverless, distributed SQL database. Covers IAM auth, multi-tenant patterns, MySQL-to-DSQL and PostgreSQL-to-DSQL schema conversion, FK replacement code generation, OCC retry patterns, ORM migration (Django/EF Core/Hibernate/Rails), DDL operations, query plan explainability, system diagnostics via CloudWatch AAS, SQL compatib

Source repository stars
868
Declared platforms
0
Static risk flags
0
Last source update
2026-08-25
Source checked
2026-08-25

Decision brief

What it does: where it fits

Aurora DSQL is a serverless, PostgreSQL-compatible distributed SQL database. This skill covers direct query execution via MCP tools, schema management, migrations, multi-tenant isolation, IAM auth, and bulk data loading via aurora-dsql-loader.

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/awslabs/agent-plugins --skill "plugins/databases-on-aws/skills/dsql"
    Safe inspection promptEditorial

    Inspect the Agent Skill "dsql" from https://github.com/awslabs/agent-plugins/blob/a35c295c62452468446d3a3fa7e2590cd27474ab/plugins/databases-on-aws/skills/dsql/SKILL.md at commit a35c295c62452468446d3a3fa7e2590cd27474ab. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Choosing How to Connect: MCP vs CLI/psql

      The aurora-dsql MCP server binds a single cluster at startup (--clusterendpoint), so using it for another cluster means editing .mcp.json and restarting the session.

      Use the aurora-dsql MCP tools (readonlyquery, transact, getschema) ONLY when theOtherwise — unconfigured, disabled, or bound to a different cluster — do NOT reconfigure it.If you cannot confirm which cluster the MCP targets, confirm first or use the CLI/psql path —
    2. 02

      Quick Start

      0. Pick a connection path: confirm the aurora-dsql MCP targets your cluster; if not, use the CLI/psql path instead — see Choosing How to Connect. The steps below name MCP tools; the equivalent SQL runs the same way through psql-connect.sh --command "...". 1. Explore: Use readonl…

      Pick a connection path: confirm the aurora-dsql MCP targets your cluster; if not, use the CLI/psql path instead — see Choosing How to Connect. The steps below name MCP tools; the equivalent SQL runs the same way through…Explore: Use readonlyquery with informationschema to list tables. Use getschema for table structure.Query: Use readonlyquery for SELECT queries. MUST include tenantid in WHERE for multi-tenant apps. MUST build SQL with safequery.build().
    3. 03

      Workflow 1: Create Multi-Tenant Schema

      1. Create main table with tenantid column using transact 2. Create async index on tenantid in separate transact call 3. Create composite indexes for common query patterns (separate transact calls) 4. Verify schema with getschema

      Create main table with tenantid column using transactCreate async index on tenantid in separate transact callCreate composite indexes for common query patterns (separate transact calls)
    4. 04

      Workflow 2: Safe Data Migration

      MUST validate every DDL with dsqllint(fix=true) before executing. DML does not require linting.

      Validate DDL with dsqllint(sql=..., fix=true) — handle diagnostics per dsql-lint.mdAdd column: transact(["ALTER TABLE ... ADD COLUMN ..."])Populate existing rows with UPDATE (batched under 3,000 rows)
    5. 05

      Workflow 3: Bulk Data Loading

      Use aurora-dsql-loader for CSV, TSV, or Parquet loads. MUST load data-loading.md before advising on throughput or diagnosing slow loads.

      Validate with --dry-run firstRun with --manifest-dir on persistent storage (not /tmp — tmpfs on AL2023, lost on crash) and --header if file has a header rowOn failure: resume with --resume-job-id; for duplicates use --on-conflict do-nothing

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score96/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars868SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    awslabs/agent-plugins
    Skill path
    plugins/databases-on-aws/skills/dsql/SKILL.md
    Commit
    a35c295c62452468446d3a3fa7e2590cd27474ab
    License
    Apache-2.0
    Collected
    2026-08-25
    Default branch
    main
    View the original SKILL.md

    Amazon Aurora DSQL Skill

    Aurora DSQL is a serverless, PostgreSQL-compatible distributed SQL database. This skill covers direct query execution via MCP tools, schema management, migrations, multi-tenant isolation, IAM auth, and bulk data loading via aurora-dsql-loader.


    Reference Files

    Load these files as needed for detailed guidance:

    Core:

    ReferenceWhen to LoadContains
    development-guide.mdALWAYS before schema changes or DB operationsBest practices, DDL rules, transaction limits, app-layer referential integrity
    language.mdMUST load for language-specific choicesDriver selection, DSQL Connectors, connection code
    access-control.mdMUST load for roles, grants, or sensitive dataScoped role setup, IAM-to-database role mapping
    troubleshooting.mdSHOULD load for errors or unexpected behaviorOCC errors, connection failures, cluster state errors, token expiry, DDL rejection causes
    dsql-examples.mdLoad for implementation examplesMulti-tenant schema examples, batch operations, FK validation patterns, connection pooling
    onboarding.mdUser requests "Get started with DSQL"Interactive step-by-step guide
    occ-retry-patterns.mdMUST load for OCC retry code or conflict mitigationDSQL Connectors, manual retry pattern, idempotent design

    MCP:

    ReferenceWhen to LoadContains
    mcp-setup.mdAlways for MCP server guidanceSetup instructions, 2 configuration options
    mcp-tools.mdFor MCP tool syntax and examplesTool parameters, input validation
    dsql-lint.mdMUST load before running dsql_lint or processing external SQLTool reference, fix statuses, unfixable error resolution

    DDL Migrations:

    ReferenceWhen to LoadContains
    ddl-migrations/overview.mdMUST load for DROP COLUMN, ALTER TYPE, DROP CONSTRAINTTable recreation pattern, verify & swap
    ddl-migrations/column-operations.mdDROP COLUMN, ALTER TYPE, SET/DROP NOT NULL/DEFAULTColumn-level migration patterns
    ddl-migrations/constraint-operations.mdADD/DROP CONSTRAINT, VALIDATE CONSTRAINT, MODIFY PRIMARY KEYConstraint and structural changes
    ddl-migrations/batched-migration.mdTables exceeding 3,000 rowsBatching patterns, progress tracking

    MySQL Migrations:

    ReferenceWhen to LoadContains
    mysql-migrations/type-mapping.mdMUST load for MySQL → DSQL migrationData type mappings, feature alternatives
    mysql-migrations/ddl-operations.mdTranslating MySQL DDL to DSQLAUTO_INCREMENT, ENUM, SET, FK patterns
    mysql-migrations/full-example.mdComplete MySQL table migrationEnd-to-end example with decision summary

    PostgreSQL Migrations:

    ReferenceWhen to LoadContains
    pg-migrations/type-mapping.mdMUST load for PG → DSQL type questionsC collation rules, NUMERIC precision, JSON/JSONB
    pg-migrations/fk-replacement.mdMUST load for FK validation code generationTenant-scoped validate_fk_*() template, cascade
    pg-migrations/index-conversion.mdMUST load for unfixable index diagnosticsGIN/GiST/BRIN → btree, partial, expression indexes
    pg-migrations/schema-objects.mdMUST load for ENUM, materialized views, extensions, multi-schemaENUM → CHECK, views, role/IAM mapping
    pg-migrations/multi-region.mdMulti-region, active-active, or HA questionsArchitecture, geographic partitioning

    ORM Guides:

    ReferenceWhen to LoadContains
    orm-guides/overview.mdMigrating any ORM to DSQLAdapter names, key gotchas for Django/EF Core/Hibernate/Rails/SQLAlchemy

    Data Loading:

    ReferenceWhen to LoadContains
    data-loading.mdPlanning or running bulk loads with aurora-dsql-loaderFresh-vs-warm partitions, resume/retry, --on-conflict semantics, throughput diagnostics

    System Diagnostics:

    ReferenceWhen to LoadContains
    system-diagnostics/workflow.mdMUST load at Workflow 12 entry — cluster performance diagnosticsPrerequisites, 5 diagnostic phases, temporal comparison, handoff
    system-diagnostics/wait-events.mdALWAYS load when interpreting AAS resultsCanonical DSQL wait event descriptions and investigation guidance
    system-diagnostics/promql-patterns.mdLoad when constructing PromQL queriesReusable query templates for AAS breakdown, top-SQL, temporal compare

    Query Plan Explainability:

    ReferenceWhen to LoadContains
    query-plan/workflow.mdMUST load at Workflow 9 entry — gates all other filesTrigger criteria, context disambiguation, routing, phased workflow
    query-plan/plan-interpretation.mdMUST load at Workflow 9 Phase 0DSQL node types, Node Duration math, estimation-error bands
    query-plan/catalog-queries.mdMUST load at Workflow 9 Phase 0pg_class/pg_stats/pg_indexes SQL, correlated-predicate verification
    query-plan/guc-experiments.mdMUST load at Workflow 9 Phase 0GUC experiment procedures, 30-second skip protocol
    query-plan/report-format.mdMUST load at Workflow 9 Phase 0Required report structure, element checklist, support request template
    query-plan/query-rewrites-generic.mdSHOULD load at Phase 0; sub-files on-demandIndex of 10 generic rewrite patterns
    query-plan/query-rewrites-dsql-specific.mdSHOULD load at Phase 0; sub-files on-demandIndex of DSQL-specific rewrite patterns

    Choosing How to Connect: MCP vs CLI/psql

    The aurora-dsql MCP server binds a single cluster at startup (--cluster_endpoint), so using it for another cluster means editing .mcp.json and restarting the session.

    • Use the aurora-dsql MCP tools (readonly_query, transact, get_schema) ONLY when the server already targets the cluster you need.
    • Otherwise — unconfigured, disabled, or bound to a different cluster — do NOT reconfigure it. Use the CLI + psql path instead: scripts/psql-connect.sh <cluster-id> --region <region> --command "SELECT ..." (mints an IAM token and runs via psql).
    • If you cannot confirm which cluster the MCP targets, confirm first or use the CLI/psql path — running against the wrong cluster is worse than the check.

    The doc-only MCP tools (dsql_lint, dsql_*_documentation, dsql_recommend) need no cluster. The CloudWatch MCP (Workflow 12) takes region/cluster_id per call, so one running server can query clusters in any PromQL-enabled region (pass each cluster's region on the call). Details: connectivity-tools.md.

    MCP Tools Available

    The aurora-dsql MCP server provides these tools:

    Database Operations:

    1. readonly_query - Execute SELECT queries (returns list of dicts)
    2. transact - Execute DDL/DML statements in transaction (takes list of SQL statements)
    3. get_schema - Get table structure for a specific table

    SQL Validation:

    1. dsql_lint - Validate SQL for DSQL compatibility and optionally auto-fix issues. Use before executing externally-sourced SQL.

    Documentation & Knowledge:

    1. dsql_search_documentation - Search Aurora DSQL documentation
    2. dsql_read_documentation - Read specific documentation pages
    3. dsql_recommend - Get DSQL best practice recommendations

    Note: There is no list_tables tool. Use readonly_query with information_schema.

    See mcp-setup.md for detailed setup instructions. See mcp-tools.md for detailed usage and examples.

    AWS Knowledge MCP (awsknowledge)

    Consult for verifying DSQL service limits before advising users. The numeric limits below are defaults that may change — when a user's decision depends on an exact limit, verify it first:

    LimitDefaultVerify query
    Max rows per transaction3,000aurora dsql transaction limits
    Max data size per transaction10 MiBaurora dsql transaction limits
    Max transaction duration5 minutesaurora dsql transaction limits
    Max connections per cluster10,000aurora dsql connection limits
    Auth token expiry15 minutesaurora dsql authentication token
    Max connection duration60 minutesaurora dsql connection limits
    Max indexes per table24aurora dsql index limits
    Max columns per index8aurora dsql index limits
    IDENTITY/SEQUENCE CACHE values1 or >= 65536aurora dsql sequence cache
    Supported column data typesSee docsaurora dsql supported data types

    When to verify: Before recommending batch sizes, connection pool settings, or schema designs where hitting a limit would cause failures; any time the exact number can affect user decision.

    Fallback: If awsknowledge is unavailable, use the defaults above and flag that limits should be verified against DSQL documentation.

    CLI Scripts Available

    Bash scripts in scripts/ for cluster management (create, delete, list, cluster info), psql connection, and bulk data loading from local/s3 csv/tsv/parquet files. See scripts/README.md for usage and hook configuration.


    Quick Start

    1. Pick a connection path: confirm the aurora-dsql MCP targets your cluster; if not, use the CLI/psql path instead — see Choosing How to Connect. The steps below name MCP tools; the equivalent SQL runs the same way through psql-connect.sh --command "...".
    2. Explore: Use readonly_query with information_schema to list tables. Use get_schema for table structure.
    3. Query: Use readonly_query for SELECT queries. MUST include tenant_id in WHERE for multi-tenant apps. MUST build SQL with safe_query.build().
    4. Schema changes: Use transact with one DDL per transaction. MUST batch DML under 3,000 rows. MUST use CREATE INDEX ASYNC in a separate call. Use dsql_lint to validate first.
    5. Bulk load data: Use aurora-dsql-loader for CSV/TSV/Parquet. Load data-loading.md for details. Use --dry-run first.

    Performance Routing

    When the user reports a performance problem, use this table to select the correct workflow:

    User signalRoute to
    General performance complaint, "cluster is slow", "something changed", latency regression, no specific query identifiedWorkflow 12 (System Diagnostics) — observe via CloudWatch first
    Specific query or query_id to investigate, "explain this plan", "why is this query slow"Workflow 9 (Query Plan Explainability) — direct EXPLAIN analysis
    OCC conflicts, commit errors, retry stormsWorkflow 12 (System Diagnostics) — confirm via CW metrics before investigating
    Cost optimization, "where is compute time spent"Workflow 12 (System Diagnostics) — identify top contributors first

    Rule: When in doubt, start with Workflow 12. It identifies specific queries to investigate and routes to Workflow 9 with context.


    Common Workflows

    Workflow 1: Create Multi-Tenant Schema

    1. Create main table with tenant_id column using transact
    2. Create async index on tenant_id in separate transact call
    3. Create composite indexes for common query patterns (separate transact calls)
    4. Verify schema with get_schema
    • MUST include tenant_id in all tables
    • MUST use CREATE INDEX ASYNC exclusively
    • MUST issue each DDL in its own transact call: transact(["CREATE TABLE ..."])
    • MUST serialize arrays into a single-column representation — DSQL has no array column type; PREFER JSONB (operators work directly); MAY use TEXT when the column is opaque to the database; ASK the user. For JSONB arrays, expand at query time with jsonb_array_elements_text(data)

    Workflow 2: Safe Data Migration

    MUST validate every DDL with dsql_lint(fix=true) before executing. DML does not require linting.

    1. Validate DDL with dsql_lint(sql=..., fix=true) — handle diagnostics per dsql-lint.md
    2. Add column: transact(["ALTER TABLE ... ADD COLUMN ..."])
    3. Populate existing rows with UPDATE (batched under 3,000 rows)
    4. Verify with readonly_query COUNT
    5. Create index if needed: validate then transact(["CREATE INDEX ASYNC ..."])
    • MUST issue each ALTER TABLE in its own transact call — DSQL rejects multi-DDL transactions with multiple ddl statements not supported in a transaction
    • MUST add column with only name and type; apply DEFAULT via separate UPDATE
    • MUST batch updates under 3,000 rows in separate transact calls

    Recovery: Resume failed batches by filtering WHERE new_column IS NULL.

    Workflow 3: Bulk Data Loading

    Use aurora-dsql-loader for CSV, TSV, or Parquet loads. MUST load data-loading.md before advising on throughput or diagnosing slow loads.

    1. Validate with --dry-run first
    2. Run with --manifest-dir on persistent storage (not /tmp — tmpfs on AL2023, lost on crash) and --header if file has a header row
    3. On failure: resume with --resume-job-id; for duplicates use --on-conflict do-nothing
    4. For large tables: create secondary indexes after load using CREATE INDEX ASYNC

    Workflow 4: Application-Layer Referential Integrity

    INSERT: MUST validate parent exists with readonly_query → throw error if not found → insert child with transact.

    DELETE: MUST check dependents with readonly_query COUNT → return error if dependents exist → delete with transact if safe.

    Workflow 5: Query with Tenant Isolation

    1. MUST authorize the caller against the tenant — format validation does not establish authorization
    2. MUST build SQL with safe_query.build() — use allow()/regex() for values (emits 'v'), ident() for table/column names (emits "v"). See input-validation.md
    3. MUST include tenant_id in the WHERE clause; reject cross-tenant access at the application layer

    Workflow 6: Set Up Scoped Database Roles

    MUST load access-control.md for role setup, IAM mapping, and schema permissions.

    Workflow 7: Table Recreation DDL Migration

    Use the Table Recreation Pattern for ALTER COLUMN TYPE, DROP COLUMN, DROP CONSTRAINT, or MODIFY PRIMARY KEY. This is a destructive workflow that requires user confirmation at each step. Every generated DDL in the pattern (CREATE new, INSERT ... SELECT, DROP old, RENAME) MUST be validated with dsql_lint(sql=..., fix=true) before execution.

    MUST load ddl-migrations/overview.md before attempting any of these operations.

    Workflow 8: Validate and Migrate to DSQL

    MUST load dsql-lint.md before running dsql_lint. Run dsql_lint(sql=source_sql, fix=true) to validate and auto-convert. For MySQL-origin SQL, MUST cross-check against mysql-migrations/type-mapping.md even when lint returns clean. On parse_error, fall back to manual conversion then re-lint.

    Workflow 9: Query Plan Explainability

    Explains why the DSQL optimizer chose a particular plan. Triggered by slow queries, high DPU, unexpected Full Scans, or plans the user doesn't understand. REQUIRES a structured Markdown diagnostic report as the deliverable.

    MUST load query-plan/workflow.md at entry — it defines trigger criteria, context disambiguation, routing, and the full phased workflow (Phase 0–4). Workflow.md specifies which reference files to load at each phase.

    Safety. Plan capture uses readonly_query exclusively. Rewrite DML to SELECT for plan capture. MUST NOT use transact --allow-writes for plan capture.

    Workflow 10: Full PostgreSQL → DSQL Schema Migration

    MUST load pg-migrations/type-mapping.md and pg-migrations/schema-objects.md. Run dsql_lint(fix=true) first for mechanical fixes, then apply semantic conversions from the pg-migrations references for unfixable diagnostics and patterns the linter cannot handle. Re-lint the final output before deploying.

    Workflow 11: ORM Migration (Django/EF Core/Hibernate/Rails)

    Load orm-guides/overview.md for adapter names and framework-specific gotchas.

    Workflow 12: System Diagnostics (CloudWatch AAS)

    Diagnose cluster performance by querying db.active_sessions.avg via PromQL. Detects temporal anomalies in wait event distribution, identifies regressed queries, and routes to Workflow 9 for per-query investigation.

    Requires: CloudWatch MCP server (awslabs.cloudwatch-mcp-server) enabled and configured with PromQL access in the same region as the cluster — see mcp/mcp-setup.md for enabling it, region requirements, and the session restart needed for its tools to register.

    MUST load system-diagnostics/workflow.md at entry — it defines prerequisites, 5 diagnostic phases, temporal baselines, and the routing to Workflow 9 for identified queries.

    Error Scenarios

    • awsknowledge returns no results: Use the default limits in the table above and note that limits should be verified against DSQL documentation.
    • dsql_lint unavailable or timing out: See the Error Handling section of dsql-lint.md. Do not silently skip validation — inform the user and require explicit confirmation before proceeding with manual rules from development-guide.md.
    • OCC serialization error: Retry the transaction. If persistent, check for hot-key contention — see troubleshooting.md.
    • Transaction exceeds limits: Split into batches under 3,000 rows — see batched-migration.md.
    • Token expiration mid-operation: Generate a fresh IAM token — see authentication-guide.md. See troubleshooting.md for other issues.

    Additional Resources

    Frequently asked questions

    What to verify before installation and use

    What does the dsql source document cover?

    Aurora DSQL is a serverless, PostgreSQL-compatible distributed SQL database. This skill covers direct query execution via MCP tools, schema management, migrations, multi-tenant isolation, IAM auth, and bulk data loading via aurora-dsql-loader.

    How do I install dsql?

    The source record exposes this install command: npx skills add https://github.com/awslabs/agent-plugins --skill "plugins/databases-on-aws/skills/dsql". Inspect the command and pinned source before running it.

    Alternatives

    Compare before choosing

    Computed 9834,322

    K-Dense-AI/scientific-agent-skills

    dask

    Distributed computing for larger-than-RAM pandas/NumPy workflows. Use when you need to scale existing pandas/NumPy code beyond memory or across clusters. Best for parallel file processing, distributed ML, integration with existing pandas code. For out-of-core analytics on single machine use vaex; for in-memory speed use polars.

    Computed 97149

    UiPath/skills

    uipath-coded-apps

    UiPath Coded Apps — scaffold, build, run, and deploy Coded Web Apps and Coded Action Apps: React/TypeScript apps that call UiPath Cloud APIs via the `@uipath/uipath-typescript` SDK and ship to Automation Cloud (push/pull to Studio Web, pack, publish, deploy, OAuth-PKCE). Also generates live analytics & governance dashboards from a plain-language request, wired to tenant data via the Insights real-time API, with edit and deploy flows. For RPA→uipath-rpa, Python agents→uipath-agents, Maestro flows

    Computed 953,766

    elementalsouls/Claude-BugHunter

    bb-local-toolkit

    Local-tooling companion to the bug-bounty orchestrator — carries the SAME complete bug-bounty workflow, but reach for THIS variant when you also need to resolve where tools, wordlists, and clones are installed on the local machine (jhaddix, SecLists, trufflehog, ffuf, dalfox, ghauri); for pure orchestration/routing use the bug-bounty skill. Workflow it covers — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports

    Computed 953,766

    elementalsouls/Claude-BugHunter

    bug-bounty

    Complete bug bounty workflow — recon (subdomain enumeration, asset discovery, fingerprinting, HackerOne scope, source code audit), pre-hunt learning (disclosed reports, tech stack research, mind maps, threat modeling), vulnerability hunting (IDOR, SSRF, XSS, auth bypass, CSRF, race conditions, SQLi, XXE, file upload, business logic, GraphQL, HTTP smuggling, cache poisoning, OAuth, timing side-channels, OIDC, SSTI, subdomain takeover, cloud misconfig, ATO chains, agentic AI), LLM/AI security test