Connect to any data source

Overview

Posit products can connect to a variety of data sources, including: Snowflake, Databricks, Oracle, SQL Server, PostgreSQL, and many others. Each data source might have specific connection methods and requirements.

The Getting started pages of this guide explain the concepts behind data connections: the connection methods available to you, the credential types that determine who sees what data and for how long, and how to manage credentials from development to deployment.

This page brings those concepts together into a repeatable recipe you can apply to any data source, including sources this guide does not cover in detail.

For Databricks and Snowflake, we have already worked through this recipe for you. If you use one of these sources, go straight to its source guide for connection types, recommended credentials, and ready-to-use code:

For other sources, follow the steps below.

More data sources and connection methods will be added over time, so check back for updates.

Connection recipe

Connecting to a data source comes down to three decisions. Work through them in order.

Step 1: Choose a connection method

Identify how your code will talk to the source. In general, prefer an SDK or language-specific library when one exists, and fall back to an ODBC driver otherwise. For sources exposed as web APIs, use an HTTP client such as httr2 or requests, or a dedicated package that wraps the API.

See Connection methods for the trade-offs, and the common data sources table for the recommended R and Python libraries by source type.

Step 2: Choose a credential scope and lifetime

Decide whose permissions the connection carries (scope) and how long the credential stays valid (lifetime). Generally, prefer:

  • A user scope so each viewer sees only the data they are authorized to access.
  • The most secure lifetime your source and platform support, which usually means an ephemeral OAuth token over a long-lived password or token.

The most secure combination is a user-scoped, ephemeral credential. Choose the scope first based on your use case, then choose the best lifetime available for that source. See Credential types for the full explanation.

Tip

Workbench and Connect provide managed OAuth integrations for many common sources, including AWS, Google, Microsoft, GitHub, and Salesforce, as well as custom OAuth providers. If your source is on that list, you can often achieve a user-scoped, ephemeral credential without managing any secrets in code. See How Workbench and Connect help.

Step 3: Make your code portable from development to deployment

The credential you use while developing in Workbench usually differs from the one your content should use once deployed to Connect. Write your connection code so it selects the right credential in each environment.

Some sources have helper packages that handle this switch for you, such as the Python posit-sdk or the R connectcreds package. When no helper is available, add logic that checks the POSIT_PRODUCT environment variable and applies the correct credential pattern in each environment.

See Managing data access from development to deployment for the pattern and code examples.

Example

Suppose you need to read data from an AWS S3 bucket, a source this guide does not cover with a dedicated page:

  1. Connection method: AWS provides language-specific libraries, so you use boto3 in Python or paws in R rather than a generic driver.
  2. Credential scope and lifetime: You want each viewer to see only the objects they are authorized to access, so you choose a user scope. AWS is supported by both Workbench Advanced Managed Credentials and Connect OAuth integrations, so you can use a user-scoped, ephemeral credential in each environment without storing any secrets in code.
  3. Development to deployment: In Workbench, your session uses a Workbench-managed AWS credential. When you deploy to Connect, the content uses a Connect OAuth credential, either a viewer credential for user scope or a service account for one-to-many scope. Add logic that checks POSIT_PRODUCT so your code uses the right one in each environment.

The same three steps apply to other databases, APIs, and additional sources.

ImportantAdministrator configuration required

Many connection methods and credentials require an administrator to install drivers or configure integrations before you can use them. Look for notes like this one throughout the guide, and see the Data sources admin guide.