Skip to main content

New Google Gemini Provider Available

· 3 min read
Technologist and Cloud Consultant

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

  • gemini - the Generative Language API surface (generativelanguage.googleapis.com): inference (content generation, embeddings, token counting, batches) plus the API's own management surface - models, tuned models and permissions, files, cached contents, corpora, file search stores and long-running operations (10 services, 32 resources, 75 operations)

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.

Inference as a result set

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:

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."}]}]';

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:

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"}]}';

Which model can do what

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

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

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.

The management surface as SQL

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

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

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

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

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

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.

One credential, one boundary

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.

Authentication

Set a single environment variable:

export GEMINI_API_KEY=...

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.

Get started

Pull the provider from the public registry:

registry pull gemini

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

Databricks Providers Update - July 2026

· 3 min read
Technologist and Cloud Consultant

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

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

New Services

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

Expanded Coverage in Existing Services

  • postgres (Lakebase) - the largest expansion in this release, now 24 resources covering projects, branches, databases, roles, endpoints, tables, synced tables, catalogs, snapshots, compute instances, change data feed configs and statuses, forward ETL, replication group previews and recovery branch previews
  • iamv2 (account and workspace) - the restructured identity APIs: full lifecycle for users, groups, service_principals, direct_group_members, workspace_access_details, workspace_assignment_details, external_users and transitive_parent_groups, plus account access identity rules and attribute control entries
  • catalog - Unity Catalog AI Gateway services (ai_gateway_model_services, ai_gateway_mcp_services, ai_gateway_agent_services, ai_gateway_model_provider_services), privilege assignments (direct and effective), UC secrets and temporary volume credentials
  • dashboards - AI/BI Genie evaluation runs and results
  • apps - app spaces, app space operations and app thumbnails
  • compute - default base environments for serverless environments and library management
  • vectorsearch - vector search index management and endpoint permissions
  • ml - feature engineering streams
  • billing (account) - usage policies

SQL Statement Execution Improvements

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:

/* 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>';

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.

Built-in Views

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:

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

Get Started

Pull the latest providers from the public registry:

stackql registry pull databricks_account
stackql registry pull databricks_workspace

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:

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

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.

OpenAI Providers Update - July 2026

· 4 min read
Technologist and Cloud Consultant

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

  • openai - the platform API surface available to standard API keys: models, files, fine-tuning, batches, vector stores, assistants, evals, conversations, uploads, containers, and skills (11 services, 26 resources, 97 operations)
  • openai_admin [new] - the organization and administration API surface: usage and cost reporting, projects, organization users and invites, groups and roles, admin API keys, audit logs, and certificates (10 services, 29 resources, 81 operations)

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

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.

Async jobs as SQL

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:

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;

Vector stores are a full CRUD surface with file membership:

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

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.

The admin provider - your OpenAI org as data

The openai_admin provider presents the organization management surface as SQL.

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:

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;

Daily spend in USD by project:

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;

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.

Governance and auditing

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

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

Admin key hygiene and audit logs work the same way:

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

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.

Authentication

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

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

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.

Get started

Pull the providers from the public registry:

registry pull openai
registry pull openai_admin

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

Azure Provider Update - July 2026

· 4 min read
Technologist and Cloud Consultant

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

  • azure - core Microsoft Azure services: 268 services, 3,473 resources and 13,559 operations (up from 202 services, a 33% increase in service coverage)
  • azure_extras - domain-specific and specialized Microsoft services (44 services)
  • azure_isv - Azure Native ISV and partner services: Databricks, Datadog, Confluent, Elastic, MongoDB Atlas, Oracle Database@Azure and more (27 services)
  • azure_stack - the Azure Stack / Azure Local family (4 services)

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.

Control plane and data plane in one provider

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.

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

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

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.

The AI surface

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

  • Azure AI Foundry: ai_projects, ai_agents, ai_inference, ai_evaluation
  • Language: ai_language (conversational language understanding, question answering and their authoring surfaces in a single service), ai_text_analytics, ai_translation_text, ai_translation_document
  • Vision: ai_vision_image_analysis, ai_vision_face
  • Documents: ai_document_intelligence, ai_form_recognizer
  • Speech: ai_transcription, ai_voice_live
  • Safety and content: ai_content_safety, ai_content_understanding
  • Plus ai_anomaly_detector, ai_personalizer, ai_discovery and the cognitive_services management plane

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

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

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.

More new and expanded coverage

  • Communication - the full Azure Communication Services surface: email, SMS, chat, calling automation, phone numbers, rooms, job router, advanced messaging and identity (9 services)
  • Databases - Azure NetApp Files, Azure Cache for Redis, Azure Managed Redis, Azure DocumentDB (MongoDB compatibility), Azure HorizonDB, MySQL and PostgreSQL flexible servers, Azure Data Explorer (Kusto)
  • Compute and containers - Compute Fleet, Compute Schedule, AKS (container_service), Kubernetes Fleet Manager, deployment safeguards, Container Registry tasks and data plane, Azure Red Hat OpenShift, Azure VMware Solution
  • Observability - Azure Monitor log query, metrics query and logs ingestion data planes, Azure Monitor workspaces (managed Prometheus), health models
  • Governance - Microsoft Purview catalog, data map, scanning, sharing and workflow APIs; a consolidated resource service spanning deployments, policy, locks, template specs and subscriptions
  • Maps - geocoding, routing, rendering, geolocation, timezone and weather (6 services)
  • Hybrid - Azure Arc-enabled servers, Kubernetes, VMware vSphere and System Center VMM, Arc gateway, Azure Local

Authentication

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

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

Get started

Pull the providers from the public registry:

registry pull azure
registry pull azure_extras
registry pull azure_isv
registry pull azure_stack

Then explore - it's just SQL:

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

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

Anthropic Providers Update - July 2026

· 3 min read
Technologist and Cloud Consultant

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

  • anthropic - the Claude API surface: messages, models, batches, files, agents, deployments, environments, sessions, skills, memory stores, user profiles, and vaults (11 services, 26 resources, 103 operations)
  • anthropic_admin [new] - the Admin API surface: organization, users, invites, workspaces, API keys, usage and cost reports, rate limits, and Claude Code analytics (6 services, 11 resources)

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

Inference as a query

Inference using Claude is accessible via SELECT for instance:

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"}';

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

Model capabilities view

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

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

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.

The admin provider - your Anthropic org as data

The anthropic_admin provider presents the organization management surface as SQL.

Enumerate workspaces and who's in them:

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

Audit users and API keys across the org:

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;

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:

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

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

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

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.

Authentication

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

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

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

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

Get started

Pull the providers from the public registry:

registry pull anthropic
registry pull anthropic_admin

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