Database Access Requirements¶
Before connecting TestGen to your database, verify that the database user you plan to use has the required permissions. This page lists the access TestGen needs for each supported database.
How TestGen accesses your database¶
TestGen pushes read-only SQL queries directly into your database to profile data, run tests, and monitor tables. No data is extracted or moved — all query results are stored in TestGen's own application database, not in your target database.
TestGen requires two types of read access:
- Schema metadata — TestGen queries system catalog views (such as
information_schema.columns) to discover tables, columns, and data types in your schema. - Table data — TestGen runs SELECT queries against your tables to compute profiling statistics, execute data quality tests, and collect monitor metrics.
TestGen never creates, modifies, or deletes tables or data in your database. No INSERT, UPDATE, DELETE, CREATE, ALTER, or DROP statements are executed against your database.
Required permissions by database¶
Grant the TestGen database user the following permissions. In all cases, only read access is required.
PostgreSQL and Amazon Aurora PostgreSQL¶
| Permission | Purpose |
|---|---|
USAGE on target schema |
Access the schema containing your tables |
SELECT on tables in target schema |
Profile data, run tests, and collect monitor metrics |
SELECT on information_schema.columns, information_schema.tables |
Discover tables, columns, and data types |
SELECT on pg_catalog.pg_namespace, pg_catalog.pg_class |
Retrieve approximate row counts for profiling optimization |
Note
Access to pg_catalog is available to all database users by default. information_schema views are accessible to all users but only return metadata for objects the user has privileges on — the SELECT grant on your target tables is sufficient. No additional grants are typically needed for these.
Amazon Redshift¶
| Permission | Purpose |
|---|---|
USAGE on target schema |
Access the schema containing your tables |
SELECT on tables in target schema |
Profile data, run tests, and collect monitor metrics |
SELECT on information_schema.columns |
Discover tables, columns, and data types |
SELECT on pg_catalog.pg_namespace, pg_catalog.pg_class |
Retrieve approximate row counts for profiling optimization |
Note
Access to pg_catalog is available to all database users by default. information_schema views are accessible to all users but only return metadata for objects the user has privileges on — the SELECT grant on your target tables is sufficient.
Amazon Redshift Spectrum¶
| Permission | Purpose |
|---|---|
USAGE on external schema |
Access the external schema containing your tables |
SELECT on tables in external schema |
Profile data, run tests, and collect monitor metrics |
Note
Redshift Spectrum uses svv_external_columns for schema discovery instead of information_schema.columns. This view is visible to all users and returns metadata for external schemas the user has access to. Approximate row counts are not available for external tables.
Azure SQL Database and Azure Synapse Analytics¶
| Permission | Purpose |
|---|---|
SELECT on tables in target schema |
Profile data, run tests, and collect monitor metrics |
SELECT on information_schema.columns |
Discover tables, columns, and data types |
SELECT on sys.objects, sys.partitions |
Retrieve approximate row counts for profiling optimization |
Note
No additional permissions are needed beyond SELECT on the target tables. information_schema views and sys.partitions are accessible to all database users by default. Metadata in sys.objects is automatically visible for tables the user has SELECT access to.
Databricks SQL¶
| Permission | Purpose |
|---|---|
USE CATALOG on target catalog |
Access any object within the catalog |
USE SCHEMA on target schema |
Access the schema containing your tables |
SELECT on tables in target schema |
Profile data, run tests, and collect monitor metrics |
CAN USE on the SQL warehouse |
Execute queries using the compute resource specified in the connection |
Note
These permissions apply to workspaces using Unity Catalog. Access to information_schema.columns (used for table and column discovery) is automatic when the user has USE CATALOG and table-level privileges — no separate grant is needed.
Google BigQuery¶
| Permission | Purpose |
|---|---|
roles/bigquery.dataViewer on the target dataset |
Read table data, metadata, and dataset-level INFORMATION_SCHEMA views |
roles/bigquery.jobUser on the project |
Run query jobs |
Note
TestGen queries INFORMATION_SCHEMA.COLUMNS and the __TABLES__ metadata view to discover tables and estimate row counts. The dataViewer role grants access to both.
Microsoft SQL Server¶
| Permission | Purpose |
|---|---|
SELECT on tables in target schema |
Profile data, run tests, and collect monitor metrics |
SELECT on information_schema.columns |
Discover tables, columns, and data types |
SELECT on sys.objects, sys.partitions |
Retrieve approximate row counts for profiling optimization |
Note
No additional permissions are needed beyond SELECT on the target tables. information_schema views and sys.partitions are accessible to all database users by default. Metadata in sys.objects is automatically visible for tables the user has SELECT access to.
Snowflake¶
| Permission | Purpose |
|---|---|
USAGE on warehouse, database, and schema |
Access the compute and storage resources |
SELECT on tables in target schema |
Profile data, run tests, and collect monitor metrics |
Note
information_schema views (used to discover tables, columns, data types, and approximate row counts) are accessible to any role with USAGE on the database — no separate grants are needed. These views automatically return metadata only for objects the role can access.
Security considerations¶
- Best practice is to create a dedicated read-only database user for TestGen, rather than reusing an application or admin account.
- TestGen only needs access to the schemas you want to profile and test. You can restrict access to specific schemas rather than granting database-wide read permissions.
- No data leaves your database during profiling or testing. TestGen pushes queries into your database and stores only computed results (aggregates, statistics, and test outcomes) in its own application database.