SQL Server

Sifflet monitors the health and quality of the data in your Microsoft SQL Server databases, from table updates down to individual field values and business metrics. Sifflet catalogs the tables and views of the schemas you select, so you can monitor them and see how an incident on your production data affects the downstream assets of your other integrations.

To learn what Sifflet imports from SQL Server, see SQL Server Collected Data.

Permissions Required

Sifflet uses a dedicated SQL Server login, authenticated with a password (SQL Server authentication), mapped to a user in the monitored database. Sifflet only needs read access: it reads metadata about your schemas and tables, and runs read-only SELECT queries to compute monitors.

PermissionUsed forRequired
Login with a password, mapped to a database userAuthenticate Sifflet and access the databaseYes
VIEW DEFINITION on each monitored schemaNot used today; avoids a new grant for future features (reading view and object definitions). SELECT already lets Sifflet read the metadata of tables, views, and columnsOptional (recommended)
SELECT on each monitored schemaRun monitors and data preview on tables and viewsYes

Schema-level grants also apply to the tables and views created later in the schema.

Sifflet's monitor queries run on your database and consume its resources. Each query starts with a SQL comment containing "app": "Sifflet" and the ID of the monitor, so you can identify Sifflet's queries.

Requirements

Required Roles for Setup

  • In SQL Server: a login that can create logins (ALTER ANY LOGIN, for example a member of the securityadmin or sysadmin server role) and create users and grant permissions in the monitored database (for example a member of the db_owner database role).
  • In Sifflet: the Admin system role to create the credential, and the Admin or System Editor system role to create the source. See Access Control.

Supported Versions and Editions

  • Sifflet connects with SQL Server authentication (login and password): your server must use the SQL Server and Windows Authentication mode (mixed mode). Windows authentication and Microsoft Entra ID authentication are not supported.
  • Managed SQL Server services that expose a standard SQL Server endpoint with SQL Server authentication use the same setup. This includes Google Cloud SQL for SQL Server: see Cloud SQL for SQL Server for its network setup.

Network Access

  • Default: Sifflet connects to your database over the internet, so its host and port must be reachable from the public internet.
  • IP allowlisting: you can restrict inbound traffic to your database (firewall rules, cloud security groups) to the IP addresses of your Sifflet instance, listed in Settings > Integration Preferences.

Cloud SQL for SQL Server

Sifflet connects directly to the IP address of your Cloud SQL instance: it doesn't use the Cloud SQL Auth Proxy or the Cloud SQL connectors, so the instance must not require connectors. See Connect to Cloud SQL for SQL Server.

  • Public IP: turn on public IP for the instance, and add the IP addresses of your Sifflet instance (Settings > Integration Preferences) to its authorized networks. Use the public IP address of the instance as the Host of the source.
  • If the instance only allows encrypted connections, keep Enforce encrypted connection (SSL) checked on the source.

Connect Sifflet to SQL Server

Step 1: Create a Login and a Database User in SQL Server

  1. Connect to your SQL Server instance as a login that has the rights listed in Required Roles for Setup.

  2. Create the Sifflet login. Replace <PASSWORD> with a strong password that meets your server's password policy. You can choose another login name than sifflet_login: use it consistently in all the following scripts.

    CREATE LOGIN sifflet_login WITH PASSWORD = '<PASSWORD>';
  3. Create the database user mapped to the login, and grant it read access to each schema that Sifflet monitors. Replace <DATABASE> with the name of your database and <SCHEMA> with the schema name.

    USE [<DATABASE>];
    CREATE USER sifflet_user FOR LOGIN sifflet_login;
    
    -- Repeat for each schema that Sifflet monitors
    GRANT VIEW DEFINITION ON SCHEMA :: [<SCHEMA>] TO sifflet_user; -- optional, see Permissions Required
    GRANT SELECT ON SCHEMA :: [<SCHEMA>] TO sifflet_user;

Cloud SQL: Create the Login with SQL

Run the scripts above as the sqlserver user, which Cloud SQL creates with the instance. Create the Sifflet login with SQL rather than in the Google Cloud console, so that you control exactly which permissions it gets.

Keep the login name (not the database user name) and the password: you need them in step 2.

Step 2: Add the SQL Server Source in Sifflet

  1. Create the credential: in Integrations > Credentials, click New credentials, enter a Credential name, and paste the following JSON in the Credential field, with the login name and password from step 1:

    {
      "user": "sifflet_login",
      "password": "<PASSWORD>"
    }
  2. Create the source: in Integrations > Sources, click New source, select MSSQL, and fill in the form:

    FieldDescriptionExample
    Source nameThe name of the source in SiffletSQL Server production
    HostThe host name or IP address of your SQL Server instance, without protocol or portsqlserver.example.com
    PortThe TCP port of your SQL Server instance (default 1433)1433
    DatabaseThe name of the database that Sifflet monitorsapp_db
    Enforce encrypted connection (SSL)Encrypts the connection with TLS (turned on by default). Sifflet accepts the server certificate without validating its certificate authority, so self-signed certificates work.Checked
    CredentialsThe credential created abovesql-server-production

    Use the same host as the other tools that connect to this database (BI tools, dbt, pipelines): Sifflet matches the host, port, and database to link their assets in lineage.

  3. Select the scope: click Load assets and select the schemas that Sifflet catalogs and monitors. Turn on Automatically include new schemas so that Sifflet also catalogs schemas created later. Create one source per database. For more details on scope selection, refresh frequency, and scheduling, see Integrations Management.

  4. Test and save: click Test to check that Sifflet can connect to the database, then click Save & Run. Sifflet starts the first metadata refresh: you can follow its status and logs in the source details (see Inspecting Source Details and Resolving Failures). Your tables and views appear in the Data Catalog once this first run completes.


Did this page help you?