ServiceNow SQL API: Query Your Instance Directly with ODBC and JDBC

Every ServiceNow admin knows the pain. Your CISO wants a Power BI dashboard showing open P1 incidents by assignment group — in real time. The options were ugly: REST API polling on a cron job, a custom ETL pipeline syncing to an external database, or just exporting CSVs and hoping nobody notices they're six hours stale.

Australia Patch 1 changes that. The SQL API gives BI tools a direct, read-only SQL connection into your ServiceNow instance — no replication, no pipeline, no export. Just a standard ODBC or JDBC connection and a SELECT query.

What the SQL API actually is

The SQL API is a read-only SQL interface that sits in front of your ServiceNow database. It exposes ServiceNow tables through ODBC and JDBC drivers — the same protocols that Power BI, Tableau, DBeaver, and basically every data tool already knows how to speak.

It is not a reporting engine, not a data warehouse, and not a replacement for GlideRecord. It is a query interface. You write SELECT statements against real ServiceNow table names (incident, task, cmdb_ci, etc.) and get rows back — with full ACL enforcement applied to every result.

What it unlocks

The practical impact is significant across four areas:

• Real-time analytics — no sync lag. Your Power BI report reflects what's in ServiceNow right now, not what was exported at 2am.
• No-replication BI models — eliminate the shadow database your team maintains in Snowflake or Redshift just to run reports on ServiceNow data.
• Native data exploration — analysts can browse tables, join incident to task to cmdb_ci, and explore the data model without needing a developer to write a REST integration.
• SQL-native MCP tools — agentic AI workflows that need structured ServiceNow data can now query directly using SQL rather than stitching together multiple GlideRecord calls through a custom tool.

The three-layer architecture

Understanding the stack matters because the SQL API is not just a query engine bolted onto the side of the platform — it is a purpose-built service with a full security and routing architecture. Three layers handle every request.

Layer 1: Security

Every query passes through six controls in sequence before any data is touched. Think of this as the bouncer line for your database:

1. IP Access Policy — your instance admin defines which IP ranges or CIDRs can establish SQL API connections at all
2. Rate Limit — per-user query rate limits prevent runaway queries from starving operational workloads
3. Auth + Role check — standard ServiceNow authentication; the user must have the sql_api_user role (or equivalent)
4. egress_sql ACL — a dedicated ACL controls which tables and fields are accessible via SQL. ACLs you've already defined on tables are inherited here
5. Strict Security Mode — enforces that no query can bypass row-level security, even with direct SQL access
6. WDF Token Metering — queries count against your instance's metered workload budget, preventing BI tools from impacting platform performance

The practical implication: a user connecting via Power BI sees exactly the same data they would see browsing the same records in the ServiceNow UI. If an ACL restricts a field from a user, that field is absent from SQL results for that user. There is no privilege escalation through the SQL layer.

Layer 2: REST layer (SELECT-only enforcement)

Behind the security layer are two dedicated services — one for ODBC, one for JDBC. Both are SELECT-only and both are internal services that only the drivers can reach. They handle query parsing, validation, and translation to ServiceNow's internal query engine.

Layer 3: Database tier

SQL API queries are routed to read replicas, not the primary database. This is the key architectural detail that makes the feature operationally safe: BI workload is isolated from your instance's transactional workload by default. If no replica is available, queries fall back to the primary (read-only mode), but ServiceNow will route to replicas whenever they exist.

Connecting in practice

Here's what a Python connection looks like using pyodbc, once you've installed the ServiceNow ODBC driver and configured your DSN:

import pyodbc

# DSN configured in your ODBC data source manager
# pointing to your ServiceNow instance
conn = pyodbc.connect("DSN=ServiceNow_Production")
cursor = conn.cursor()

# Standard SQL against real ServiceNow table names
cursor.execute("""
    SELECT
        number,
        short_description,
        assignment_group,
        state,
        priority,
        sys_created_on
    FROM incident
    WHERE state IN ('1', '2')   -- 1=New, 2=In Progress
      AND priority = '1'         -- Critical
    ORDER BY sys_created_on DESC
    LIMIT 100
""")

for row in cursor.fetchall():
    print(row.number, row.priority, row.assignment_group)

conn.close()

The same connection string works in Power BI, Tableau, DBeaver, and any other ODBC-compatible tool. For JDBC, the pattern is identical but uses the JDBC driver jar and a JDBC URL format provided in your instance documentation.

Joining tables works exactly as you'd expect

ServiceNow's relational model translates cleanly to SQL joins. Reference fields (like incident.assignment_group, which stores a sys_id pointing to sys_user_group) are queryable by their underlying column name:

-- Get open incidents with assignment group names
SELECT
    i.number,
    i.short_description,
    g.name AS assignment_group_name,
    i.priority,
    i.sys_created_on
FROM incident i
JOIN sys_user_group g ON i.assignment_group = g.sys_id
WHERE i.active = true
ORDER BY i.sys_created_on DESC

What to know before you activate it

A few things that are worth being explicit about before you hand the JDBC URL to your analytics team:

• Australia Patch 1 minimum — the SQL API plugin requires this patch level or later. Confirm your instance version before planning a rollout.
• RaptorDB required — not negotiable. If your instance is on the legacy database infrastructure, this feature is not available until you migrate.
• ODBC/JDBC driver installation — end users and BI servers need the ServiceNow-provided driver installed locally. This is a standard deployment step but requires distribution to BI server hosts.
• Query performance — read replicas handle BI load, but expensive queries (full table scans on large tables like task) can still be slow. Encourage analysts to always filter on indexed columns like number, sys_created_on, and state.
• sql_api_user role — users need this role assigned. It does not grant any additional data access; it just enables the SQL connection. Existing ACLs still control what data is visible.
• Schema discovery — tools like DBeaver can browse your ServiceNow schema through the driver. This is useful for analysts but means all table and column names are discoverable. Factor this into your security posture.

The bigger picture

The SQL API is the missing piece in a pattern that a lot of organizations have been hacking around for years. The choice was always: build and maintain a replication pipeline (expensive), poll the REST API on a schedule (laggy and brittle), or live with exported CSVs (everyone's least favourite option).

A direct, ACL-enforced, read-replica-backed SQL interface that works with standard database drivers is a genuinely better pattern — not just for BI, but for the data science and agentic workflows that increasingly need structured ServiceNow data as input.

The fact that it's SELECT-only is a feature, not a limitation. It makes the access model simple to reason about and easy to audit. No SQL injection risk, no accidental bulk updates, no change control headaches.

If your instance is on RaptorDB and running Australia Patch 1 or later, this is worth activating and testing with one BI use case before pushing it out broadly. Start with a dashboard your team already maintains through a REST integration — the before/after on pipeline complexity alone makes the case.