AutoGineer
Generated banner for Dsql
Generated logo for Dsql

Dsql

AWS LabsOfficialPublished by AWS Labs

  • Skill
  • Tool integration
  • Data and AI
  • Apache-2.0
  • Low risk
  • Has scripts
Download ZIP

From the author

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, foreign key constraints, OCC retry patterns, ORM migration (Django/EF Core/Hibernate/Rails/SQLAlchemy), DDL operations, query plan explainability, system diagnostics via CloudWatch AAS, SQL compatibility validation, and bulk data loading. Load before answering DSQL limit or error-code questions; it has limits docs omit. Triggers on phrases like: DSQL, Aurora DSQL, distributed SQL database, serverless PostgreSQL-compatible database, migrate to DSQL, DSQL query plan, DSQL EXPLAIN ANALYZE, DSQL ENUM, DSQL foreign key, DSQL OCC retry, DSQL multi-region, DSQL JSONB, DSQL GIN index, load into DSQL, load CSV into DSQL, bulk load DSQL, aurora-dsql-loader, DSQL slow, DSQL performance, DSQL wait events, DSQL AAS.
— the description by AWS Labs

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The dsql skill provides a structured framework for interacting with Amazon Aurora DSQL. It encompasses schema management, migration strategies from MySQL and PostgreSQL, performance diagnostics, and bulk data loading. The skill integrates with MCP tools for direct database operations and provides extensive documentation on IAM authentication, multi-tenant patterns, and transaction management to ensure safe and efficient database operations.

What it does

  • Executes SQL queries and DDL operations via MCP tools.
  • Provides migration paths and type mapping for MySQL and PostgreSQL to DSQL.
  • Offers diagnostic workflows for cluster performance and query plan explainability.
  • Facilitates bulk data loading using specialized loaders.
  • Enforces best practices for IAM authentication and scoped database roles.
  • Validates SQL compatibility and provides linting for DSQL-specific constraints.

When to use it

  • When building or migrating applications to Aurora DSQL.
  • When performing schema changes or complex DDL migrations.
  • When troubleshooting performance issues or query plan inefficiencies.
  • When setting up multi-tenant database architectures.
  • When bulk loading data into a DSQL cluster.

Advantages

  • Ensures adherence to DSQL-specific transaction and concurrency limits.
  • Promotes secure access patterns through IAM and scoped roles.
  • Provides clear, phased workflows for complex tasks like performance tuning.
  • Reduces migration friction with automated linting and type mapping guidance.
  • Standardizes diagnostic reporting for query plan analysis.

Usage examples

“How do I migrate my existing PostgreSQL schema to Aurora DSQL?”
The agent will guide you through pg-migrations/type-mapping.md and schema-objects.md, providing steps to convert indexes, enums, and data types while ensuring compatibility.
“My query is running slowly on DSQL, can you help?”
The agent will initiate Workflow 9 (Query Plan Explainability) to analyze the query plan, check for full scans, and provide a structured diagnostic report.
“How do I set up a multi-tenant table in DSQL?”
The agent will provide instructions on using tenant_id in your schema design, enforcing it in WHERE clauses, and using separate transact calls for DDL.
“What are the transaction limits for DSQL?”
The agent will consult the limits-and-error-codes.md or awsknowledge tool to provide the exact limits for row modifications, data size, and duration.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/awslabs/dsql/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip dsql.zip -d .agents/skills

Documentation by AWS Labs

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, foreign key constraints
foreign-keys.mdMUST load for foreign key operations or migrationsFK syntax, actions, validation, tenant keys
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 and 23503, FK, connections, cluster state
limits-and-error-codes.mdSHOULD load before sizing batches, keys or indexes, or on 54000/0A000/54011Every limit, rejection and quota with SQLSTATE and exact message
dsql-examples.mdLoad for implementation examplesMulti-tenant access, batch operations, identity and sequences, 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 mitigationConnectors, 40001 retry, non-retryable 23503, FK read conflicts, 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 ALTER TYPE, SET NOT NULL, MODIFY PRIMARY KEYDirect ALTER coverage and last-resort table recreation
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 DSQL NUMERIC or PG type questionsC collation rules, NUMERIC(p,s), JSON/JSONB
pg-migrations/index-conversion.mdMUST load for any index conversion or index support questionGIN/GiST/BRIN → btree, operator class removal, partial + expression indexes, sort order
pg-migrations/schema-objects.mdMUST load for ENUM, materialized views, extensions, multi-schema, CREATE FUNCTIONENUM → CHECK, views, role/IAM mapping, LANGUAGE sql functions
pg-migrations/multi-region.mdMulti-region, active-active, or HA questionsArchitecture, geographic partitioning
ORM Guides:
ReferenceWhen to LoadContains
orm-guides/overview.mdMigrating an ORM or using ORM locking with DSQLAdapter names, locking, and 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 row modifications 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 table24 incl. PKaurora 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. For the full limit set with each SQLSTATE and its exact error message, see limits-and-error-codes.md; where it marks a value observed and the docs differ, use the observed value.

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 tenant-owned tables with tenant_id using separate transact calls

  2. Use composite tenant FKs for tenant-owned parents and ordinary FKs for shared parents

  3. Create tenant and query-pattern indexes with separate CREATE INDEX ASYNC calls

  4. Verify with get_schema

  • 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. Execute the reviewed fixed_sql when present, otherwise the reviewed source statement

  3. Add column in its own transact call

  4. Populate existing rows with UPDATE (batched under 3,000 rows)

  5. Verify with readonly_query COUNT

  6. Create an index if needed: validate then execute the reviewed DDL in its own transact call

  • 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: Foreign Key Constraints

MUST load and follow foreign-keys.md before creating, altering, dropping, or migrating foreign keys.

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

For ALTER COLUMN TYPE, SET NOT NULL, or MODIFY PRIMARY KEY, MUST load ddl-migrations/overview.md. Use a direct ALTER form when supported; otherwise, present a user-approved table-recreation plan.

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, pg-migrations/index-conversion.md, pg-migrations/schema-objects.md, and foreign-keys.md. Run dsql_lint(fix=true) first for mechanical fixes, preserve foreign-key relationships, translate unsupported source syntax or options, 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 and Locking (Django/EF Core/Hibernate/Rails/SQLAlchemy)

Load orm-guides/overview.md for adapter names, locking guidance, 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 (40001): Retry with backoff, and keep (OC001) in the loop too — see occ-retry-patterns.md.

  • Foreign key violation (23503): Correct the relationship or referential action; MUST NOT send it through the 40001 retry loop — see troubleshooting.md.

  • Transaction exceeds limits: Split batches under 3,000 rows and 10 MiB; size is checked at COMMIT — see limits-and-error-codes.md to size them and batched-migration.md for the pattern.

  • Token expiration mid-operation: Generate a fresh IAM token — see authentication-guide.md. See troubleshooting.md for other issues.

Additional Resources

Files

references/foreign-keys.md

Foreign Key Constraints

Aurora DSQL supports foreign key constraints with familiar SQL syntax. Use foreign keys by default for database-enforced referential integrity. Preserve foreign-key relationships during migration and translate only unsupported source syntax or options.

Table of Contents

  1. Default Pattern

  2. DSQL-Specific DDL

  3. Operational Notes

  4. Table Recreation and Drops

  5. Additional Resources

Default Pattern

Create the referenced table before the referencing table and use standard REFERENCES or FOREIGN KEY ... REFERENCES syntax. See Foreign Key Pattern for executable composite tenant-key DDL.

Use a unique referenced key and type-compatible referencing columns.

For a tenant-scoped relationship where the database must enforce tenant equality, the tenant key MUST appear in both keys and be NOT NULL on both sides. Under the default MATCH SIMPLE, optional relationship columns MAY remain nullable; a null relationship value means no relationship. Use MATCH FULL when the application must reject partially populated composite keys. Preserve ordinary foreign keys for shared or globally identified rows. A foreign key enforces integrity, not caller authorization.

DSQL-Specific DDL

Run every externally sourced or generated DDL statement through the complete dsql-lint workflow. Surface every diagnostic and the returned fixed_sql; stop on unfixable and obtain acknowledgement for fixed_with_warning.

Add to an existing table

Post-creation foreign keys MUST use NOT VALID. The add is synchronous, applies to new writes immediately, skips the existing-row scan, and returns no job_id.

When referenced uniqueness comes from CREATE UNIQUE INDEX ASYNC, wait until pg_index.indisvalid = true before adding the foreign key.

ALTER TABLE orders
  ADD CONSTRAINT orders_customers_customer_fkey
  FOREIGN KEY (tenant_id, customer_id)
  REFERENCES customers (tenant_id, customer_id)
  NOT VALID;
Validate existing rows

ASYNC is REQUIRED for VALIDATE CONSTRAINT and applies only to this statement.

ALTER TABLE ASYNC orders
  VALIDATE CONSTRAINT orders_customers_customer_fkey;

Capture the returned job_id, poll sys.jobs through submitted, processing, completed, or failed, inspect details on failure, and verify the catalog state:

from safe_query import build, literal
import time

validation_result = transact([
    "ALTER TABLE ASYNC orders "
    "VALIDATE CONSTRAINT orders_customers_customer_fkey"
])
job_id = validation_result[0]["job_id"]
deadline = time.monotonic() + 300

while True:
    job = readonly_query(build(
        "SELECT status, details FROM sys.jobs WHERE job_id = {job_id}",
        job_id=literal(job_id),
    ))[0]
    if job["status"] == "completed":
        break
    if job["status"] == "failed":
        raise RuntimeError(f"Foreign key validation failed: {job['details']}")
    if time.monotonic() >= deadline:
        raise TimeoutError(f"Timed out waiting for validation job {job_id}")
    time.sleep(1)

validated = readonly_query(build(
    "SELECT convalidated FROM pg_constraint "
    "WHERE conrelid = 'orders'::regclass "
    "AND contype = 'f' "
    "AND conname = {constraint_name}",
    constraint_name=literal("orders_customers_customer_fkey"),
))[0]["convalidated"]
if not validated:
    raise RuntimeError("Validation job completed without validating the constraint")

Alternatively, call sys.wait_for_job through an autocommit database client and require its succeeded result to be true. Use sys.jobs when the caller needs job status or failure details.

Operational Notes

  • Use default MATCH SIMPLE, or use MATCH FULL to require all-null or all-non-null composite keys.

  • SHOULD default to NO ACTION. Use CASCADE, SET NULL, or SET DEFAULT only when the user explicitly intends the behavior and confirms its impact. Choose deferrability to match the transaction's validation point.

  • Use DEFERRABLE for circular relationships or ORM flush orders that cannot satisfy each FK statement-by-statement. Run SET CONSTRAINTS in the same explicit transaction as the related DML; a separate MCP transact call commits independently. Deferred violations surface at COMMIT.

  • Use relationship-specific constraint names such as orders_billing_customer_fkey; qualify the table name when a schema is required.

  • For tenant-scoped relationships, referential actions MUST preserve the tenant key and the resulting tuple MUST remain in the same tenant.

  • FK checks perform reads. A transaction can fail with 40001 when a concurrent referenced-key change commits after the transaction's snapshot; retry the complete transaction.

  • Cascading actions count toward transaction limits. MUST assess per-parent fan-out; use NO ACTION or RESTRICT and process children in bounded transactions when one parent can exceed the limit.

  • Surface foreign-key violation 23503 for relationship correction.

Table Recreation and Drops

Use ALTER TABLE ... DROP CONSTRAINT to remove a foreign key directly. Before dropping, confirm the named constraint with pg_constraint.contype = 'f', explain the loss of database enforcement, and obtain confirmation.

When a table-recreation request involves foreign keys or dependent views, stop the generic pattern and present a dedicated, user-approved migration plan.

Additional Resources

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an MCP server, Needs Python, Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
AWS Labs
Publisher
AWS Labs (Official)
Source
awslabs/agent-plugins · plugins/databases-on-aws/skills/dsql · commit fbefb37
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • NOTICE (added by AutoGineer from NOTICE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by AWS Labs.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dsql.zip