99 posts tagged with "stackql"

We've released an update to the StackQL anthropic provider, regenerated from the current Claude API specification. The provider now covers 12 services, 27 resources and 108 operations (up from 11, 26 and 103 in the July release). Changes in this release:

• A new dreams service
• Files and skills moved to their generally available endpoints
• Workspace-scoped queries on most operations through the anthropic-workspace-id parameter

The anthropic_admin provider (6 services, 11 resources, 27 operations) is unchanged in this release.

Dreams​

Dreams are asynchronous memory-consolidation jobs: a dream reads a memory store and a set of session transcripts and writes consolidated memories into an output store. The service is a research preview on the Anthropic side, so the endpoints return a 404 for keys that are not enrolled. The dreams resource maps the surface as follows:

Dreams and their status as rows:

SELECT id, status, JSON_ARRAY_LENGTH(inputs) AS input_count, created_at, ended_at
FROM anthropic.dreams.dreams
ORDER BY created_at DESC;

Starting one is an INSERT. inputs and model are JSON values that the provider passes through as structured request fields:

INSERT INTO anthropic.dreams.dreams (inputs, model, instructions)
SELECT '[{"type": "memory_store", "memory_store_id": "memstore_01..."}]',
       '{"id": "claude-opus-5"}',
       'Consolidate project decisions and open questions.'
RETURNING id, status;

Files and skills on GA endpoints​

The Files API and the Skills API are generally available. The files and skills services now call the GA endpoints (/v1/files, /v1/skills) instead of the beta ones, and no longer send an anthropic-beta header. Resources, methods and SQL verbs are unchanged, so existing queries keep working. One behavioural change: the files list is now cursor-paginated and the provider walks the pages automatically.

SELECT id, filename, mime_type, size_bytes, created_at
FROM anthropic.files.files
ORDER BY created_at DESC;

SELECT id, display_name, JSON_EXTRACT(source, '$.type') AS source, latest_version_id, updated_at
FROM anthropic.skills.skills
ORDER BY updated_at DESC;

Skill versions are a separate resource keyed by the skill:

SELECT id, skill_id, name, description, created_at
FROM anthropic.skills.versions
WHERE skill_id = 'xlsx';

Uploading a file or creating a skill version is a multipart request, which SQL cannot express; those two methods remain documented as EXEC operations, and the rest of each resource (list, get, delete) is plain SQL.

Workspace-scoped queries​

The Claude API added an optional anthropic-workspace-id header to most operations, for credentials that can act on more than one workspace. The provider exposes it as an optional parameter on around 110 operations. It is a hyphenated name, so it is double-quoted in SQL:

SELECT id, display_name, created_at
FROM anthropic.models.models
WHERE "anthropic-workspace-id" = 'wrkspc_01CZkZaBF1tNoB5wlCeusgy';

The workspace ids are the ones the anthropic_admin provider lists:

SELECT id, name, archived_at
FROM anthropic_admin.workspaces.workspaces;

A key that belongs to a single workspace can omit the parameter. The API validates the value: a malformed id is rejected with a 400.

Under the hood​

The provider is generated from the OpenAPI specification that Anthropic now bundles with its SDKs. That specification grew from 126 to 244 operations since July, and the SDKs' configured endpoint count from 116 to 201. Beyond the changes above, the growth is the beta twins of the GA files and skills endpoints and the Admin API, which the specification now models but which needs an org-scoped admin key and belongs to the anthropic_admin provider. Every operation in the specification is either mapped or listed in a documented exclusion list, and the build fails when the two do not add up.

Every documented example query runs in the provider's test suite, and each generated docs page now shows the date it was last regenerated.

Authentication​

Unchanged. The two providers use different key types, which are disjoint by design:

# anthropic - workspace-scoped Claude API key
export ANTHROPIC_API_KEY=sk-ant-api...

# anthropic_admin - org-scoped Admin API key (created by org admins)
export ANTHROPIC_ADMIN_KEY=sk-ant-admin...

Get started​

Pull the latest provider from the public registry:

registry pull anthropic;

Provider docs, including required parameters and example queries for every resource, are at anthropic-provider.stackql.io and anthropic-admin-provider.stackql.io. Visit us on GitHub and let us know how you're using it.

StackQL v0.11 is out. The StackQL MCP server: now includes the current Model Context Protocol revision, 2026-07-28, alongside every earlier revision it already supported, and the audit log that records what an agent did can be written as OpenTelemetry log records instead of the bespoke JSONL format. Both are available today through every install channel.

We've released an updated StackQL Datadog provider covering the Datadog v1 and v2 REST APIs together: 18 services, 597 resources and 1658 operations, up from 16 services and 575 operations in the previous release.

What's new​

The previous provider was built from the v2 API alone. Datadog's most-used resources - monitors, dashboards, synthetics, SLOs, hosts, log indexes and pipelines - only exist in the v1 API, so this release merges the two specs into one provider. The v2 surface has also grown considerably since the last build. In summary:

• The v1 API: monitors (list, search, create, replace, validate, delete), dashboards and dashboard lists, synthetics tests (API, browser and mobile), locations, private locations and global variables, SLOs and SLO corrections, hosts, host totals and host tags, notebooks, log indexes and pipelines, the Azure, PagerDuty, Slack and webhook integrations, and usage metering.
• New v2 surfaces: cases and case projects, on-call schedules, escalation policies and paging, status pages, incident configuration and responders, feature flags, deployment gates, LLM Observability (projects, datasets, experiments, prompts, annotation queues), Fleet Automation, cloud cost budgets, commitments and tag pipelines, security findings automation, static analysis and SCA, agentless scanning, SIEM historical detections, RUM replay and product analytics, reference tables, org groups and personal access tokens, among others.
• Site from the environment: the provider addresses https://api.{site}, and site is resolved from DD_SITE when it is set (datadoghq.eu, us5.datadoghq.com, ap2.datadoghq.com, ...), the same convention as the Datadog Agent and API clients. Queries carry no site clause; a WHERE site = '...' still wins for one statement.
• Pagination and pushdown: cursor-paginated lists (audit events, container images, spans, RUM events, CI events, security signals and findings) are traversed transparently, and a SQL LIMIT is sent as the API's page-size parameter.
• snake_case surface: columns and WHERE / INSERT keys are snake_case throughout; the few camelCase wire names are aliased.
• Terraform-aligned authentication: DD_API_KEY and DD_APP_KEY, unchanged.

Service highlights​

Authentication​

Export an API key and an application key; set DD_SITE if your organization is not on datadoghq.com:

export DD_API_KEY=...
export DD_APP_KEY=...
export DD_SITE=datadoghq.eu     # optional, defaults to datadoghq.com

Monitors​

Every monitor with its state:

SELECT id, name, type, overall_state, tags
FROM datadog.monitoring.monitors;

Only alerting monitors, using the API's own filter:

SELECT id, name, overall_state
FROM datadog.monitoring.monitors
WHERE group_states = 'alert';

Monitor search, with the same syntax as the Manage Monitors page:

SELECT id, name, status, type
FROM datadog.monitoring.monitor_search_results
WHERE query = 'type:metric status:alert';

Dashboards, SLOs and synthetics​

SELECT id, title, layout_type, author_handle, modified_at
FROM datadog.dashboards.dashboards;

SELECT id, name, type, target_threshold, timeframe
FROM datadog.service_management.slos;

SELECT public_id, name, type, status, locations
FROM datadog.monitoring.synthetics_tests;

Users, roles and keys​

v2 resources return the JSON:API row shape - id, type, attributes, relationships - so attributes are one json_extract away. A user audit:

SELECT id,
       json_extract(attributes, '$.email') AS email,
       json_extract(attributes, '$.status') AS status,
       json_extract(attributes, '$.disabled') AS disabled,
       json_extract(attributes, '$.created_at') AS created_at
FROM datadog.organization.users;

API keys by age, the input to a rotation policy:

SELECT id,
       json_extract(attributes, '$.name') AS name,
       json_extract(attributes, '$.created_at') AS created_at,
       json_extract(attributes, '$.last4') AS last4
FROM datadog.organization.api_keys
ORDER BY created_at;

Infrastructure and logs​

Hosts reporting to Datadog, and the log indexes with their retention:

SELECT host_name, up, is_muted, apps, last_reported_time
FROM datadog.infrastructure.hosts;

SELECT name, num_retention_days, daily_limit
FROM datadog.logs.indexes;

Audit log​

The audit event list is cursor-paginated and takes the time window as a query parameter:

SELECT json_extract(attributes, '$.timestamp') AS timestamp,
       json_extract(attributes, '$.attributes.evt.name') AS event,
       json_extract(attributes, '$.attributes.usr.email') AS actor
FROM datadog.organization.audit_logs
WHERE "filter[from]" = 'now-1d';

Security monitoring rules​

Which detection rules are enabled, and who last changed them:

SELECT id, name, type, is_enabled, is_default, updated_at, update_author_id
FROM datadog.security.monitoring_rules
WHERE is_default = false;

Provisioning​

Mutations use the same SQL grammar. v1 resources take their fields as columns; v2 resources take the JSON:API data document. A monitor end to end - validate the definition, create it, replace it (the v1 monitor API updates with PUT), delete it:

EXEC datadog.monitoring.monitors.validate_monitor
  @type = 'metric alert',
  @query = 'avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 90',
  @name = 'High CPU on prod hosts';

INSERT INTO datadog.monitoring.monitors (name, type, query, message, tags)
SELECT 'High CPU on prod hosts',
       'metric alert',
       'avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 90',
       'CPU above 90% on {{host.name}} @slack-ops',
       '["team:web", "managed-by:stackql"]';

REPLACE datadog.monitoring.monitors
SET name = 'High CPU on prod hosts', type = 'metric alert',
    query = 'avg(last_5m):avg:system.cpu.user{env:prod} by {host} > 95'
WHERE monitor_id = 12345678;

DELETE FROM datadog.monitoring.monitors
WHERE monitor_id = 12345678;

A downtime for a release window, and a role:

INSERT INTO datadog.service_management.downtimes (data)
SELECT '{"type": "downtime",
         "attributes": {"message": "release window", "scope": "env:prod",
                        "monitor_identifier": {"monitor_tags": ["team:web"]},
                        "schedule": {"start": "2026-09-01T22:00:00Z", "end": "2026-09-01T23:00:00Z"}}}';

INSERT INTO datadog.organization.roles (data)
SELECT '{"type": "roles", "attributes": {"name": "read-only-auditors"}}';

UPDATE datadog.organization.roles
SET data = '{"id": "<role-id>", "type": "roles", "attributes": {"name": "auditors"}}'
WHERE role_id = '<role-id>';

Get started​

Pull the provider from the public registry:

registry pull datadog;

Provider docs are at datadog-provider.stackql.io. Let us know what you build. Star us on GitHub.

We've rebuilt the StackQL Kubernetes provider from the ground up:

• k8s - every built-in control plane API group in a pinned Kubernetes minor release (currently 1.36): core, apps, batch, autoscaling, networking, storage, rbac, policy, apiextensions, admissionregistration, certificates, coordination, discovery, events, flowcontrol, node, scheduling, authentication, authorization and apiregistration (20 services, 152 resources, 573 operations)

The provider is generated from the per-group specs published in the Kubernetes repository, so the same provider works against kind, EKS, GKE, AKS, OpenShift or bare metal. Subresources (status, scale, log, eviction, binding, approval) are first-class resources, list pagination is traversed transparently, and LIMIT and label/field selectors are pushed down to the API server.

Connect with kubectl proxy​

The provider defaults to null_auth, designed for the kubectl proxy workflow - the proxy authenticates with your kubeconfig (including the EKS, GKE and AKS credential plugins), and StackQL connects to the local port with no configuration:

kubectl proxy --port=8001
export KUBE_HOST='localhost:8001'
export KUBE_PROTOCOL='http'
stackql shell

KUBE_HOST and KUBE_PROTOCOL resolve the provider's server variables from the environment, so queries carry no connection clauses at all (an explicit WHERE protocol = ... AND cluster_addr = ... still wins when you want to address another cluster in the same session).

The cluster is a database​

Row columns are the top-level fields of each object (metadata, spec, status, data); nested values are one json_extract away. The pod estate with phase and node placement:

SELECT json_extract(metadata, '$.namespace') AS namespace,
       json_extract(metadata, '$.name') AS name,
       json_extract(status, '$.phase') AS phase,
       json_extract(spec, '$.nodeName') AS node
FROM k8s.core.pods_all_namespaces;

Pods that are not running - a one-line cluster health check:

SELECT json_extract(metadata, '$.namespace') AS namespace,
       json_extract(metadata, '$.name') AS name,
       json_extract(status, '$.phase') AS phase
FROM k8s.core.pods_all_namespaces
WHERE json_extract(status, '$.phase') NOT IN ('Running', 'Succeeded');

Desired versus ready replicas for every deployment in a namespace:

SELECT json_extract(metadata, '$.name') AS name,
       json_extract(spec, '$.replicas') AS want,
       json_extract(status, '$.readyReplicas') AS ready
FROM k8s.apps.deployments
WHERE namespace = 'default';

Node inventory with kubelet version and schedulability:

SELECT json_extract(metadata, '$.name') AS name,
       json_extract(status, '$.nodeInfo.kubeletVersion') AS kubelet,
       json_extract(status, '$.nodeInfo.osImage') AS os,
       json_extract(spec, '$.unschedulable') AS cordoned
FROM k8s.core.nodes;

RBAC audit and warning events​

Column names are snake_case at the SQL surface (role_ref, string_data, api_version), mapped to the API's camelCase on the wire - the same convention as the aws and azure providers. Who is bound to cluster-admin:

SELECT json_extract(metadata, '$.name') AS binding,
       subjects
FROM k8s.rbac.cluster_role_bindings
WHERE json_extract(role_ref, '$.name') = 'cluster-admin';

Recent warning events across the cluster, usually the first place to look when something is off:

SELECT json_extract(metadata, '$.namespace') AS namespace,
       reason,
       message
FROM k8s.core.events_all_namespaces
WHERE type = 'Warning';

Server-side filtering and pagination​

Label and field selectors are ordinary WHERE parameters, pushed to the API server so the filtering happens where the data lives:

SELECT json_extract(metadata, '$.name') AS name
FROM k8s.core.pods_all_namespaces
WHERE label_selector = 'k8s-app=kube-dns';

SELECT ... LIMIT n lands on the wire as the Kubernetes limit parameter, and the continue token chain is followed transparently - a SELECT returns all rows even when the API server caps page sizes.

Provision, mutate and tear down​

Mutations are the usual SQL verbs - INSERT creates an object, UPDATE applies a merge patch, REPLACE is a full update and DELETE removes it. Body columns are the native wire property names:

-- create
INSERT INTO k8s.core.config_maps(namespace, metadata, data)
SELECT 'default', '{"name": "app-config"}', '{"greeting": "hello"}';

-- partial update (merge patch)
UPDATE k8s.core.config_maps
SET data = '{"mood": "optimistic"}'
WHERE namespace = 'default' AND name = 'app-config';

-- remove it
DELETE FROM k8s.core.config_maps
WHERE namespace = 'default' AND name = 'app-config';

Subresources are resources, so scaling a deployment is an UPDATE on its scale subresource:

UPDATE k8s.apps.deployments_scale
SET spec = '{"replicas": 3}'
WHERE namespace = 'default' AND name = 'web';

and point-in-time pod logs are a queryable column:

SELECT log FROM k8s.core.pods_log
WHERE namespace = 'default' AND name = 'web-6d5f9c7b8-x2x9k';

Streaming operations (exec, attach, port-forward, watch) use protocol upgrades and are out of scope for the generated provider.

Who am I, and can I​

The authentication and authorization review kinds are mapped too. The zero-parameter self review is a plain SELECT; the parameterized access reviews are an INSERT whose verdict comes back with RETURNING:

-- who am I
SELECT json_extract(status, '$.userInfo.username') AS username
FROM k8s.authentication.self_subject_reviews;

-- can I delete pods in prod
INSERT INTO k8s.authorization.self_subject_access_reviews(spec)
SELECT '{"resourceAttributes": {"verb": "delete", "resource": "pods", "namespace": "prod"}}'
RETURNING status;

What changed from the original provider​

This is a major update to the previous published k8s provider (v23.03.00121):

• Coverage expands from 5 services to all 20 built-in API groups, one flat service per group (networking.k8s.io is k8s.networking)
• Resource names are plural snake_case (k8s.core.pods, k8s.apps.stateful_sets), consistent with the aws, google and databricks providers
• Request body columns are the native wire property names (metadata, spec, data), not data__ prefixed; snake_case spellings of camelCase wire names are accepted everywhere
• SELECT and DESCRIBE columns present as snake_case aliases of the camelCase wire properties
• Namespaced list-all operations are separate _all_namespaces resources, and subresources are separate resources (deployments_scale, pods_log)

The previous provider version remains in the registry for pinning if you need it.

Direct authentication​

To skip the proxy and hit the API server directly, supply a bearer token via the KUBE_TOKEN environment variable (the same variable the Terraform Kubernetes provider uses), along with the cluster CA bundle:

export KUBE_TOKEN=$(kubectl create token my-serviceaccount)
AUTH='{ "k8s": { "type": "bearer", "credentialsenvvar": "KUBE_TOKEN" }}'
stackql shell --auth="${AUTH}" --tls.CABundle cluster-ca.pem

For managed clusters, a token from the platform credential helper (aws eks get-token, gke-gcloud-auth-plugin, kubelogin) works the same way; those tokens are short lived, so prefer the proxy vector for long sessions.

Get started​

Pull the provider from the public registry:

registry pull k8s;

Provider docs are at k8s-provider.stackql.io. Let us know what you build. Star us on GitHub.

We've released an update to the StackQL AWS provider, regenerated from the latest AWS service definitions. Significant additions include:

• 9 new services
• Over 200 new resources
• Over 500 new operations
• Full support for S3 object level CRUD operations

New Services​

Nine services are new in this release:

Expanded Coverage in Existing Services​

• ec2 - the largest operation count increase in this release: account-level VPC encryption controls (account_vpc_encryption_controls), application status checks, capacity reservation cancellation quotes, and a major IPAM build-out covering internet registry associations, route origin authorizations, route protection findings and discovered routes
• acm - public ACME issuance: acme_accounts, acme_endpoints, acme_domain_validations and external account bindings, plus per-domain certificate validation status
• quicksight - agentic BI: agents, spaces, knowledge_bases, approval policies, DLP settings and OAuth client applications
• bedrock_agentcore_control - datasets, dataset versions and examples, evaluation harness_endpoints and versions, capacity providers and gateway rate limits
• wellarchitected - AI-assisted reviews: agent profiles, goals, contexts and agent_recommendations with per-item detail
• odb (Oracle Database@AWS) - autonomous database coverage: autonomous_databases, backups, clones, peers, wallet details, Exadata VM clusters and Exascale storage vaults
• iotsitewise - industrial data pipelines: pipelines, pipeline executions, enrichment jobs, dataset export jobs, ad hoc queries and search
• glue - business catalog additions: assets, asset_types, glossaries and glossary_terms
• drs - orchestrated disaster recovery: recovery_plans, plan steps and execution tracking
• billing - credits, credit allocation histories, billing preferences and enterprise support charge summaries
• appconfig - feature experiments: experiment_definitions, runs and run events
• healthlake - FHIR data transformation profiles and jobs

Another 180+ services picked up incremental operations and resources, including connect, securityagent, cleanrooms, socialmessaging, devops_agent and artifact.

S3 Object Content Lifecycles​

The headline feature in this release: aws.s3.objects now supports the full content lifecycle for text objects. The object body is projected as a single contents column, so you can read, write, overwrite and delete object contents with standard SQL verbs - no SDK code, no presigned URLs.

The motivating case is reading a Terraform state file straight out of S3:

SELECT contents FROM aws.s3.objects
WHERE region = 'ap-southeast-2'
AND bucket = 'my-bucket'
AND key = 'env/terraform.tfstate';

Writing works through the same resource. INSERT creates an object, and since S3 PutObject is create-or-overwrite, REPLACE updates it in place:

-- create an object
INSERT INTO aws.s3.objects(region, bucket, key, contents)
SELECT 'ap-southeast-2', 'my-bucket', 'app/config.json',
'{"feature_flags": {"dark_mode": true}, "log_level": "info"}';

-- overwrite its contents
REPLACE aws.s3.objects
SET contents = '{"feature_flags": {"dark_mode": false}, "log_level": "warn"}'
WHERE region = 'ap-southeast-2'
AND bucket = 'my-bucket'
AND key = 'app/config.json';

-- delete it
DELETE FROM aws.s3.objects
WHERE region = 'ap-southeast-2'
AND bucket = 'my-bucket'
AND key = 'app/config.json';

Listing is unchanged - a WHERE clause with just bucket and region routes to the list operation, adding key routes to the object read:

SELECT key, size, last_modified FROM aws.s3.objects
WHERE region = 'ap-southeast-2' AND bucket = 'my-bucket';

Content round-trips byte-for-byte, including multi-MB objects and objects uploaded via multipart upload. Text objects only for now - binary content is not supported and base64 support is deferred.

Get Started​

Pull the latest provider from the public registry:

stackql registry pull aws;

Authenticate with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, then explore:

SELECT vpc_id, state, cidr_block, is_default
FROM aws.ec2.vpcs
WHERE region = 'us-east-1';

Provider docs, including required parameters and example queries for every resource, are at aws-provider.stackql.io. Visit us on GitHub and let us know how you're using it.