{ "version": "https://jsonfeed.org/version/1", "title": "StackQL Blog - Provider Announcements", "home_page_url": "https://stackql.io/blog/providers", "description": "New and updated StackQL providers", "items": [ { "id": "https://stackql.io/blog/providers/new-typesafe-provider-available", "content_html": "

We've released a new StackQL provider for TypeSafe AI:

\n\n

Jev is a System One model. Instead of generating text it answers typed questions about a state you supply and returns a calibrated probability or distribution for each one: a Noul question is a yes/no with the probability of yes, a Choice picks one option from a set you define with a probability per option and a confidence, and a Score rates the state against an ordered rubric. Any mix of the three runs against the same state in one request, in about a hundred milliseconds, for a fraction of a cent. There is nothing to parse and nothing to coax into JSON.

\n

That matters most for agents that already run on the StackQL MCP server. Those agents have every provider's control plane as SQL, and the audit log and approval gates that come with it. What a WHERE clause cannot do is make the judgment call: is this instance production or scratch, does this rule's description justify public ingress, does this account still need an admin role, is a restart the right response to this event. In this provider that call is a SELECT too, so a decision sits between a context query and a mutation as one more governed tool call. The rest of this post is that routine, in the shapes platform, FinOps, SRE and security teams actually run.

\n

Connect​

\n

Authentication is a TypeSafe API key, created in the TypeSafe console and read from TYPESAFE_API_KEY, the same variable the TypeSafe SDKs use (there is no Terraform provider for TypeSafe):

\n
export TYPESAFE_API_KEY=...
stackql shell
\n

Pricing is per input token ($0.042 per million at the time of writing; output tokens are free), and the usage column of every row reports what a decision cost. Jev 1.13 allows 80 requests per second and 100K tokens per second; the provider carries the retry policy the vendor SDKs apply by default, so a 429 or a 529 on the first attempt is retried with backoff before it surfaces.

\n

The routine​

\n

An evaluation is a SELECT from typesafe.systemone.evaluations: the state, the model and the questions are the WHERE clause, and the row that comes back carries the versioned model that answered, the answers keyed by the names you chose, and the token usage. Over MCP the routine is three tool calls:

\n
    \n
  1. Context - run_select_query against the provider that owns the facts (aws, k8s, okta, github, ...). The agent keeps the columns the decision needs.
    2. \n
  2. Decision - run_select_query against typesafe.systemone.evaluations, with the record serialised as the JSON state and the routine's questions as questions.
    3. \n
  3. Action - run_mutation_query or run_lifecycle_operation against the owning provider, only when the answer clears the threshold the routine sets: a Noul at or above 0.9 (or at or below 0.1), a Choice with confidence at or above 0.9, a Score above a level.
    4. \n
\n

Every evaluation is a read, so the decision step is allowed in every MCP server mode, including read_only; in the default safe mode the action still goes through the client's approval prompt, and in read_only the routine stops at the recommendation. Every tool call lands in the server's audit log, and because the row names the model version that answered, every automated change can record which model decided it.

\n

The examples below were run live against the API before publication. Each shows the context query, the decision over one representative record, and the action; the answer Jev gave for that record is under each block.

\n

Tagging hygiene​

\n

Platform engineering: classify an instance from its name and existing tags, then write the missing tags back.

\n
-- 1. context (run_select_query)
SELECT instance_id, instance_type, launch_time, tags
FROM aws.ec2.instances
WHERE region = 'us-east-1';

-- 2. decision (run_select_query): one record from the result as the state
SELECT json_extract(answers, '$.environment.choice') AS environment,
       json_extract(answers, '$.environment.confidence') AS confidence,
       json_extract(answers, '$.owner_team.choice') AS owner_team,
       model
FROM typesafe.systemone.evaluations
WHERE state = '{\"instance_id\": \"i-0a1b2c3d4e5f67890\", \"instance_type\": \"m5.2xlarge\", \"launch_time\": \"2026-03-02T09:14:00Z\", \"tags\": [{\"Key\": \"Name\", \"Value\": \"jenkins-agent-prod-2\"}, {\"Key\": \"created-by\", \"Value\": \"ci-platform@example.com\"}]}'
  AND model = 'jev-latest'
  AND questions = '{
    \"environment\": {\"type\": \"choice\", \"instructions\": \"Which environment does this instance belong to? Use the Name tag and anything else in the record.\",
                    \"criteria\": {\"production\": \"Serves live traffic or production pipelines\", \"staging\": \"Pre-production, UAT or release testing\", \"development\": \"Developer, sandbox or test use\", \"unknown\": \"The record does not say\"}},
    \"owner_team\": {\"type\": \"choice\", \"instructions\": \"Which team most likely owns this instance?\",
                   \"criteria\": {\"platform\": \"CI, build and shared infrastructure\", \"data\": \"Analytics and data pipelines\", \"product\": \"Customer-facing applications\", \"unknown\": \"Cannot tell from the record\"}}
  }';

-- 3. action (run_mutation_query), when confidence >= 0.9
INSERT INTO aws.ec2.tags (ResourceId, Tag, region)
SELECT 'i-0a1b2c3d4e5f67890',
       '[{\"Key\": \"environment\", \"Value\": \"production\"}, {\"Key\": \"owner\", \"Value\": \"platform\"}]',
       'us-east-1';
\n
environmentconfidenceowner_teammodel
production1.0platformjev-1.13.0
\n

A routine that walks every untagged instance in the account is a loop over the context rows: one decision call per record, one tag write per record that clears the bar, and the rest left for a person.

\n

Rightsizing and off-hours scheduling​

\n

FinOps and GreenOps: given an instance record and the utilisation the agent has gathered, decide between keeping it, stopping it outside business hours, downsizing it or referring it to the owner. A second question asks whether the workload could run at another time or in another region at all, which is the lever carbon-aware scheduling needs.

\n
-- 1. context (run_select_query)
SELECT instance_id, instance_type, state, launch_time, tags
FROM aws.ec2.instances
WHERE region = 'us-east-1';

-- 2. decision (run_select_query)
SELECT json_extract(answers, '$.action.choice') AS action,
       json_extract(answers, '$.action.confidence') AS confidence,
       json_extract(answers, '$.schedulable.noul') AS p_schedulable,
       model
FROM typesafe.systemone.evaluations
WHERE state = '{\"instance_id\": \"i-0b9c8d7e6f5a43210\", \"instance_type\": \"r5.4xlarge\", \"state\": \"running\", \"launch_time\": \"2025-11-18T03:00:00Z\", \"tags\": [{\"Key\": \"Name\", \"Value\": \"nightly-report-builder\"}, {\"Key\": \"owner\", \"Value\": \"data\"}], \"avg_cpu_14d_pct\": 3.1, \"max_cpu_14d_pct\": 61.0, \"busy_hours_utc\": \"01:00-03:00\"}'
  AND model = 'jev-latest'
  AND questions = '{
    \"action\": {\"type\": \"choice\", \"instructions\": \"What should a cost review do with this instance?\",
               \"criteria\": {\"keep\": \"Utilisation and purpose justify running it as is\", \"stop_outside_hours\": \"It only works in a known window and can be stopped the rest of the time\", \"downsize\": \"It is oversized for its sustained load\", \"review_with_owner\": \"The record is not enough to decide\"}},
    \"schedulable\": {\"type\": \"noul\", \"instructions\": \"Could this workload run at a different time of day or in a different region without affecting users?\",
                    \"criteria\": {\"true\": \"A batch or scheduled job with no interactive users\", \"false\": \"Serves users or other systems on demand\"}}
  }';

-- 3. action (run_lifecycle_operation), when action = 'stop_outside_hours' and confidence >= 0.9
EXEC aws.ec2.instances.stop_instances
  @InstanceId = 'i-0b9c8d7e6f5a43210',
  @region = 'us-east-1';
\n
actionconfidencep_schedulable
stop_outside_hours0.90.87
\n

The confidence sat between 0.86 and 0.91 across repeated runs of the same record, which is the point of putting a threshold in the routine rather than in the prompt: at 0.86 this instance goes to the owner instead of being stopped.

\n

Incident triage​

\n

SRE: read the cluster's warning events, let Jev name the likely cause, rate the severity and say whether rescheduling the pod is the right first response.

\n
-- 1. context (run_select_query)
SELECT json_extract(involved_object, '$.namespace') AS namespace,
       json_extract(involved_object, '$.kind') AS kind,
       json_extract(involved_object, '$.name') AS name,
       reason, message, count, last_timestamp
FROM k8s.core.events_all_namespaces
WHERE type = 'Warning';

-- 2. decision (run_select_query)
SELECT json_extract(answers, '$.cause.choice') AS cause,
       json_extract(answers, '$.severity.score') AS severity,
       json_extract(answers, '$.reschedule_helps.noul') AS p_reschedule_helps,
       model
FROM typesafe.systemone.evaluations
WHERE state = '{\"namespace\": \"payments\", \"kind\": \"Pod\", \"name\": \"checkout-api-7c9d6f8b5-xk2lp\", \"reason\": \"BackOff\", \"message\": \"Back-off restarting failed container checkout-api in pod checkout-api-7c9d6f8b5-xk2lp\", \"count\": 14, \"last_timestamp\": \"2026-10-05T02:41:07Z\", \"recent_log_tail\": \"FATAL: connection pool exhausted after 30s waiting for a connection to payments-db\"}'
  AND model = 'jev-latest'
  AND questions = '{
    \"cause\": {\"type\": \"choice\", \"instructions\": \"What is the most likely cause of this event?\",
              \"criteria\": {\"crash_loop\": \"The container exits repeatedly on its own error\", \"out_of_memory\": \"Killed for exceeding its memory limit\", \"image_pull\": \"The image cannot be pulled\", \"scheduling\": \"No node can place the pod\", \"dependency\": \"A dependency the container needs is unavailable or saturated\", \"other\": \"None of the above\"}},
    \"severity\": {\"type\": \"score\", \"instructions\": \"How severe is this for users?\",
                 \"criteria\": [\"Informational, no user impact\", \"Degraded, users may notice\", \"Outage of a user-facing capability\", \"Outage with data or payment risk\"]},
    \"reschedule_helps\": {\"type\": \"noul\", \"instructions\": \"Would deleting the pod so the controller reschedules it most likely resolve this?\",
                         \"criteria\": {\"true\": \"A transient or node-local fault that a fresh pod clears\", \"false\": \"A code, configuration or dependency fault a new pod would hit again\"}}
  }';

-- 3. action (run_mutation_query), when p_reschedule_helps >= 0.9 and severity < 2
DELETE FROM k8s.core.pods
WHERE namespace = 'payments' AND name = 'checkout-api-7c9d6f8b5-xk2lp';
\n
causeseverityp_reschedule_helps
dependency2.20.21
\n

This one is worth reading closely. The event alone looks like a crash loop, and a reflexive runbook would delete the pod. Jev read the log tail, named the saturated database pool as the cause, rated it an outage with payment risk and gave the restart a 0.21, so the routine does not touch the pod and the agent escalates instead.

\n

Public ingress review​

\n

CSPM: list the security group rules open to the internet, let Jev judge whether each rule's description and port make the exposure a deliberate public endpoint or an exposed management or database port, then revoke a rule only when it is judged unjustified.

\n
-- 1. context (run_select_query)
SELECT security_group_rule_id, group_id, ip_protocol, from_port, to_port, cidr_ipv_4, is_egress, description
FROM aws.ec2.security_group_rules
WHERE region = 'us-east-1'
  AND cidr_ipv_4 = '0.0.0.0/0';

-- 2. decision (run_select_query)
SELECT json_extract(answers, '$.justified.noul') AS p_justified,
       json_extract(answers, '$.exposure.choice') AS exposure,
       json_extract(answers, '$.exposure.confidence') AS confidence,
       model
FROM typesafe.systemone.evaluations
WHERE state = '{\"security_group_rule_id\": \"sgr-0f1e2d3c4b5a69788\", \"group_id\": \"sg-0123456789abcdef0\", \"group_name\": \"analytics-db\", \"ip_protocol\": \"tcp\", \"from_port\": 5432, \"to_port\": 5432, \"cidr_ipv_4\": \"0.0.0.0/0\", \"is_egress\": false, \"description\": \"temp access for vendor demo\"}'
  AND model = 'jev-latest'
  AND questions = '{
    \"justified\": {\"type\": \"noul\", \"instructions\": \"Do the description, group name and port justify ingress from the whole internet?\",
                  \"criteria\": {\"true\": \"A deliberate public endpoint such as a load balancer or web tier on 80 or 443\", \"false\": \"A management, database or internal service port, or a temporary exception\"}},
    \"exposure\": {\"type\": \"choice\", \"instructions\": \"What kind of exposure is this?\",
                 \"criteria\": {\"public_endpoint\": \"Intended internet-facing service\", \"management_port\": \"SSH, RDP, WinRM or similar\", \"database_port\": \"A database or cache listener\", \"unknown\": \"Cannot tell from the record\"}}
  }';

-- 3. action (run_lifecycle_operation), when p_justified <= 0.1
EXEC aws.ec2.security_groups.revoke_security_group_ingress
  @GroupId = 'sg-0123456789abcdef0',
  @SecurityGroupRuleId = 'sgr-0f1e2d3c4b5a69788',
  @region = 'us-east-1';
\n
p_justifiedexposureconfidence
0.04database_port1.0
\n

Audit findings​

\n

Audit and compliance: the context comes from one provider and the action goes to another. Read the privilege grants from the identity provider's system log, let Jev check each against the change policy written into the question, and open a tracked finding for the ones that fall outside it.

\n
-- 1. context (run_select_query)
SELECT published, eventType, displayMessage, outcome, actor, target
FROM okta.logs.system_log_events
WHERE subdomain = 'my-org'
  AND since = '2026-10-04T00:00:00Z'
  AND filter = 'eventType eq \"user.account.privilege.grant\"';

-- 2. decision (run_select_query)
SELECT json_extract(answers, '$.in_policy.noul') AS p_in_policy,
       json_extract(answers, '$.risk.score') AS risk,
       model
FROM typesafe.systemone.evaluations
WHERE state = '{\"published\": \"2026-10-04T22:47:13Z\", \"eventType\": \"user.account.privilege.grant\", \"displayMessage\": \"Grant user privilege\", \"outcome\": \"SUCCESS\", \"actor\": {\"alternateId\": \"j.doe@example.com\", \"type\": \"User\"}, \"target\": [{\"alternateId\": \"svc-reporting@example.com\", \"type\": \"User\"}, {\"displayName\": \"Super Administrator\", \"type\": \"ROLE\"}], \"note\": \"no change ticket referenced\"}'
  AND model = 'jev-latest'
  AND questions = '{
    \"in_policy\": {\"type\": \"noul\", \"instructions\": \"Does this privilege grant comply with the change policy?\",
                  \"criteria\": {\"true\": \"Granted by an identity administrator, between 09:00 and 17:00 UTC on a weekday, with a change ticket referenced\", \"false\": \"Outside the change window, by a non-administrator, to a service account, or without a ticket\"}},
    \"risk\": {\"type\": \"score\", \"instructions\": \"How much risk does this grant carry?\",
             \"criteria\": [\"Routine, scoped role\", \"Elevated role to a person\", \"Tenant-wide administrative role, or any role to a service account\"]}
  }';

-- 3. action (run_mutation_query), when p_in_policy <= 0.2
INSERT INTO github.issues.issues (owner, repo, title, body, labels)
SELECT 'my-org',
       'security-audit',
       'Privilege grant outside change policy: svc-reporting@example.com granted Super Administrator',
       'Granted 2026-10-04T22:47:13Z by j.doe@example.com with no change ticket referenced. Flagged by jev-1.13.0 (in_policy 0.02, risk 2.0). Review and revoke or document.',
       '[\"compliance\", \"iam\"]';
\n
p_in_policyrisk
0.022.0
\n

The policy lives in the criteria of one question. Changing the change window or the ticket rule is a diff in that text, reviewed like any other change to the routine, not a retrained classifier.

\n

Writing the questions​

\n

Two things came out of putting these routines together. First, ask Jev the judgment and compute the facts yourself. An access-review draft asked \"Is this account dormant?\" with a 90-day rule in the criteria, and the answer drifted between 0.54 and 0.88 however plainly the dates were stated; Jev treats dormancy as a judgment about the person. Asked instead \"Do the title and department justify the roles this account holds?\" the same record answered 0.16 every time, and \"What kind of account is this?\" answered contractor with confidence 1.0. Days since the last sign-in is arithmetic, so it stays in SQL, and the suspension (EXEC okta.users.users.suspend_user) runs only when the arithmetic and the judgment agree. The full example is on the provider docs.

\n

Second, keep the thresholds in the routine and the model version in the record. Choice confidences and Scores drift a little between identical calls, which is a reason to gate on them rather than to read a single number as a verdict. The model column records which version answered, so an action log can say \"stopped by jev-1.13.0 at 0.91\", and once a routine's thresholds are tuned the versioned id can be pinned in place of the jev-latest alias.

\n

What the provider is and is not​

\n

The TypeSafe API is two operations, and the provider maps both. There is no administrative or usage API to map: keys are created and revoked in the TypeSafe console, and usage is reported per request in the usage column rather than through a reporting endpoint. Everything in the API is a read, so the provider has no INSERT, UPDATE or DELETE methods of its own; the mutations in this post belong to the providers that own the resources. The models catalog is the one plain inventory query:

\n
SELECT name, description, release_date
FROM typesafe.models.models
ORDER BY name;
\n

Every statement in this post was checked before publication: the typesafe statements ran live, and the aws, k8s, okta and github statements were routed through their providers to the wire against a scratch account. The complete smoke run of the provider costs a fraction of a cent.

\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull typesafe;
\n

Provider docs, including the request shape of each question type, the error contract and the full set of agent-routine examples, are at typesafe-provider.stackql.io. For the MCP server itself, start with How to use StackQL with AI agents. Let us know what you build. Star us on GitHub.

", "url": "https://stackql.io/blog/providers/new-typesafe-provider-available", "title": "New TypeSafe Provider Available", "summary": "A new StackQL provider for TypeSafe AI that brings Jev, TypeSafe's System One decision model, into StackQL agent routines over MCP - rows from aws, k8s, okta or github become the state, Jev returns a typed decision with a probability or confidence, and a StackQL mutation runs only when the decision clears the routine's threshold. Tagging hygiene, rightsizing, incident triage, access review, public ingress review and audit findings, as SQL.", "date_modified": "2026-10-05T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "typesafe", "jev", "provider", "mcp", "ai-agents" ] }, { "id": "https://stackql.io/blog/providers/new-railway-provider-available", "content_html": "

We've released a new StackQL provider for Railway:

\n\n

The provider reads and writes. Projects, environments, services, variables, domains and volumes can be queried, created, changed and removed, and deployment operations such as redeploy, restart and rollback are available on the resources they act on. The rest of this post is the questions it answers and the tasks it handles.

\n

Connect​

\n

Authentication is a Railway account token or workspace token, read from RAILWAY_TOKEN - the same variable the Terraform Railway provider uses:

\n
export RAILWAY_TOKEN=...
stackql shell
\n

Tokens are created under Account settings -> Tokens. A project token does not work with the provider. Railway limits API requests per hour by plan (100 on Free, 1000 on Hobby, 10000 on Pro), which is worth keeping in mind for queries that cover many projects or environments.

\n

What is deployed where​

\n

The workspaces a token can reach, the projects in one, and the environments of a project:

\n
SELECT id, name, plan
FROM railway.workspaces.workspaces;

SELECT id, name, description, created_at
FROM railway.projects.projects
WHERE workspace_id = '<workspace-id>'
ORDER BY created_at DESC;

SELECT id, name, is_ephemeral
FROM railway.environments.environments
WHERE project_id = '<project-id>';
\n

A service instance is a service as it is configured in one environment. Listing the instances of an environment shows what runs there, from which image or repository, and how the last deployment went:

\n
SELECT service_name, region, num_replicas,
       json_extract(source, '$.image') AS image,
       json_extract(source, '$.repo') AS repo,
       json_extract(latest_deployment, '$.status') AS last_deployment,
       json_extract(latest_deployment, '$.created_at') AS deployed_at
FROM railway.services.service_instances
WHERE environment_id = '<environment-id>';
\n

An IN list covers several environments in one query, with one request made per environment. Joining to environments puts names on the rows:

\n
SELECT e.name AS environment, s.service_name, s.region, s.num_replicas,
       json_extract(s.latest_deployment, '$.status') AS last_deployment
FROM railway.services.service_instances s
JOIN railway.environments.environments e ON e.id = s.environment_id
WHERE e.project_id = '<project-id>'
  AND s.environment_id IN ('<production-environment-id>', '<staging-environment-id>')
ORDER BY environment, service_name;
\n

The same works across projects, here for the services of two projects in a workspace:

\n
SELECT p.name AS project, s.name AS service, s.created_at
FROM railway.services.services s
JOIN railway.projects.projects p ON p.id = s.project_id
WHERE p.workspace_id = '<workspace-id>'
  AND s.project_id IN ('<project-id>', '<other-project-id>')
ORDER BY project, service;
\n

Deployment health​

\n

Deployment outcomes for a project, then the ones that failed or crashed, with who triggered them:

\n
SELECT status, count(*) AS deployments
FROM railway.deployments.deployments
WHERE project_id = '<project-id>'
GROUP BY status;

SELECT id, service_id, status, created_at,
       json_extract(creator, '$.name') AS deployed_by
FROM railway.deployments.deployments
WHERE project_id = '<project-id>'
  AND status = '{in: [FAILED, CRASHED]}'
ORDER BY created_at DESC;
\n

Services in an environment whose latest deployment is not healthy:

\n
SELECT service_name,
       json_extract(latest_deployment, '$.id') AS deployment_id,
       json_extract(latest_deployment, '$.status') AS status
FROM railway.services.service_instances
WHERE environment_id = '<environment-id>'
  AND json_extract(latest_deployment, '$.status') NOT IN ('SUCCESS', 'SLEEPING');
\n

From there, the build and runtime logs of a deployment are tables. LIMIT sets how many lines are fetched:

\n
SELECT timestamp, severity, message
FROM railway.observability.build_logs
WHERE deployment_id = '<deployment-id>'
LIMIT 100;

SELECT timestamp, severity, message
FROM railway.observability.deployment_logs
WHERE deployment_id = '<deployment-id>'
  AND filter = 'error'
LIMIT 100;
\n

Drift between environments​

\n

Variables are one row per variable, so comparing two environments is a join. Variables a service has in production that are missing in staging:

\n
SELECT prod.name
FROM railway.variables.variables prod
LEFT JOIN railway.variables.variables stg
  ON stg.name = prod.name
WHERE prod.project_id = '<project-id>'
  AND prod.environment_id = '<production-environment-id>'
  AND prod.service_id = '<service-id>'
  AND stg.project_id = '<project-id>'
  AND stg.environment_id = '<staging-environment-id>'
  AND stg.service_id = '<service-id>'
  AND stg.name IS NULL
  AND prod.name NOT LIKE 'RAILWAY_%';
\n

Variables set in both environments with different values:

\n
SELECT prod.name
FROM railway.variables.variables prod
JOIN railway.variables.variables stg
  ON stg.name = prod.name
WHERE prod.project_id = '<project-id>'
  AND prod.environment_id = '<production-environment-id>'
  AND prod.service_id = '<service-id>'
  AND stg.project_id = '<project-id>'
  AND stg.environment_id = '<staging-environment-id>'
  AND stg.service_id = '<service-id>'
  AND prod.value <> stg.value
  AND prod.name NOT LIKE 'RAILWAY_%';
\n

The variables Railway provides itself are prefixed RAILWAY_ and differ between environments by design, so they are left out. Both queries return names only. Selecting value returns the values in clear, so treat that output as a secret.

\n

The same approach compares how a service is configured in each environment:

\n
SELECT prod.service_name,
       prod.num_replicas AS prod_replicas, stg.num_replicas AS staging_replicas,
       prod.region AS prod_region, stg.region AS staging_region,
       prod.start_command AS prod_start_command, stg.start_command AS staging_start_command
FROM railway.services.service_instances prod
JOIN railway.services.service_instances stg
  ON stg.service_id = prod.service_id
WHERE prod.environment_id = '<production-environment-id>'
  AND stg.environment_id = '<staging-environment-id>';
\n

Domains and certificates​

\n

The generated domains of every service in an environment, without going service by service. The custom_domains key of the same column holds the custom ones:

\n
SELECT s.service_name,
       json_extract(d.value, '$.domain') AS domain,
       json_extract(d.value, '$.target_port') AS target_port
FROM railway.services.service_instances s,
     json_each(json_extract(s.domains, '$.service_domains')) d
WHERE s.environment_id = '<environment-id>';
\n

Custom domains carry their verification and certificate state, and the DNS records Railway expects to find:

\n
SELECT domain,
       json_extract(status, '$.verified') AS verified,
       json_extract(status, '$.certificate_status') AS certificate_status,
       json_extract(status, '$.dns_records') AS dns_records
FROM railway.networking.custom_domains
WHERE project_id = '<project-id>'
  AND environment_id = '<environment-id>'
  AND service_id = '<service-id>';
\n

Usage and cost​

\n

Usage for a workspace by measurement, grouped by project, with project names joined in:

\n
SELECT p.name AS project, u.measurement, u.value
FROM railway.billing.usage u
JOIN railway.projects.projects p
  ON p.id = json_extract(u.tags, '$.project_id')
WHERE u.workspace_id = '<workspace-id>'
  AND u.measurements = '[CPU_USAGE, MEMORY_USAGE_GB, NETWORK_TX_GB, DISK_USAGE_GB]'
  AND u.group_by = '[PROJECT_ID]'
  AND p.workspace_id = '<workspace-id>'
ORDER BY project, measurement;
\n

start_date and end_date narrow the window. The projected usage for the current billing period, and the billing position of the workspace:

\n
SELECT project_id, measurement, estimated_value
FROM railway.billing.estimated_usage
WHERE workspace_id = '<workspace-id>'
  AND measurements = '[CPU_USAGE, MEMORY_USAGE_GB]';

SELECT state, current_usage, credit_balance,
       json_extract(billing_period, '$.end') AS period_ends,
       json_extract(usage_limit, '$.hard_limit') AS hard_limit
FROM railway.billing.customers
WHERE workspace_id = '<workspace-id>';
\n

Volumes report their allocated and used size per environment:

\n
SELECT json_extract(volume, '$.name') AS volume, mount_path, region, state,
       size_mb, current_size_mb,
       ROUND(100.0 * current_size_mb / size_mb, 1) AS used_pct
FROM railway.storage.volume_instances
WHERE environment_id = '<environment-id>';
\n

Provisioning​

\n

A project is created with one environment. RETURNING gives back the identifiers the next statements need:

\n
INSERT INTO railway.projects.projects (name, description, workspace_id)
SELECT 'orders', 'order processing', '<workspace-id>'
RETURNING id, name, primary_environment_id;

INSERT INTO railway.environments.environments (project_id, name)
SELECT '<project-id>', 'staging'
RETURNING id, name;
\n

A service from a container image or a repository. A service with a source is deployed when it is created, and a running deployment is billed:

\n
INSERT INTO railway.services.services (project_id, name, source)
SELECT '<project-id>', 'cache', '{\"image\": \"redis:7-alpine\"}'
RETURNING id, name;

INSERT INTO railway.services.services (project_id, name, source, branch)
SELECT '<project-id>', 'api', '{\"repo\": \"my-org/orders-api\"}', 'main'
RETURNING id, name;
\n

Variables are written one at a time or as a set. Writing a variable that exists replaces its value, and skip_deploys keeps the change from triggering a deployment:

\n
INSERT INTO railway.variables.variables
  (project_id, environment_id, service_id, name, value, skip_deploys)
SELECT '<project-id>', '<environment-id>', '<service-id>', 'LOG_LEVEL', 'info', true;

INSERT INTO railway.variables.variables
  (project_id, environment_id, service_id, variables, skip_deploys)
SELECT '<project-id>', '<environment-id>', '<service-id>',
       '{\"SENTRY_DSN\": \"https://example.ingest.sentry.io/1\", \"FEATURE_FLAGS\": \"checkout-v2\"}', true;
\n

A generated domain and a volume for the service:

\n
INSERT INTO railway.networking.service_domains (environment_id, service_id)
SELECT '<environment-id>', '<service-id>'
RETURNING id, domain;

INSERT INTO railway.storage.volumes (project_id, environment_id, service_id, mount_path)
SELECT '<project-id>', '<environment-id>', '<service-id>', '/data'
RETURNING id, name;
\n

Day-two operations​

\n

Changing how a service runs in an environment is an UPDATE. Values in SET are written as quoted strings:

\n
UPDATE railway.services.service_instances
SET num_replicas = '2',
    start_command = 'npm run start',
    healthcheck_path = '/healthz'
WHERE service_id = '<service-id>'
  AND environment_id = '<environment-id>';
\n

Deployment operations are EXEC methods. The SHOWRESULTS hint returns the API's answer, including a refusal:

\n
EXEC /*+ SHOWRESULTS */ railway.services.service_instances.redeploy
  @service_id = '<service-id>',
  @environment_id = '<environment-id>';

EXEC /*+ SHOWRESULTS */ railway.deployments.deployments.restart
  @id = '<deployment-id>';

EXEC /*+ SHOWRESULTS */ railway.deployments.deployments.rollback
  @id = '<deployment-id>';
\n

Preview environment cleanup​

\n

Pull request environments accumulate. The ephemeral environments of a project, with the pull request each one belongs to:

\n
SELECT id, name, created_at,
       json_extract(meta, '$.pr_number') AS pr_number,
       json_extract(meta, '$.branch') AS branch
FROM railway.environments.environments
WHERE project_id = '<project-id>'
  AND is_ephemeral = true
ORDER BY created_at;
\n

Removing one is a DELETE. Running the listing again confirms it is gone:

\n
DELETE FROM railway.environments.environments
WHERE id = '<environment-id>';
\n

A join across providers​

\n

Services deployed from a GitHub repository can be matched to the repository itself, for example to find services still deploying from a repository that has been archived or has not been pushed to in some time. This uses the github provider alongside railway:

\n
SELECT s.service_name,
       r.full_name AS repo, r.archived, r.pushed_at
FROM railway.services.service_instances s
JOIN github.repos.repos r
  ON r.full_name = json_extract(s.source, '$.repo')
WHERE s.environment_id = '<environment-id>'
  AND r.org = 'my-org'
ORDER BY r.pushed_at;
\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull railway;
\n

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

", "url": "https://stackql.io/blog/providers/new-railway-provider-available", "title": "New Railway Provider Available", "summary": "A new StackQL provider for Railway - query and manage workspaces, projects, environments, services, deployments, variables, domains, volumes and usage using SQL - available in the StackQL Provider Registry now.", "date_modified": "2026-09-30T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "railway", "provider", "paas", "deployments", "finops" ] }, { "id": "https://stackql.io/blog/providers/new-gitlab-provider-available", "content_html": "

We've released a new StackQL provider for GitLab:

\n\n

The provider is generated from the introspection schema gitlab.com publishes, pinned by content hash and refreshed as a reviewed diff. It works against gitlab.com out of the box and routes to a self-managed instance from an environment variable. It is read-only by architecture: StackQL's GraphQL path is a query path, so there are no INSERT, UPDATE, DELETE or EXEC methods. What it is for is inventory, reporting and cross-provider joins over the GitLab control plane - the questions that otherwise need a script and three API clients.

\n

Connect​

\n

Authentication is a personal access token with the read_api scope, read from GITLAB_TOKEN - the same variable the Terraform GitLab provider uses:

\n
export GITLAB_TOKEN=glpat-...
stackql shell
\n

Public projects and groups on gitlab.com are readable without a token (--auth='{\"gitlab\": {\"type\": \"null_auth\"}}'). For a self-managed instance, set GITLAB_HOST=gitlab.example.com and every query routes there; an explicit WHERE host = ... still wins for addressing another instance in the same session.

\n

Three scopes, one shape​

\n

Resources follow the GraphQL schema. Instance-scoped resources take optional filters only (projects, users, runners); project-scoped resources are prefixed project_ and take the project path; group-scoped resources are prefixed group_ and take the group path. Columns are snake_case, and the nested identity objects GitLab attaches everywhere (author, namespace, milestone, user) are JSON columns one json_extract away.

\n

Every project in a group tree, with activity and visibility signals:

\n
SELECT full_path, visibility, archived,
       star_count, forks_count,
       open_issues_count, open_merge_requests_count,
       last_activity_at
FROM gitlab.groups.group_projects
WHERE full_path = 'gitlab-org' AND include_subgroups = true
ORDER BY last_activity_at DESC;
\n

GitLab connections are Relay-paginated with a hard page size of 100. StackQL walks the pageInfo cursor chain transparently, so the query above returns the whole tree, not the first page.

\n

Filters are pushed down​

\n

Every scalar or enum argument a GitLab field accepts is a WHERE parameter rendered into the GraphQL query itself, so the API does the filtering. Open merge requests with their approval state and age:

\n
SELECT iid, title,
       json_extract(author, '$.username') AS author,
       draft, approved, approvals_left, detailed_merge_status,
       ROUND(julianday('now') - julianday(created_at)) AS age_days
FROM gitlab.merge_requests.project_merge_requests
WHERE full_path = 'gitlab-org/gitlab-runner' AND state = 'opened'
ORDER BY age_days DESC;
\n

Cycle time over a window (merged_after is a filter, merged_at a column):

\n
SELECT iid, title,
       ROUND((julianday(merged_at) - julianday(created_at)) * 24, 1) AS hours_to_merge
FROM gitlab.merge_requests.project_merge_requests
WHERE full_path = 'gitlab-org/gitlab-runner'
  AND state = 'merged'
  AND merged_after = '2026-09-01T00:00:00Z'
ORDER BY merged_at DESC;
\n

Pipelines and runners​

\n

Pipeline outcomes for a project, and the same across every project in a group by joining the inventory to each project's pipelines (the engine issues one pipelines request per project):

\n
SELECT status, count(*) AS pipelines, ROUND(AVG(duration) / 60.0, 1) AS avg_minutes
FROM gitlab.ci.project_pipelines
WHERE full_path = 'gitlab-org/gitlab-runner'
GROUP BY status;

SELECT p.full_path,
       count(*) AS pipelines,
       SUM(c.status = 'FAILED') AS failed,
       ROUND(100.0 * SUM(c.status = 'FAILED') / count(*), 1) AS failure_pct
FROM gitlab.groups.group_projects p
JOIN gitlab.ci.project_pipelines c ON c.full_path = p.full_path
WHERE p.full_path = 'my-group'
GROUP BY p.full_path
ORDER BY failure_pct DESC;
\n

Runner fleet status for a group, with contact recency (the instance-wide runner listing is administrator-only on gitlab.com; the group and project listings are what a token can read):

\n
SELECT id, description, runner_type, status, paused, contacted_at, upgrade_status
FROM gitlab.ci.group_runners
WHERE full_path = 'my-group'
ORDER BY contacted_at DESC;
\n

Vulnerability reporting​

\n

Findings across a group by severity and state, then the unresolved criticals with their owning project:

\n
SELECT severity, state, count(*) AS findings
FROM gitlab.security.group_vulnerabilities
WHERE full_path = 'my-group'
GROUP BY severity, state;

SELECT json_extract(project, '$.full_path') AS project,
       title, report_type, detected_at, web_url
FROM gitlab.security.group_vulnerabilities
WHERE full_path = 'my-group' AND severity = 'CRITICAL' AND state = 'DETECTED'
ORDER BY detected_at;
\n

Membership, and a join across providers​

\n

Group membership with access level is a table:

\n
SELECT json_extract(user, '$.username') AS username,
       json_extract(user, '$.name') AS name,
       json_extract(access_level, '$.string_value') AS access_level,
       expires_at
FROM gitlab.groups.group_group_members
WHERE full_path = 'my-group';
\n

which makes the offboarding question a LEFT JOIN against the identity provider - GitLab members with no active Okta user, computed locally by the SQL engine after registry pull okta:

\n
SELECT json_extract(m.user, '$.username') AS gitlab_username,
       json_extract(m.user, '$.name') AS gitlab_name,
       o.status AS okta_status
FROM gitlab.groups.group_group_members m
LEFT JOIN okta.user.users o
  ON lower(json_extract(o.profile, '$.login')) = lower(json_extract(m.user, '$.username') || '@example.com')
 AND o.subdomain = 'my-okta-org'
WHERE m.full_path = 'my-group'
  AND (o.status IS NULL OR o.status != 'ACTIVE');
\n

How it is built​

\n\n

Premium-tier fields (issue weight, health status, epics) read back as null on the free tier, and the schema is gitlab.com's, so an older self-managed instance may reject fields it does not serve.

\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull gitlab;
\n

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

", "url": "https://stackql.io/blog/providers/new-gitlab-provider-available", "title": "New GitLab Provider Available", "summary": "A new read-only StackQL provider for GitLab, generated from the GitLab GraphQL schema - projects, groups, members, issues, merge requests, pipelines, jobs, runners, releases, environments, packages, vulnerabilities and more as SQL, with transparent Relay pagination and pushed-down filters - available in the StackQL Provider Registry now.", "date_modified": "2026-09-26T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "gitlab", "provider", "graphql", "devops", "ci-cd", "security" ] }, { "id": "https://stackql.io/blog/providers/anthropic-providers-update-september-2026", "content_html": "

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:

\n\n

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

\n

Dreams​

\n

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:

\n
MethodSQL verbOperation
list, getSELECTlist dreams (cursor-paginated, walked automatically), get a dream
createINSERTstart a dream over one or more inputs
cancel, archiveEXEClifecycle operations
\n

Dreams and their status as rows:

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

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

\n
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;
\n

Files and skills on GA endpoints​

\n

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.

\n
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;
\n

Skill versions are a separate resource keyed by the skill:

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

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.

\n

Workspace-scoped queries​

\n

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:

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

The workspace ids are the ones the anthropic_admin provider lists:

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

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.

\n

Under the hood​

\n

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.

\n

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

\n

Authentication​

\n

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

\n
# 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...
\n

Get started​

\n

Pull the latest provider from the public registry:

\n
registry pull anthropic;
\n

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.

", "url": "https://stackql.io/blog/providers/anthropic-providers-update-september-2026", "title": "Anthropic Providers Update - September 2026", "summary": "Update to the StackQL anthropic provider regenerated from the current Claude API spec - a new dreams service for memory consolidation jobs, files and skills on their GA endpoints, and workspace-scoped queries through the anthropic-workspace-id parameter. The anthropic_admin provider is unchanged.", "date_modified": "2026-09-15T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "anthropic", "claude", "provider", "agents" ] }, { "id": "https://stackql.io/blog/providers/updated-datadog-provider-available", "content_html": "

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.

\n

What's new​

\n

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:

\n\n

Service highlights​

\n
ServiceResourcesOperationsWhat it covers
service_management82281incidents, cases, on-call, SLOs, downtimes, events, status pages, change management, error tracking
security93247security monitoring rules, signals and suppressions, findings and automation, vulnerabilities, CSM, agentless scanning, static analysis, SIEM historical detections
organization85207users, roles, permissions, API and application keys, service accounts, teams, org settings, SAML, audit logs, usage
integrations59192AWS, GCP, Azure, OCI, Jira, ServiceNow, Slack, Microsoft Teams, Google Chat, PagerDuty, Opsgenie, webhooks, Cloudflare, Confluent, Fastly, Okta, reference tables
monitoring39100monitors, synthetics, monitor policies, notification rules, service checks
digital_experience3898RUM applications, events, metrics and retention, replay, product analytics, sourcemaps
llm_observability3783projects, datasets, experiments, prompts, annotation queues, evaluators, Model Lab
cloud_costs3773budgets, AWS / Azure / GCP / OCI cost configs, commitments, tag pipelines, cost attribution
software_delivery2071CI pipelines and tests, DORA, deployment gates, workflows, feature flags, code coverage
dashboards1661dashboards, dashboard lists, powerpacks, notebooks, widgets, annotations, scheduled reports
logs1455indexes, pipelines, archives, custom destinations, log metrics, restriction queries, observability pipelines
infrastructure2847hosts and host tags, containers, processes, network devices, app builder, storage management
metrics1842metrics and metadata, tag configurations, timeseries and scalar queries, datasets, DDSQL
apm1027retention filters, spans metrics, scorecards, traces
remote_config627CSM Threats agent rules and policies, WAF rules and policies
actions623action connections, datastores, execution policies
fleet616agents, deployments, schedules, tracers
catalog38software catalog entities, kinds, relations
\n

Authentication​

\n

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

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

Monitors​

\n

Every monitor with its state:

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

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

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

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

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

Dashboards, SLOs and synthetics​

\n
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;
\n

Users, roles and keys​

\n

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

\n
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;
\n

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

\n
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;
\n

Infrastructure and logs​

\n

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

\n
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;
\n

Audit log​

\n

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

\n
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';
\n

Security monitoring rules​

\n

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

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

Provisioning​

\n

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:

\n
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;
\n

A downtime for a release window, and a role:

\n
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>';
\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull datadog;
\n

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

", "url": "https://stackql.io/blog/providers/updated-datadog-provider-available", "title": "Datadog Provider - August 2026", "summary": "The StackQL Datadog provider now covers the v1 and v2 REST APIs together - monitors, dashboards, synthetics, SLOs, downtimes, incidents, cases, on-call, logs configuration, metrics, security monitoring, cloud cost, users, roles and keys, integrations, RUM, LLM Observability and fleet automation.", "date_modified": "2026-08-26T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "datadog", "provider", "observability", "monitors", "security", "finops" ] }, { "id": "https://stackql.io/blog/providers/new-kubernetes-provider-available", "content_html": "

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

\n\n

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.

\n

Connect with kubectl proxy​

\n

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:

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

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).

\n

The cluster is a database​

\n

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:

\n
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;
\n

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

\n
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');
\n

Desired versus ready replicas for every deployment in a namespace:

\n
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';
\n

Node inventory with kubelet version and schedulability:

\n
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;
\n

RBAC audit and warning events​

\n

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:

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

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

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

Server-side filtering and pagination​

\n

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

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

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.

\n

Provision, mutate and tear down​

\n

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:

\n
-- 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';
\n

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

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

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

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

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

\n

Who am I, and can I​

\n

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:

\n
-- 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;
\n

What changed from the original provider​

\n

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

\n\n

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

\n

Direct authentication​

\n

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:

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

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.

\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull k8s;
\n

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

", "url": "https://stackql.io/blog/providers/new-kubernetes-provider-available", "title": "New Kubernetes Provider Available", "summary": "A ground-up rebuild of the StackQL k8s provider - every built-in Kubernetes control plane API group as SQL, with subresources, server-side filtering, transparent pagination, and a full write lifecycle, pointable at any conformant cluster - available in the StackQL Provider Registry now.", "date_modified": "2026-08-25T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "kubernetes", "k8s", "provider", "cloud-native", "rbac", "audit" ] }, { "id": "https://stackql.io/blog/providers/aws-provider-update-august-2026", "content_html": "

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

\n\n

New Services​

\n

Nine services are new in this release:

\n
ServiceDescription
resiliencehubv2The next generation of AWS Resilience Hub - assess and improve the resilience of critical applications at scale, the largest new service in this release
lambda_microvmsCreate, manage and operate AWS Lambda MicroVMs and their associated MicroVM image environments
lambda_coreShared infrastructure resources for Lambda, including network connectors that give MicroVMs access to resources in your VPC
agent_registry_controlManaged catalog for publishing and discovering MCP servers, agents and agent skills - control plane for registries and records
agent_registryData-plane discovery of approved records published to an Agent Registry
account_accessAccount access manager - manage applications and entitlements that grant IAM Identity Center principals access to IAM roles across accounts
supportauthzSupport authorization - cryptographically signed support permits controlling which actions AWS support operators can perform on your resources
pricing_plan_managerFlat-rate pricing subscriptions - create, approve and cancel subscriptions and associate resources with them
sagemakerjobruntimeAgentic RFT runtime - trajectory and transition data for reinforcement fine-tuning jobs
\n

Expanded Coverage in Existing Services​

\n\n

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

\n

S3 Object Content Lifecycles​

\n

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.

\n

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

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

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

\n
-- 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';
\n

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

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

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.

\n

Get Started​

\n

Pull the latest provider from the public registry:

\n
stackql registry pull aws;
\n

Authenticate with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, then explore:

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

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.

", "url": "https://stackql.io/blog/providers/aws-provider-update-august-2026", "title": "AWS Provider Update - August 2026", "summary": "Update to the StackQL AWS provider adding nine new services including Resilience Hub V2, Lambda MicroVMs, Agent Registry and Support AuthZ, expanded coverage across EC2, ACM, QuickSight, Bedrock AgentCore and more, plus full S3 object content lifecycles - read, write, replace and delete object contents with SQL.", "date_modified": "2026-08-20T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "aws", "amazon web services", "provider", "s3" ] }, { "id": "https://stackql.io/blog/providers/new-clickhouse-provider-available", "content_html": "

We've released a new StackQL provider for ClickHouse Cloud:

\n\n

The provider covers the Cloud management API only. The ClickHouse server HTTP interface - SQL against a service endpoint and the system.* tables - is a separate surface with separate authentication and is reserved as a future sibling provider, clickhouse_server. What takes two Terraform providers today (the Cloud infrastructure provider and the DBops provider) will be two namespaces in one StackQL session.

\n

Organization scope from the environment​

\n

Every resource except organizations is scoped to an organization. The organization ID is a server variable that StackQL resolves from CLICKHOUSE_ORG_ID when it is set, so queries carry no organization clause:

\n
SELECT name, state, provider, region
FROM clickhouse.services.services;
\n

A WHERE organization_id = '...' still takes precedence when you need to address another organization in the same session. Columns and WHERE/INSERT keys are snake_case (created_at, ip_access_list, service_id); the provider maps them to the API's camelCase on the wire.

\n

Estate inventory​

\n

State, footprint and scaling configuration for every service in one result set:

\n
SELECT name, state, provider, region,
       num_replicas,
       min_replica_memory_gb, max_replica_memory_gb,
       json_extract(current_scaling, '$.effectiveAutoscalingMode') AS scaling_mode,
       idle_scaling, idle_timeout_minutes, clickhouse_version
FROM clickhouse.services.services
ORDER BY provider, region, name;
\n

Organization quotas report usage against limits, which is the quickest answer to \"how much room is left\":

\n
SELECT quota_code, name, value AS quota_limit, usage
FROM clickhouse.organizations.quotas;
\n

Usage cost by day and entity​

\n

The usage cost endpoint returns one row per entity per day in ClickHouse Credits, with the compute, storage, backup and data-transfer components in a metrics object:

\n
SELECT date, entity_type, entity_name, total_chc,
       json_extract(metrics, '$.computeCHC') AS compute_chc,
       json_extract(metrics, '$.storageCHC') AS storage_chc,
       json_extract(metrics, '$.backupCHC')  AS backup_chc
FROM clickhouse.organizations.usage_costs
WHERE from_date = '2026-08-01' AND to_date = '2026-08-31'
ORDER BY date, entity_name;
\n

Joined to the services list, the same data answers which stopped or idle services still carried cost in the window:

\n
SELECT s.name, s.state, SUM(c.total_chc) AS chc_in_window
FROM clickhouse.services.services s
JOIN clickhouse.organizations.usage_costs c
  ON c.service_id = s.id
WHERE c.from_date = '2026-08-01' AND c.to_date = '2026-08-31'
  AND s.state IN ('stopped', 'idle')
GROUP BY s.name, s.state
ORDER BY chc_in_window DESC;
\n

Scaffolding​

\n

Provisioning is the usual SQL verbs. A service is an INSERT; the state command (start, stop, awake) is an EXEC; access-list changes are an UPDATE whose PATCH body takes add/remove arrays, passed through as written:

\n
INSERT INTO clickhouse.services.services
  (name, provider, region, min_replica_memory_gb, max_replica_memory_gb, num_replicas, idle_scaling, idle_timeout_minutes)
SELECT 'analytics-dev', 'aws', 'us-east-1', 8, 8, 1, true, 15;

UPDATE clickhouse.services.services
SET ip_access_list = '{\"add\": [{\"source\": \"203.0.113.0/24\", \"description\": \"office\"}],
                       \"remove\": [{\"source\": \"0.0.0.0/0\", \"description\": \"Anywhere\"}]}'
WHERE service_id = '<service-uuid>';

EXEC clickhouse.services.services.update_state
  @serviceId = '<service-uuid>',
  @command = 'stop';
\n

Organizations that use Custom Roles assign API key roles by ID, so the role lookup and the key creation are one statement, and the generated secret comes back with RETURNING:

\n
INSERT INTO clickhouse.keys.keys (name, assigned_role_ids, state)
SELECT 'finops-reader', '[\"' || id || '\"]', 'enabled'
FROM clickhouse.roles.roles
WHERE name = 'Organization API Reader'
RETURNING json_extract(result, '$.key.id')    AS id,
          json_extract(result, '$.keyId')     AS key_id,
          json_extract(result, '$.keySecret') AS key_secret;
\n

Backup configuration is queryable across the estate, and settable per service:

\n
SELECT s.name, b.backup_period_in_hours, b.backup_retention_period_in_hours, b.backup_start_time
FROM clickhouse.services.services s
JOIN clickhouse.backups.backup_configurations b
  ON b.service_id = s.id;
\n

Observability as code​

\n

ClickStack dashboards, alerts, sources, webhooks and saved searches are resources with full CRUD, so a dashboard definition lives in version control and is applied with an INSERT:

\n
INSERT INTO clickhouse.clickstack.dashboards (service_id, name, tiles, tags)
SELECT '<service-uuid>', 'Service Overview',
       '[{\"name\": \"Error rate\", \"x\": 0, \"y\": 0, \"w\": 6, \"h\": 3,
          \"config\": {\"displayType\": \"line\",
                     \"select\": [{\"aggFn\": \"count\", \"where\": \"SeverityText = ''ERROR''\"}]}}]',
       '[\"production\"]';
\n

and audited with a SELECT:

\n
SELECT d.name, json_array_length(d.tiles) AS tiles, d.tags
FROM clickhouse.clickstack.dashboards d
WHERE d.service_id = '<service-uuid>';
\n

Alerts and webhooks follow the same pattern (clickhouse.clickstack.alerts, clickhouse.clickstack.webhooks), and the organization activity log is a table for audit questions:

\n
SELECT created_at, type, actor_type, actor_details
FROM clickhouse.organizations.activities
ORDER BY created_at DESC;
\n

The data platform estate in one query​

\n

Cross-provider joins are ordinary SQL, so ClickHouse Cloud services sit alongside Snowflake warehouses and Databricks clusters in one inventory:

\n
SELECT 'clickhouse' AS platform, name, state, region
FROM clickhouse.services.services
UNION ALL
SELECT 'snowflake', name, state, NULL
FROM snowflake.warehouses.warehouses
UNION ALL
SELECT 'databricks', cluster_name, state, NULL
FROM databricks_workspace.compute.clusters
WHERE deployment_name = '<workspace>';
\n

Authentication​

\n

Create an API key pair in the ClickHouse Cloud console (Settings -> API Keys) with the role the queries need - Organization API Reader / Service API Reader for inventory and cost queries, Service API Admin for provisioning - and export three variables:

\n
export CLICKHOUSE_CLOUD_API_KEY=...      # Key ID
export CLICKHOUSE_CLOUD_API_SECRET=...   # Key Secret
export CLICKHOUSE_ORG_ID=...             # organization ID
\n

The API allows a fixed window of requests per key (documented as 10 per 10 seconds); a 429 is the signal to pace wide scans.

\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull clickhouse
\n

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

", "url": "https://stackql.io/blog/providers/new-clickhouse-provider-available", "title": "New ClickHouse Cloud Provider Available", "summary": "A new StackQL provider for the ClickHouse Cloud API - query and provision organizations, services, API keys, members and roles, backups, ClickPipes, ClickStack dashboards and alerts, UDFs and Managed Postgres, and report usage cost by day and entity, using SQL - available in the StackQL Provider Registry now.", "date_modified": "2026-08-17T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "clickhouse", "clickhouse-cloud", "provider", "finops", "clickstack", "observability" ] }, { "id": "https://stackql.io/blog/providers/google-provider-update-august-2026", "content_html": "

We've released an update to the StackQL Google provider, regenerated from the latest Google API discovery documents. The google provider now covers 187 services, 2,183 resources and over 9,100 operations - up from 179 services, 1,966 resources and 8,423 operations in the previous release. The companion providers in the google family (googleworkspace, googleadmin and firebase) were regenerated in the same pass.

\n

New Services​

\n

Eleven services are new in this release:

\n
ServiceDescription
agentregistryCentralized catalog to store, discover and govern MCP servers, tools and AI agents within Google Cloud
agentidentityIdentities and authorization for AI agents - auth providers, authorizations and access summaries
agentidentitycredentialsShort-lived credential issuance for agent identities
cesGemini Enterprise for Customer Experience - agents, apps, deployments, conversations, guardrails and tool schemas
hypercomputeclusterCluster Director - deploy, manage and monitor AI/ML and HPC clusters
databasecenterOrganization-wide database fleet health monitoring across projects and folders
metastoreDataproc Metastore - services, backups, federations, metadata imports and migrations
threatintelligenceGoogle Threat Intelligence - alerts, findings, documents and configurations
cloudnumberregistryIP address management - realms, registry books, custom and discovered ranges
developerknowledgeProgrammatic access to Google developer documentation
healthGoogle Health API (v4) - health and fitness metrics, data points, devices and subscriptions
\n

Expanded Coverage in Existing Services​

\n\n

Another 50+ services picked up incremental resources and operations, including discoveryengine, contactcenterinsights, netapp, artifactregistry, assuredworkloads and dataproc.

\n

Removed Services​

\n

Google has retired several APIs since the last release, and they are removed from the provider accordingly:

\n\n

The duplicate *_aggregated helper resources in compute were also consolidated - cross-zone queries are served by the primary resources, so a zone-less SELECT fans out across all zones:

\n
SELECT name, status, machineType, zone
FROM google.compute.instances
WHERE project = 'my-project';
\n

Example: Open Firewall Audit​

\n

Ingress rules open to the entire internet, and what they allow:

\n
SELECT
  name,
  direction,
  sourceRanges,
  allowed
FROM google.compute.firewalls
WHERE project = 'my-project'
AND sourceRanges LIKE '%0.0.0.0/0%';
\n

Get Started​

\n

Pull the latest provider from the public registry:

\n
stackql registry pull google;
\n

Authenticate with a service account key in the GOOGLE_CREDENTIALS environment variable (or interactively via gcloud auth login), then explore:

\n
SELECT
  json_extract(config, '$.name') AS api,
  state
FROM google.serviceusage.services
WHERE parent = 'my-project'
AND parentType = 'projects'
AND filter = 'state:ENABLED';
\n

Provider docs, including getting-started queries for each provider in the family, are at google-provider.stackql.io, googleworkspace-provider.stackql.io, googleadmin-provider.stackql.io and firebase-provider.stackql.io. Visit us on GitHub and let us know how you're using it.

", "url": "https://stackql.io/blog/providers/google-provider-update-august-2026", "title": "Google Provider Update - August 2026", "summary": "Update to the StackQL Google provider adding eleven new services including Agent Registry, Agent Identity, Cluster Director, Database Center and Google Threat Intelligence, a major expansion of Compute Engine and Vertex AI coverage, and removal of APIs retired by Google.", "date_modified": "2026-08-06T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "google cloud", "gcp", "provider", "vertex-ai", "compute-engine" ] }, { "id": "https://stackql.io/blog/providers/new-gemini-provider-available", "content_html": "

We've released a new StackQL provider for the Google Gemini API:

\n\n

Everything reachable with a GEMINI_API_KEY ships in one provider. Authentication is handled automatically, LIMIT is pushed down to the wire, and paginated lists are walked for you.

\n

Inference as a result set​

\n

Asking Gemini a question is a SELECT. The reply comes back as a row, with the text in the candidates array and the token spend in usageMetadata:

\n
SELECT
  JSON_EXTRACT(candidates, '$[0].content.parts[0].text') AS reply,
  JSON_EXTRACT(usageMetadata, '$.totalTokenCount') AS total_tokens
FROM gemini.models.content
WHERE modelsId = 'gemini-2.5-flash'
AND contents = '[{\"parts\":[{\"text\":\"Name the four Galilean moons of Jupiter, comma separated.\"}]}]';
\n

Token counting works the same way via gemini.models.token_counts - free of charge, so a prompt can be priced before it is sent. Embeddings come back as rows too:

\n
SELECT JSON_EXTRACT(embedding, '$.values[0]') AS first_dimension
FROM gemini.models.embeddings
WHERE modelsId = 'gemini-embedding-001'
AND content = '{\"parts\":[{\"text\":\"stackql lets you query cloud APIs with SQL\"}]}';
\n

Which model can do what​

\n

The provider ships a convenience view that fans each model's supported generation methods and limits out into flat columns:

\n
SELECT name, display_name, input_token_limit, thinking, supports_generate_content
FROM gemini.models.vw_model_capabilities
ORDER BY name;
\n

One row per model with token limits, default sampling parameters, and boolean flags for content generation, token counting, embedding, batching and caching support - useful for picking a model programmatically instead of reading release notes.

\n

The management surface as SQL​

\n

Files, cached contents, corpora, file search stores and tuned models are managed with the corresponding SQL verbs:

\n
-- create
INSERT INTO gemini.corpora.corpora (displayName)
SELECT 'my-knowledge-base'
RETURNING name, displayName;

-- read
SELECT name, displayName, mimeType, sizeBytes, state
FROM gemini.files.files;

-- update
UPDATE gemini.cached_contents.cached_contents
SET ttl = '600s'
WHERE cachedContentsId = 'my-cache-id';

-- delete
DELETE FROM gemini.cached_contents.cached_contents
WHERE cachedContentsId = 'my-cache-id';
\n

Batches are long-running operations and follow the async job pattern: SELECT polls them, EXEC runs the lifecycle ops:

\n
SELECT name, done, JSON_EXTRACT(metadata, '$.state') AS state
FROM gemini.batches.batches;

EXEC gemini.batches.batches.cancel @batchesId = 'my-batch-id';
\n

Tuned model permissions are a full CRUD surface as well, so sharing a tuned model is an INSERT and auditing who can see it is a SELECT.

\n

One credential, one boundary​

\n

The provider covers the Gemini API surface under a GEMINI_API_KEY. Billing, quota, API key management and IAM are GCP control-plane services (cloudbilling, serviceusage, apikeys, iam) that authenticate with OAuth/ADC - they live in the google provider. StackQL does cross-provider joins, so the two compose; worked examples are at gemini-provider.stackql.io/google-control-plane.

\n

Authentication​

\n

Set a single environment variable:

\n
export GEMINI_API_KEY=...
\n

Keys are created in Google AI Studio. The key is only ever sent as a request header (x-goog-api-key) - never in the URL query string.

\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull gemini
\n

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

", "url": "https://stackql.io/blog/providers/new-gemini-provider-available", "title": "New Google Gemini Provider Available", "summary": "A new StackQL provider for the Google Gemini API - run Gemini inference, count tokens, generate embeddings, and manage models, tuned models, files, cached contents, corpora, file search stores and batches using SQL - available in the StackQL Provider Registry now.", "date_modified": "2026-08-03T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "gemini", "google", "generative language", "provider", "inference", "embeddings", "tuned models", "file search" ] }, { "id": "https://stackql.io/blog/providers/databricks-providers-update-july-2026", "content_html": "

We've released an update to the StackQL Databricks providers, regenerated from the latest Databricks platform APIs (SDK v0.123.0):

\n\n

Includes 392 resources and over 1,200 operations across both providers, including four new services and more than 70 new or restructured resources.

\n

New Services​

\n
ProviderServiceDescription
databricks_accountdisasterrecoveryManage disaster recovery failover groups and stable URLs for workspace failover across regions
databricks_workspaceaisearchDatabricks AI Search endpoints and indexes, including data plane operations to query, scan, sync and upsert index data
databricks_workspacebundledeploymentsDatabricks Asset Bundle deployments - deployments, versions, operations and deployed resources
databricks_workspacesupervisoragentsAgent Bricks supervisor agents - agents, tools, examples and permissions
\n

Expanded Coverage in Existing Services​

\n\n

SQL Statement Execution Improvements​

\n

StackQL lets you traverse the Databricks control plane and data plane in the same query surface. This release cleans up the verb mappings for databricks_workspace.sql.statement_execution, so the full statement lifecycle maps naturally to SQL:

\n
/* submit a statement to a SQL warehouse */
INSERT INTO databricks_workspace.sql.statement_execution (
  statement,
  warehouse_id,
  wait_timeout,
  deployment_name
)
SELECT
  'SELECT * FROM samples.nyctaxi.trips LIMIT 100',
  '<warehouse_id>',
  '0s',
  '<deployment_name>';

/* poll for status and results */
SELECT status, manifest, result
FROM databricks_workspace.sql.statement_execution
WHERE statement_id = '<statement_id>'
AND deployment_name = '<deployment_name>';

/* cancel a running statement */
DELETE FROM databricks_workspace.sql.statement_execution
WHERE statement_id = '<statement_id>'
AND deployment_name = '<deployment_name>';
\n

The cancel operation is now mapped to the DELETE verb (previously INSERT), and sql.query_history now projects one row per query with server-side pagination wired in, so large result sets append across pages automatically.

\n

Built-in Views​

\n

Both providers ship with curated views that flatten common multi-step queries into a single SELECT, and this release adds views for Lakebase alongside the existing IAM, billing, provisioning, networking and settings views - 49 views in total. For example:

\n
SELECT *
FROM databricks_account.iam.vw_account_user_roles
WHERE account_id = '<account_id>';

SELECT key, value
FROM databricks_workspace.settings.vw_all_settings
WHERE deployment_name = '<deployment_name>';
\n

Get Started​

\n

Pull the latest providers from the public registry:

\n
stackql registry pull databricks_account
stackql registry pull databricks_workspace
\n

Authenticate with the same service principal environment variables used by Terraform and the Databricks CLI (DATABRICKS_ACCOUNT_ID, DATABRICKS_CLIENT_ID, DATABRICKS_CLIENT_SECRET), then explore:

\n
SELECT workspace_id, workspace_name, workspace_status, deployment_name
FROM databricks_account.provisioning.workspaces
WHERE account_id = '<account_id>';
\n

Provider docs are at databricks-account-provider.stackql.io and databricks-workspace-provider.stackql.io. Visit us on GitHub and let us know how you're using it.

", "url": "https://stackql.io/blog/providers/databricks-providers-update-july-2026", "title": "Databricks Providers Update - July 2026", "summary": "Update to the StackQL Databricks providers adding four new services including disaster recovery, AI Search, bundle deployments and supervisor agents, a major expansion of Lakebase (Postgres) and identity coverage, and improved SQL statement execution semantics including DELETE to cancel running statements.", "date_modified": "2026-07-31T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "databricks", "provider", "lakebase", "unity-catalog", "agent-bricks" ] }, { "id": "https://stackql.io/blog/providers/openai-providers-update-july-2026", "content_html": "

We've released an update to the StackQL providers for the OpenAI platform:

\n\n

Both providers expose a SQL-first surface: authentication is handled automatically, push down support using the LIMIT clause and built in pagination handling.

\n

The openai provider is a ground-up rebuild of the previous provider, generated from the vendor's published OpenAPI specification. Some resources have been renamed and the organization/admin surface has moved to openai_admin - the previous provider version remains available in the registry for pinning, and the full disposition is documented at openai-provider.stackql.io.

\n

Async jobs as SQL​

\n

Fine-tuning jobs, batches, vector store file batches and uploads follow the same pattern: INSERT creates the job, SELECT polls it, EXEC cancels it. For example:

\n
SELECT id, status, model, fine_tuned_model, trained_tokens
FROM openai.fine_tuning.jobs;

SELECT id, status, endpoint, request_counts
FROM openai.batches.batches
LIMIT 10;
\n

Vector stores are a full CRUD surface with file membership:

\n
SELECT id, name, status, usage_bytes, file_counts
FROM openai.vector_stores.vector_stores;
\n

Inference endpoints (chat/completions, responses, embeddings, images, audio) are deliberately out of scope - the provider covers the control plane; use the vendor SDKs for invocation.

\n

The admin provider - your OpenAI org as data​

\n

The openai_admin provider presents the organization management surface as SQL.

\n

Usage and cost are bucketed time series: one row per time bucket, with the per-group breakdown in the results JSON column, fanned out with JSON_EACH. Token usage by project and model over a 30-day window:

\n
SELECT
  json_extract(r.value, '$.project_id')    AS project_id,
  json_extract(r.value, '$.model')         AS model,
  strftime('%Y-%m-%d', u.start_time, 'unixepoch') AS usage_date,
  json_extract(r.value, '$.input_tokens')  AS input_tokens,
  json_extract(r.value, '$.output_tokens') AS output_tokens
FROM openai_admin.usage.completions u, json_each(u.results) r
WHERE u.start_time = 1781481600
  AND u.bucket_width = '1d'
  AND u.limit = 31
  AND u.group_by = 'project_id'
ORDER BY usage_date, project_id;
\n

Daily spend in USD by project:

\n
SELECT
  strftime('%Y-%m-%d', c.start_time, 'unixepoch') AS cost_date,
  json_extract(r.value, '$.project_id')   AS project_id,
  json_extract(r.value, '$.amount.value') AS amount_usd
FROM openai_admin.costs.costs c, json_each(c.results) r
WHERE c.start_time = 1781481600
  AND c.limit = 180
  AND c.group_by = 'project_id'
ORDER BY cost_date, amount_usd DESC;
\n

Usage is broken out per capability - completions, embeddings, moderations, images, audio, vector stores and code interpreter sessions - and can be grouped by project_id, api_key_id or model.

\n

Governance and auditing​

\n

Projects and their child resources (users, service accounts, API keys, rate limits) are queryable and writable:

\n
SELECT p.name AS project, p.status, sa.name AS service_account, sa.role
FROM openai_admin.projects.projects p
JOIN openai_admin.projects.service_accounts sa ON sa.project_id = p.id
WHERE p.status = 'active';
\n

Admin key hygiene and audit logs work the same way:

\n
SELECT name, created_at, last_used_at, owner
FROM openai_admin.admin_api_keys.admin_api_keys
ORDER BY created_at;

SELECT id, type, effective_at, actor, project
FROM openai_admin.audit_logs.audit_logs
WHERE \"effective_at[gt]\" = 1750000000
  AND \"event_types[]\" = 'project.created';
\n

Because it's all SQL, you can join usage to projects, materialize daily cost snapshots into a database, or point a BI tool at StackQL's Postgres wire protocol server and build an org-wide OpenAI spend dashboard without writing a line of integration code.

\n

Authentication​

\n

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

\n
# openai - standard API key
export OPENAI_API_KEY=sk-...

# openai_admin - org-scoped admin key (created by organization owners)
export OPENAI_ADMIN_KEY=sk-admin-...
\n

Admin keys are available to organization accounts only and can be provisioned by organization owners in the platform console. A standard key cannot call the admin endpoints and vice versa.

\n

Get started​

\n

Pull the providers from the public registry:

\n
registry pull openai
registry pull openai_admin
\n

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

", "url": "https://stackql.io/blog/providers/openai-providers-update-july-2026", "title": "OpenAI Providers Update - July 2026", "summary": "Latest release of the StackQL OpenAI providers - openai for the platform API (models, files, fine-tuning, batches, vector stores, evals and more) and openai_admin for organization management, usage and cost reporting, projects, RBAC and audit logs - are available in the StackQL Provider Registry now.", "date_modified": "2026-07-20T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "openai", "provider", "admin api", "usage reporting", "cost reporting", "finops", "projects", "audit logs", "enterprise" ] }, { "id": "https://stackql.io/blog/providers/azure-provider-update-july-2026", "content_html": "

We've released a major update to the StackQL Azure provider family:

\n\n

Service, resource and method names are consistently snake_cased, service titles carry the official Azure product names, and related services have been consolidated - SHOW SERVICES IN azure now reads like the Azure portal, not like an SDK package index.

\n

Control plane and data plane in one provider​

\n

Most Azure tooling stops at ARM. This provider exposes Azure data plane APIs alongside the ARM control plane as first-class services, so the same SQL surface that manages a resource can work with what's inside it.

\n

Enumerate Key Vaults in a subscription (control plane), then list the secrets in one of them (data plane):

\n
SELECT name, location
FROM azure.key_vault.vaults
WHERE subscription_id = '<subscription_id>';

SELECT id, content_type, attributes
FROM azure.key_vault_secrets.secrets
WHERE vault_name = 'my-vault';
\n

The same pattern extends across the platform - Storage blobs, queues and file shares, Cosmos DB tables, App Configuration key-values, Event Grid publishing, Container Registry repositories, Azure Monitor log queries and ingestion, Azure Maps, Azure AI Search documents, Service Fabric cluster operations, Batch jobs, and the Synapse and Purview workspace APIs are all present as data plane services next to their management planes.

\n

The AI surface​

\n

The biggest expansion in this release is AI - 20 services covering Azure AI Foundry and the Azure AI services portfolio:

\n\n

Inventory every Azure AI services account in a subscription, with kind and provisioning state:

\n
SELECT name, kind, location, provisioning_state
FROM azure.cognitive_services.accounts
WHERE subscription_id = '<subscription_id>';
\n

ARM's nested properties envelope is flattened at query time, so attributes like provisioning_state are ordinary columns - no JSON extraction needed for the common case.

\n

More new and expanded coverage​

\n\n

Authentication​

\n

The provider uses Azure's standard credential chain - an az login session works as-is, or set service principal credentials:

\n
export AZURE_TENANT_ID=<tenant_id>
export AZURE_CLIENT_ID=<client_id>
export AZURE_CLIENT_SECRET=<client_secret>
\n

Get started​

\n

Pull the providers from the public registry:

\n
registry pull azure
registry pull azure_extras
registry pull azure_isv
registry pull azure_stack
\n

Then explore - it's just SQL:

\n
SELECT name, location, provisioning_state, vm_id
FROM azure.compute.virtual_machines
WHERE subscription_id = '<subscription_id>';
\n

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

", "url": "https://stackql.io/blog/providers/azure-provider-update-july-2026", "title": "Azure Provider Update - July 2026", "summary": "Major update to the StackQL Azure provider - 268 services covering the ARM control plane and Azure data planes in one provider, with expanded AI coverage including Azure AI Foundry, AI Language, Document Intelligence, Content Safety and more, available in the StackQL Provider Registry now.", "date_modified": "2026-07-16T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "azure", "provider", "arm", "azure ai", "ai foundry", "key vault", "cosmos db", "data plane", "cloud inventory", "finops" ] }, { "id": "https://stackql.io/blog/providers/anthropic-providers-update-july-2026", "content_html": "

We've released an update to the StackQL providers for the Anthropic platform:

\n\n

Both providers expose a SQL-first surface: authentication is handled automatically, Push down support using the LIMIT clause and built in pagination handling.

\n

Inference as a query​

\n

Inference using Claude is accessible via SELECT for instance:

\n
SELECT
id,
model,
stop_reason,
JSON_EXTRACT(content, '$[0].text') AS assistant_message,
JSON_EXTRACT(usage, '$.output_tokens') AS output_tokens
FROM anthropic.messages.messages
WHERE model = 'claude-sonnet-5'
AND max_tokens = 2048
AND messages = '[
  {
    \"role\": \"user\",
    \"content\": \"how does stackql work?\"
  }
]'
AND system = 'You are a technical assistant. Answer in one short paragraph.'
AND thinking = '{\"type\": \"disabled\"}';
\n

Token counting works the same way via anthropic.messages.token_counts - free of charge.

\n

Model capabilities view​

\n

The provider ships a convenience view that fans the per-model capability matrix out of the capabilities JSON column into flat columns:

\n
SELECT id, display_name, thinking, adaptive, xhigh, max_input_tokens, max_tokens
FROM anthropic.models.vw_model_capabilities;
\n

One row per model with boolean flags for batch, citations, code execution, context management, effort tiers (low through xhigh), image and PDF input, structured outputs, and thinking modes - useful for picking a model programmatically instead of reading release notes.

\n

The admin provider - your Anthropic org as data​

\n

The anthropic_admin provider presents the organization management surface as SQL.

\n

Enumerate workspaces and who's in them:

\n
SELECT id, name, created_at, data_residency
FROM anthropic_admin.workspaces.workspaces;

SELECT user_id, workspace_id, workspace_role
FROM anthropic_admin.workspaces.members
WHERE workspace_id = '<workspace_id>';
\n

Audit users and API keys across the org:

\n
SELECT id, email, name, role
FROM anthropic_admin.organization.users;

SELECT id, name, status, workspace_id, partial_key_hint
FROM anthropic_admin.api_keys.api_keys;
\n

Pull usage reports as time-bucketed rows - results is a JSON column you can break down with JSON_EACH, and reports can be grouped and filtered by model, workspace, API key, service tier, and more:

\n
SELECT starting_at, ending_at, results
FROM anthropic_admin.usage.usage_reports
WHERE starting_at = '2026-07-01T00:00:00Z'
AND \"group_by[]\" = 'model';
\n

Cost reporting and Claude Code adoption analytics work the same way:

\n
SELECT starting_at, ending_at, results
FROM anthropic_admin.cost.cost_reports
WHERE starting_at = '2026-07-01T00:00:00Z';

SELECT starting_at, ending_at, results
FROM anthropic_admin.usage.claude_code_reports
WHERE starting_at = '2026-07-01T00:00:00Z';
\n

Because it's all SQL, you can join usage to workspaces, materialize daily cost snapshots into a database, or point a BI tool at StackQL's Postgres wire protocol server and build an org-wide Claude spend dashboard without writing a line of integration code.

\n

Authentication​

\n

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

\n
# 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...
\n

Admin keys are available to organization accounts only and can be provisioned by users with the admin role in the Console.

\n

Get started​

\n

Pull the providers from the public registry:

\n
registry pull anthropic
registry pull anthropic_admin
\n

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

", "url": "https://stackql.io/blog/providers/anthropic-providers-update-july-2026", "title": "Anthropic Providers Update - July 2026", "summary": "Latest release of the StackQL Anthropic providers - anthropic for the Claude API (messages, agents, sessions, skills, files, vaults and more) and anthropic_admin for enterprise organization management, usage and cost reporting, and Claude Code analytics - are available in the StackQL Provider Registry now.", "date_modified": "2026-07-10T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "anthropic", "claude", "provider", "admin api", "usage reporting", "cost reporting", "claude code", "agents", "enterprise" ] }, { "id": "https://stackql.io/blog/providers/updated-cloudflare-provider-available", "content_html": "

We've released the latest version of the StackQL Cloudflare provider, including the full Cloudflare V4 API surface under SQL with 108 services, 1259 resources, and 2840 operations.

\n

Service highlights​

\n

Key services in this release include:

\n
ServiceResourcesOperationsWhat it covers
zero_trust155427Access apps, gateway, tunnels, identity providers, device posture
radar266273Internet measurement: BGP, traffic, attacks, AS info, quality
cloudforce_one56130Threat intel: requests, priorities, scans, threat events
ai114116Workers AI inference across 100+ models
workers39107Scripts, deployments, KV, Durable Objects, queues, cron triggers
magic_transit2190Magic WAN: sites, connectors, GRE/IPsec tunnels, routes
zones2664Zone lifecycle, settings, SSL/TLS, page rules, custom hostnames
realtime_kit2763RealtimeKit meetings, sessions, recordings, presets
dns1958DNS records, zone transfers, firewall, analytics
load_balancers1254Pools, monitors, regions, search
aisearch2048AI Search indexes, ingest jobs, models
email_security1547Area 1: alerts, allow/block policies, investigation
firewall1047WAF rules, packages, lockdowns, access rules, UA rules
streams1347Stream video uploads, live inputs, signed URLs, captions
api_gateway1743API discovery, schemas, operations, settings
r21742Buckets, lifecycle, CORS, custom domains, event notifications
\n

Authentication​

\n

Authenticate with a Cloudflare API token via the CLOUDFLARE_API_TOKEN environment variable:

\n
export CLOUDFLARE_API_TOKEN=...
\n

Example queries​

\n

List your zones:

\n
SELECT id, name, status, plan
FROM cloudflare.zones.zones
WHERE account.id = '<account_id>';
\n

Inspect Workers scripts in an account:

\n
SELECT id, modified_on, usage_model
FROM cloudflare.workers.scripts
WHERE account_id = '<account_id>';
\n

List DNS records for a zone:

\n
SELECT name, type, content, ttl, proxied
FROM cloudflare.dns.records
WHERE zone_id = '<zone_id>';
\n

Pull a Radar BGP summary:

\n
SELECT *
FROM cloudflare.radar.routes_stats;
\n

Binary and non-JSON responses​

\n

A number of Cloudflare endpoints return binary or plain-text payloads - PDF LOAs, PNG screenshots, raw script source, CSV exports. The provider wraps these as a one-row table with a contents column so they're still SELECT-able:

\n
SELECT contents
FROM cloudflare.browser_rendering.screenshot
WHERE account_id = '<account_id>' AND url = 'https://example.com';
\n

Get started​

\n

Pull the provider from the public registry:

\n
registry pull cloudflare
\n

Then start querying. Let us know what you build. Star us on GitHub.

", "url": "https://stackql.io/blog/providers/updated-cloudflare-provider-available", "title": "Cloudflare Provider - May 2026", "summary": "Initial release of the StackQL Cloudflare provider with 108 services, 1259 resources, and 2840 operations spanning Zero Trust, Workers, R2, DNS, Zones, Radar, AI, Stream, Magic Transit, and more.", "date_modified": "2026-05-27T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "cloudflare", "provider", "zero trust", "workers", "r2", "dns", "radar", "ai", "stream", "magic transit" ] }, { "id": "https://stackql.io/blog/providers/confluent-provider-may-2026-update", "content_html": "

We've released an update to the StackQL Confluent provider adding eight new services and 40 additional resources across existing services.

\n

New Services​

\n

The eight new services added in this update are:

\n
ServiceDescription
cclCustom Code Logging - manage log topics that capture stdout/stderr and worker process logs from custom connectors running in Confluent Cloud
ccpmCustom Connect Plugin Management - upload, version, and manage custom connector plugins at the environment level, including plugin version resources for JAR/ZIP artifacts
endpointsManage PrivateLink access points and private network endpoints used to reach Confluent Cloud clusters and serverless products over private networking
pipelinesManage Stream Designer pipelines - the visual SQL/ksqlDB pipeline builder for connecting sources, transforms, and sinks across Kafka topics
share_groupManage Kafka share groups (KIP-932 / Queues for Kafka), which provide queue-like consumption semantics with per-message acknowledgement and consumer parallelism beyond partition count
streams_groupManage Kafka Streams groups - the broker-side coordination resource for Kafka Streams applications introduced alongside the next-generation consumer rebalance protocol
tableflowMaterialize Kafka topics as Apache Iceberg or Delta Lake tables, including catalog integrations, storage configuration, and table maintenance settings
usmUnified Stream Manager - register and govern self-managed Confluent Platform clusters from Confluent Cloud, including agent deployment and hybrid cluster monitoring
\n

Updates​

\n

This release also adds 40 additional resources across existing services, expanding coverage for:

\n\n

Get Started​

\n

Pull the latest Confluent provider:

\n
stackql registry pull confluent
\n

Visit us on GitHub and let us know how you're using it.

", "url": "https://stackql.io/blog/providers/confluent-provider-may-2026-update", "title": "Confluent Provider Update - May 2026", "summary": "Update to the StackQL Confluent provider adding eight new services including ccl, ccpm, endpoints, pipelines, share_group, streams_group, tableflow, and usm, along with 40 additional resources across existing services.", "date_modified": "2026-05-08T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "confluent", "provider", "kafka", "tableflow", "stream-designer" ] }, { "id": "https://stackql.io/blog/providers/github-provider-april-2026-update", "content_html": "

We've released an update to the StackQL GitHub provider adding new services and expanding coverage across several existing ones.

\n

New Services​

\n

Some of the newly added services of note include:

\n

agent_tasks​

\n

The agent_tasks service exposes GitHub's AI agent task API, allowing you to query and manage agent task runs within a repository. Resources include:

\n
ResourceDescription
agent_tasksList, get, and manage agent task runs scoped to a repository
agent_task_stepsRetrieve individual step-level detail for an agent task run
agent_task_labelsManage labels assigned to agent tasks
\n

This covers the audit and observability side of AI agent operations in GitHub - useful for tracking what agent tasks have run, their status, and step-level output.

\n

campaigns​

\n

The campaigns service covers GitHub's security campaign management, part of GitHub Advanced Security. Resources include:

\n
ResourceDescription
campaignsCreate, list, get, update, and close security campaigns scoped to an organization
campaign_repositoriesList repositories participating in a campaign
\n

Security campaigns let you coordinate remediation of code scanning or secret scanning alerts across an org. This service lets you query campaign state and participation programmatically.

\n

classroom​

\n

The classroom service brings GitHub Classroom into StackQL. Resources include:

\n
ResourceDescription
classroomsList and get classrooms accessible to the authenticated user
assignmentsList and get assignments within a classroom
accepted_assignmentsQuery student-accepted assignment repositories
assignment_gradesRetrieve grade data for accepted assignments
\n

This is useful for institutions managing GitHub Classroom at scale - querying assignment completion or generating reports across multiple classrooms.

\n

hosted_compute​

\n

The hosted_compute service covers GitHub's hosted compute networking resources, relevant to organizations using GitHub-hosted runners with custom network configurations. Resources include:

\n
ResourceDescription
hosted_compute_networksManage hosted compute network configurations at the org level
hosted_compute_network_settingsQuery and update settings for a hosted compute network
\n

This is relevant if you're using GitHub's hosted compute with Azure private networking or similar integrations.

\n

private_registries​

\n

The private_registries service exposes org-level private registry configurations - credentials and settings stored in GitHub for use by Actions workflows. Resources include:

\n
ResourceDescription
org_private_registriesList, get, create, update, and delete private registry configurations for an organization
\n

This allows you to audit which private registries (npm, Docker Hub, Maven, etc.) are configured at the org level without going through the GitHub UI.

\n

enterprise_teams​

\n

The enterprise_teams service provides enterprise-scoped team management, distinct from org-level teams. Resources include:

\n
ResourceDescription
enterprise_teamsList and get teams at the enterprise level
enterprise_team_membersQuery membership for enterprise teams
\n

This is useful for enterprises managing teams that span multiple organizations.

\n

Updates​

\n

Notable updates to existing services include:

\n

actions​

\n

New resources added to the actions service:

\n\n

orgs​

\n\n

repos​

\n\n

Get Started​

\n

Pull the latest GitHub provider:

\n
stackql registry pull github
\n

Visit us on GitHub and let us know how you're using it.

", "url": "https://stackql.io/blog/providers/github-provider-april-2026-update", "title": "GitHub Provider Update - April 2026", "summary": "Update to the StackQL GitHub provider adding six new services including agent_tasks, campaigns, classroom, hosted_compute, private_registries, and enterprise_teams, along with resource additions across existing services.", "date_modified": "2026-04-18T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "github", "provider", "github actions", "github classroom", "hosted compute" ] }, { "id": "https://stackql.io/blog/providers/new-databricks-providers-available", "content_html": "

Updated StackQL providers for Databricks are now available: databricks_account and databricks_workspace, giving you SQL access to the full Databricks control plane across account-level and workspace-level operations.

\n

Provider Structure​

\n

The following updated providers are available:

\n
ProviderScopeServices
databricks_accountAccount8
databricks_workspaceWorkspace26
\n

Coverage​

\n

There are over 30 services, 300+ resources, and 983 operations spanning IAM, compute, catalog, billing, jobs, ML, serving, sharing, vector search, and more.

\n

Example Queries​

\n

List workspaces in an account​

\n
SELECT
  workspace_id,
  workspace_name,
  workspace_status,
  aws_region,
  compute_mode,
  deployment_name,
  datetime(creation_time/1000, 'unixepoch') as creation_date_time
FROM databricks_account.provisioning.workspaces
WHERE account_id = 'ebfcc5a9-9d49-4c93-b651-b3ee6cf1c9ce';
\n

Query account users and roles​

\n
SELECT
  id as user_id,
  displayName as display_name,
  userName as user_name,
  active,
  IIF(JSON_EXTRACT(roles,'$[0].value') = 'account_admin', 'true', 'false') as is_account_admin
FROM databricks_account.iam.account_users
WHERE account_id = 'ebfcc5a9-9d49-4c93-b651-b3ee6cf1c9ce';
\n

List catalogs in a workspace​

\n
SELECT
  full_name,
  catalog_type,
  comment,
  datetime(created_at/1000, 'unixepoch') as created_at,
  created_by,
  datetime(updated_at/1000, 'unixepoch') as updated_at,
  updated_by,
  enable_predictive_optimization
FROM databricks_workspace.catalog.catalogs
WHERE deployment_name = 'dbc-36ff48e3-4a69';
\n

Download billable usage to CSV​

\n

This one is worth calling out. You can pull billable usage data for a given period and write it straight to a CSV file:

\n
./stackql exec \\
  -o text \\
  --hideheaders \\
  -f billable_usage.csv \\
  \"SELECT contents
  FROM databricks_account.billing.billable_usage
  WHERE start_month = '2025-12'
  AND end_month = '2026-01'
  AND account_id = 'your-account-id'\"
\n

Authentication​

\n

Both providers authenticate using OAuth2 with a Databricks service principal. Set the following environment variables:

\n
export DATABRICKS_ACCOUNT_ID=\"your-account-id\"
export DATABRICKS_CLIENT_ID=\"your-client-id\"
export DATABRICKS_CLIENT_SECRET=\"your-client-secret\"
\n

These are the same variables used by Terraform, the Databricks SDKs, and the Databricks CLI.

\n

Get Started​

\n

Pull the providers:

\n
registry pull databricks_account;
registry pull databricks_workspace;
\n

Start querying via the shell or exec:

\n
SELECT * FROM databricks_account.iam.account_groups WHERE account_id = 'your-account-id';
\n

Full documentation is available at databricks-account-provider.stackql.io and databricks-workspace-provider.stackql.io. Let us know what you think on GitHub.

", "url": "https://stackql.io/blog/providers/new-databricks-providers-available", "title": "New Databricks Providers for StackQL Released", "summary": "Updated providers for Databricks released covering account and workspace operations, with over 30 services, 300 resources, and nearly 1,000 operations queryable using SQL.", "date_modified": "2026-02-12T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "databricks", "provider", "infrastructure-as-code" ] }, { "id": "https://stackql.io/blog/providers/new-awscc-provider-available", "content_html": "

We've released a new dedicated StackQL AWS Cloud Control provider, providing full CRUDL operations across AWS services via the Cloud Control API including purpose-built resource definitions leveraging Cloud Control's consistent schema.

\n

Resource Naming Convention​

\n

Resources follow a clear pattern to differentiate operations:

\n
Resource PatternOperationsUse Case
{resource} (e.g., s3.buckets)SELECT, INSERT, UPDATE, DELETEFull CRUD with complete resource properties
{resource}_list_only (e.g., s3.buckets_list_only)SELECTFast enumeration of resource identifiers
\n
\n

This separation means listing thousands of resources won't trigger rate limits from individual GET calls:

\n
-- Fast enumeration (list operation only)
SELECT bucket_name 
FROM awscc.s3.buckets_list_only 
WHERE region = 'us-east-1';

-- Full resource details (get operation)
SELECT * 
FROM awscc.s3.buckets 
WHERE region = 'us-east-1' 
AND data__Identifier = 'my-bucket';
\n

Provider Coverage​

\n

The awscc provider includes:

\n\n

Example Operations​

\n

Create an S3 Bucket​

\n
INSERT INTO awscc.s3.buckets (
  BucketName,
  region
)
SELECT 
  'my-new-bucket',
  'us-east-1';
\n

Query EC2 Instances​

\n
SELECT 
  instance_id,
  instance_type,
  tags
FROM awscc.ec2.instances
WHERE region = 'ap-southeast-2'
AND data__Identifier = 'i-1234567890abcdef0';
\n

Delete a Resource​

\n
DELETE FROM awscc.lambda.functions
WHERE data__Identifier = 'my-function'
AND region = 'us-east-1';
\n

Enhanced Documentation​

\n

The provider documentation at awscc.stackql.io now features:

\n\n

Get Started​

\n

Pull the new provider:

\n
stackql registry pull awscc
\n

Query your AWS resources:

\n
stackql shell
>> SELECT region, bucket_name FROM awscc.s3.buckets_list_only WHERE region = 'us-east-1';
\n

Let us know your thoughts! Visit us and give us a star on GitHub.

", "url": "https://stackql.io/blog/providers/new-awscc-provider-available", "title": "New Dedicated AWS Cloud Control Provider Released", "summary": "Introducing the standalone StackQL AWS Cloud Control provider with full CRUDL support, optimized resource naming, and comprehensive coverage of AWS Cloud Control API resources.", "date_modified": "2026-01-19T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "aws", "awscc", "cloud control", "provider", "infrastructure-as-code" ] }, { "id": "https://stackql.io/blog/providers/google-provider-december-2025-update", "content_html": "

We've released a major update to the StackQL Google provider with a new service, enhanced AI/ML capabilities, and improvements across 177 service files.

\n

New Service: Speech-to-Text v2​

\n

The speechv2 service brings Cloud Speech-to-Text API v2 to StackQL with 6 resources:

\n
ResourceDescription
recognizersManage speech recognition configurations with create, list, get, patch, delete, undelete, recognize, and batch_recognize methods
custom_classesCreate custom vocabulary classes for improved recognition accuracy
phrase_setsDefine phrase hints to boost recognition of specific terms
configManage location-level Speech-to-Text configuration
locationsQuery available service locations
operationsTrack long-running operations
\n

Key features include support for multiple audio encodings (WAV, FLAC, MP3, OGG, WebM, MP4/AAC), translation capabilities, denoiser config, and KMS encryption support.

\n

Vertex AI / AI Platform​

\n

The largest update in this release with 87,000+ line changes introduces powerful new RAG and evaluation capabilities:

\n\n

Discovery Engine​

\n

Major enhancements (50,000+ line changes) for search and conversational AI:

\n\n

Contact Center AI Insights​

\n

Quality assurance and analytics improvements (20,000+ line changes):

\n\n

BigQuery​

\n

Enhanced governance and access control (18,000+ line changes):

\n\n

Healthcare API​

\n

Expanded metrics and data mapping (15,000+ line changes):

\n\n

Cloud Spanner​

\n

Backup and security enhancements (14,000+ line changes):

\n\n

Cloud SQL Admin​

\n

New integration and management features (12,000+ line changes):

\n\n

GKE On-Prem​

\n

Enhanced IAM across VMware and Bare Metal clusters (9,000+ line changes):

\n\n

Developer Connect​

\n

Git integration improvements (3,500+ line changes):

\n\n

Text-to-Speech​

\n

Enhanced voices and text resources with new capabilities.

\n

Get Started​

\n

Update to the latest Google provider:

\n
stackql registry pull google
\n

Let us know your thoughts! Visit us and give us a star on GitHub.

", "url": "https://stackql.io/blog/providers/google-provider-december-2025-update", "title": "Google Provider Update - December 2025", "summary": "Major update to the StackQL Google provider featuring a new Speech-to-Text v2 service, enhanced Vertex AI with RAG capabilities, and significant improvements across BigQuery, Spanner, and 15+ other Google Cloud services.", "date_modified": "2025-12-12T00:00:00.000Z", "author": { "name": "Jeffrey Aven", "url": "https://www.linkedin.com/in/jeffreyaven/" }, "tags": [ "stackql", "google cloud", "gcp", "provider", "vertex ai", "speech-to-text", "bigquery", "spanner" ] } ] }