Fourteen databases, three file formats, three places to read the files from. TestGen added sources in three 2026 releases, so date anything you quote from this list.
The full list, as of TestGen 5.134.0
The source is the TestGen product page as of October 2026, with release versions from the posts linked in the table.
| Kind | What TestGen connects to | Added |
|---|---|---|
| Cloud warehouses | Snowflake, Databricks SQL, Google BigQuery, Amazon Redshift, Azure Synapse Analytics | |
| Relational databases | PostgreSQL, Amazon Aurora PostgreSQL, Microsoft SQL Server, Azure SQL Database | |
| Enterprise databases | Oracle Database 12c and later, SAP HANA | 5.9.4, March 2026 |
| Microsoft Fabric | Microsoft OneLake, through the SQL analytics endpoint | 5.92.1 |
| Other platforms | Salesforce Data 360 | |
| Embedded database | DuckDB .duckdb files, opened read-only | 5.134.0, October 14, 2026 |
| Files | CSV, Parquet, and JSON on a local path, in Amazon S3, or in Azure Blob Storage | 5.134.0, October 14, 2026 |
| External tables | Parquet, Avro, ORC, CSV, and JSON exposed through Apache Iceberg, Amazon Redshift Spectrum, or Snowflake external tables |
A blank in the last column means the sources don’t give a release. File and DuckDB connections shipped in both the open-source and Enterprise editions of 5.134.0. The same goes for every database on the list: each one works in both editions. Enterprise adds users, connections, projects, security, and support, not database connectors.
Files are a connection now
Before October 14, a CSV had to become a table before TestGen could see it. In DataKitchen’s NYC taxi exercise, one 48 MB Parquet file had to be loaded into Postgres first. TestGen 5.134.0 removed that step. It embeds DuckDB 1.5.5 and reads the files where they sit.
You point a connection at a location and declare tables inside it. A table is one file, such as sales/orders.csv, or a pattern, such as sales/*.csv, which makes a folder of daily drops into one table with history. TestGen reads the union of columns across every matched file, so a column that shows up in only some deliveries is still in the table, and a renamed field appears in the next profile. That is the case the vendor files answer works through.
What it needs from each source
Read access, and nothing more. For databases, TestGen runs its queries inside the database, so rows don’t cross the wire. For files, the October release post lists the minimum:
| Source | What you give TestGen | Access it needs |
|---|---|---|
| Local files | An absolute path to a directory | Read access, mounted read-only |
| Amazon S3 | A base URI, plus access keys or an IAM role | s3:ListBucket and s3:GetObject |
| Azure Blob Storage | A storage account and container, plus a managed identity, service principal, or account key | Storage Blob Data Reader |
| DuckDB | The path to a .duckdb file | Read access to the file |
Limits to plan around
Files have no server, so the work lands on TestGen’s machine. Each file or DuckDB run uses TestGen’s own memory and disk, sized to the largest table you read, and by default only one such run happens at a time while the rest queue.
Types are inferred for CSV and JSON. Excel isn’t supported. And on Docker, a local path is resolved inside the container, so mount the folder first. DataKitchen’s sizing guide has the memory and disk numbers.
Migrating between two of these databases? TestGen’s Table Comparison tests run the source’s tests on the target, and the migration answer covers the procedure.