Buster accesses your database through a read-only user. This user needs access to the following:
All tables and columns that would be used in answering user questions.
Access to schema information such as schemas, tables, and columns.
Access to all intermediate tables or columns that would be used to join across tables.
Enabling access to these tables and columns does not mean that end-users will be able to query them. See schema selection to understand how you can manage access controls across your tables and columns.
Select your database tenancy from one of the following options:
Multi-tenant architectures have all customers in the same database. Records are separated on a row-by-row basis, typically by some sort of customer id. If your SQL queries between customers look like the example below, you likely have a multi-tenant architecture.
# Customer 1's query is using the WHERE clause to provision access.SELECT*FROM users WHERE users.id ='customer_1';# Customer 2's query is using the WHERE clause to provision access.SELECT*FROM users WHERE users.id ='customer_2';
Below is a diagram of a multi-tenant architecture.
Single-tenant architectures have customer data broken out into different logical or physical locations. If your SQL queries between customers look like the example below, you likely have a single-tenant architecture.
# Customer 1's query is using the customer_1 schema/databaseSELECT*FROM customer_1.users;# Customer 2's query is using the customer_2 schema/databaseSELECT*FROM customer_2.users;
Below is a diagram of a single-tenant architecture.
For any testing, development, or staging datasources, we recommend using the development environment. This introduces an extra layer of security and prevents access to production environments during development.
Depending on your data source, your credentials will look slightly different:
Host:
This is where your database is active. (Example: rds.amazonaws.com)
Port:
The port your database uses. (Example: 5432)
Database Name:
The name of the database you are connecting to. (Example: postgres)
Username:
The username of the read-only user you created. (Example: buster)
Password:
The password that you assigned to the read-only user at creation. (Example: supersecure!)
Schemas:
The schema(s) you would like to connect to Buster.
If your customers are separated by schema, do not connect all schemas. Only connect the schemas necessary to answer a single customer’s questions.
SSH Config:
If you require a connection through a bastion or jump host, reach out to us: support@buster.so
Host:
This is where your database is active. (Example: rds.amazonaws.com)
Port:
The port your database uses. (Example: 3306)
Username:
The username of the read-only user you created. (Example: buster)
Password:
The password that you assigned to the read-only user at creation. (Example: supersecure!)
If your customers are separated by schema, do not connect all schemas. Only connect the schemas necessary to answer a SINGLE customers questions.
Database Name(s):
The name of the database(s) you are connecting to. (Example: ecommerce_db)
If you’re customers are separated by database, do not connect all databases. Only connect the databases necessary to answer a SINGLE customers questions.
SSH Config:
If you require a connection through a bastion or jump host, reach out to us: support@buster.so
Host:
This is where your database is active. (Example: rds.amazonaws.com)
Port:
The port your database uses. (Example: 3306)
Username:
The username of the read-only user you created. (Example: buster)
Password:
The password that you assigned to the read-only user at creation. (Example: supersecure!)
If your customers are separated by schema, do not connect all schemas. Only connect the schemas necessary to answer a single customer’s questions.
Database Name(s):
The name of the database(s) you are connecting to. (Example: ecommerce_db)
If you’re customers are separated by database, do not connect all databases. Only connect the databases necessary to answer a single customer’s questions.
SSH Config:
If you require a connection through a bastion or jump host, reach out to us: support@buster.so
Json Credentials:
This is the file that was given when you created the service account.
This user must have the bigquery.jobs.create role and have access to the schema information for the project you’re connecting.
Project ID:
This is the identifier for the project you are connecting to. (Example: buster_project)
Dataset ID (Optional):
By default, Buster will pull in all datasets in a project. However, if you want to limit Buster to a specific dataset within a project, you would do that here.
If your customers are separated by dataset, do not connect all datasets. Only connect the dataset necessary to answer a single customer’s questions.
Restrict Tables (Optional):
By default, Buster will pull in all tables in a project. However, if you want to limit Buster to specific tables within a project and dataset, you would do that here.
Host:
This is where your data warehouse is active. (Example: cloud.databricks.com)
API Key:
This is an API Key with read-only access to your cluster.
Warehouse ID:
The identifier of the warehouse you are connecting to.
Catalog:
The name of the catalog that you are connecting to
Reach out to us for help with Redshift connections: support@buster.so
Reach out to us for help with Snowflake connections: support@buster.so
If you need assistance connecting to Buster via SSH, reach out to us: support@buster.so
