Skip to main content



Full Refresh SyncYes
Incremental - Append SyncYes
Incremental - Append + DedupedYes

Output Schema

Each stream will be output into its own table in SQL Server. Each table will contain 3 columns:

  • _airbyte_ab_id: a uuid assigned by Airbyte to each event that is processed. The column type in SQL Server is VARCHAR(64).
  • _airbyte_emitted_at: a timestamp representing when the event was pulled from the data source. The column type in SQL Server is DATETIMEOFFSET(7).
  • _airbyte_data: a JSON blob representing with the event data. The column type in SQL Server is NVARCHAR(MAX).

Microsoft SQL Server specifics or why NVARCHAR type is used here:

  • NVARCHAR is Unicode - 2 bytes per character, therefore max. of 1 billion characters; will handle East Asian, Arabic, Hebrew, Cyrillic etc. characters just fine.
  • VARCHAR is non-Unicode - 1 byte per character, max. capacity is 2 billion characters, but limited to the character set you're SQL Server is using, basically - no support for those languages mentioned before

Getting Started (Airbyte Cloud)

Airbyte Cloud only supports connecting to your MSSQL instance with TLS encryption. Other than that, you can proceed with the open-source instructions below.

Full Refresh SyncYes
Incremental - Append SyncYes
Incremental - Append + DedupedYes

Getting Started (Airbyte Open Source)


To use the SQL Server destination, you'll need:

MS SQL Server: Azure SQL Database, Azure Synapse Analytics, Azure SQL Managed Instance, SQL Server 2019, SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012, or PDW 2008R2 AU34.

Normalization Requirements

To sync with normalization you'll need to use MS SQL Server of the following versions: SQL Server 2019, SQL Server 2017, SQL Server 2016, SQL Server 2014. The work of normalization on SQL Server 2012 and bellow are not guaranteed.

Setup guide

  • MS SQL Server: Azure SQL Database, Azure Synapse Analytics, Azure SQL Managed Instance, SQL Server 2019, SQL Server 2017, SQL Server 2016, SQL Server 2014, SQL Server 2012, or PDW 2008R2 AU34.

Network Access

Make sure your SQL Server database can be accessed by Airbyte. If your database is within a VPC, you may need to allow access from the IP you're using to expose Airbyte.


You need a user configured in SQL Server that can create tables and write rows. We highly recommend creating an Airbyte-specific user for this purpose. In order to allow for normalization, please grant ALTER permissions for the user configured.

Target Database

You will need to choose an existing database or create a new database that will be used to store synced data from Airbyte.

SSL configuration (optional)

Airbyte supports a SSL-encrypted connection to the database. If you want to use SSL to securely access your database, ensure that the server is configured to use an SSL certificate.

Setup the MSSQL destination in Airbyte

You should now have all the requirements needed to configure SQL Server as a destination in the UI. You'll need the following information to configure the MSSQL destination:

  • Host
  • Port
  • Username
  • Password
  • Schema
  • Database
    • This database needs to exist within the schema provided.
  • SSL Method:
    • The SSL configuration supports three modes: Unencrypted, Encrypted (trust server certificate), and Encrypted (verify certificate).
      • Unencrypted: Do not use SSL encryption on the database connection
      • Encrypted (trust server certificate): Use SSL encryption without verifying the server's certificate. This is useful for self-signed certificates in testing scenarios, but should not be used in production.
      • Encrypted (verify certificate): Use the server's SSL certificate, after standard certificate verification.
    • Host Name In Certificate (optional): When using certificate verification, this property can be set to specify an expected name for added security. If this value is present, and the server's certificate's host name does not match it, certificate verification will fail.

Connection via SSH Tunnel

Airbyte has the ability to connect to the MS SQL Server instance via an SSH Tunnel. The reason you might want to do this because it is not possible (or against security policy) to connect to the database directly (e.g. it does not have a public IP address).

When using an SSH tunnel, you are configuring Airbyte to connect to an intermediate server (a.k.a. a bastion sever) that have direct access to the database. Airbyte connects to the bastion and then asks the bastion to connect directly to the server.

Using this feature requires additional configuration, when creating the source. We will talk through what each piece of configuration means.

  1. Configure all fields for the source as you normally would, except SSH Tunnel Method.

  2. SSH Tunnel Method defaults to No Tunnel (meaning a direct connection). If you want to use an SSH Tunnel choose SSH Key Authentication or Password Authentication.

  3. Choose Key Authentication if you will be using an RSA private key as your secret for establishing the SSH Tunnel (see below for more information on generating this key).

  4. Choose Password Authentication if you will be using a password as your secret for establishing the SSH Tunnel.

  5. SSH Tunnel Jump Server Host refers to the intermediate (bastion) server that Airbyte will connect to. This should be a hostname or an IP Address.

  6. SSH Connection Port is the port on the bastion server with which to make the SSH connection. The default port for SSH connections is 22,

    so unless you have explicitly changed something, go with the default.

  7. SSH Login Username is the username that Airbyte should use when connection to the bastion server. This is NOT the MS SQL Server username.

  8. If you are using Password Authentication, then SSH Login Username should be set to the password of the User from the previous step.

    If you are using SSH Key Authentication leave this blank. Again, this is not the MS SQL Server password, but the password for the OS-user that

    Airbyte is using to perform commands on the bastion.

  9. If you are using SSH Key Authentication, then SSH Private Key should be set to the RSA Private Key that you are using to create the SSH connection.

    This should be the full contents of the key file starting with -----BEGIN RSA PRIVATE KEY----- and ending with -----END RSA PRIVATE KEY-----.


VersionDatePull RequestSubject
0.2.02023-06-27#27781License Update: Elv2
0.1.252023-06-21#27555Reduce image size
0.1.242023-06-05#27034Internal code change for future development (install normalization packages inside connector)
0.1.232023-04-04#24604Support for destination checkpointing
0.1.222022-10-21#18275Upgrade commons-text for CVE 2022-42889
0.1.202022-07-14#14618Removed additionalProperties: false from JDBC destination connectors
0.1.192022-05-25#13054Destination MSSQL: added custom JDBC parameters support.
0.1.182022-05-17#12820Improved 'check' operation performance
0.1.172022-04-05#11729Bump mina-sshd from 2.7.0 to 2.8.0
0.1.152022-02-25#10421Refactor JDBC parameters handling
0.1.142022-02-14#10256Add -XX:+ExitOnOutOfMemoryError JVM option
0.1.132021-12-28#9158Update connector fields title/description
0.1.122021-12-01#8371Fixed incorrect handling "\n" in ssh key
0.1.112021-11-08#7719Improve handling of wide rows by buffering records based on their byte size rather than their count
0.1.102021-10-11#6877Add normalization capability, add append+deduplication sync mode
0.1.92021-09-29#5970Add support & test cases for MSSQL Destination via SSH tunnels
0.1.82021-08-07#5272Add batch method to insert records
0.1.72021-07-30#5125Enable additionalPropertities in spec.json
0.1.62021-06-21#3555Partial Success in BufferedStreamConsumer
0.1.52021-07-20#4874declare object types correctly in spec
0.1.42021-06-17#3744Fix doc/params in specification file
0.1.32021-05-28#3728Change dockerfile entrypoint
0.1.22021-05-13#3367Fix handle symbols unicode
0.1.12021-05-11#3566MS SQL Server Destination Release!