PolyBase is a new feature of SQL Server that allows you to connect to relational and non-relational data. You can run queries on any external data sources you might have, such as Oracle, PostgreSQL, Salesforce, MongoDB, Hadoop, etc. When paired with the CData ODBC Driver for PostgreSQL, you get access to your PostgreSQL data directly alongside your SQL Server data.
To help you get started, we put together this tutorial on how you can create an external data source and external tables to grant access to live PostgreSQL data using T-SQL queries.
The CData ODBC Drivers interact live with PostgreSQL data using PolyBase, leveraging optimized data processing built into the driver. When you issue complex SQL queries from SQL Server to PostgreSQL, the driver pushes down supported SQL operations, like filters and aggregations, directly to PostgreSQL and utilizes the embedded SQL engine to process unsupported operations client-side (e.g. SQL functions and JOIN operations). With PolyBase, you can also join SQL Server data and PostgreSQL data using a single query to pull data from distributed sources.
If you have not already, first specify connection properties in an ODBC DSN (data source name). This is the last step of the driver installation. You can use the Microsoft ODBC Data Source Administrator to create and configure ODBC DSNs. To create an external data source in SQL Server using PolyBase, configure a System DSN (CData PostgreSQL Sys is created automatically).
To connect to PostgreSQL, set the Server, Port (the default port is 5432), and Database connection properties and set the User and Password you wish to use to authenticate to the server. If the Database property is not specified, the data provider connects to the user's default database.
Click "Test Connection" to ensure that the DSN is connected to PostgreSQL properly. Navigate to the Tables tab to review the table definitions for PostgreSQL.
After configuring the connection, you need to create a master encryption key and a credential database for the external data source.
Execute the following SQL command to create a new master key, 'ENCRYPTION,' to encrypt the credentials for the external data source.
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'password';
Execute the following SQL command to create credentials for the external data source connected to PostgreSQL data.
NOTE: IDENTITY and SECRET correspond with the User and Password properties for PostgreSQL.
CREATE DATABASE SCOPED CREDENTIAL postgresql_creds
WITH IDENTITY = 'username', SECRET = 'password';
Execute the following SQL command to create an external data source for PostgreSQL with PolyBase, using the DSN and credentials configured earlier.
NOTE: SERVERNAME and PORT corresponds to the Server and Port connection properties for PostgreSQL. PUSHDOWN is set to ON by default, meaning the ODBC Driver can leverage server-side processing for complex queries.
CREATE EXTERNAL DATA SOURCE cdata_postgresql_source
LOCATION = 'odbc://SERVERNAME[:PORT]',
CONNECTION_OPTIONS = 'DSN=CData PostgreSQL Sys',
-- PUSHDOWN = ON | OFF,
CREDENTIAL = postgresql_creds
After creating the external data source, use CREATE EXTERNAL TABLE statements to link to PostgreSQL data from your SQL Server instance. The table column definitions must match those exposed by the CData ODBC Driver for PostgreSQL. You can refer to the Tables tab of the DSN Configuration Wizard to see the table definition.
The statement to create an external table based on a PostgreSQL Orders would look similar to the following:
CREATE EXTERNAL TABLE Orders(
ShipName nvarchar NULL,
ShipCity nvarchar NULL,
) WITH (
Having created external tables for PostgreSQL in your SQL Server instance, you are now able to query local and remote data simultaneously.
Organizations today have multiple database providers and sources they must integrate. The PostgreSQL ODBC Driver allows you to connect with live PostgreSQL data, directly from any applications that support ODBC connectivity.
Thanks to built-in query processing in the CData ODBC Driver, you can trust that as much query processing as possible is being pushed to PostgreSQL, freeing up local resources and computing power.