Why Squish Never Touches Your Data
Most data tools that connect to your database need access to your actual data. Data catalogs scan tables. BI tools run queries. ETL pipelines extract rows. Squish is fundamentally different: we only need to know what your tables look like, not what is in them.
The Metadata-Only Approach
When you connect a database to Squish, we run queries against your database's system catalogs. On PostgreSQL, that means information_schema. On MySQL, the same. On Snowflake, INFORMATION_SCHEMA views.
These system catalogs contain structural metadata: table names, column names, data types, and constraint definitions. No row data.
The exact query we use to discover tables:
SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema NOT IN ('information_schema', 'pg_catalog');
And for columns:
SELECT table_name, column_name, data_type, is_nullable FROM information_schema.columns WHERE table_schema = 'public';
That is it. We never run SELECT * FROM your_tables. We never read customer records, financial data, PII, or application data.
Why This Works for Relationship Discovery
Squish discovers relationships between database tables. To do that, we need to know:
1. Table and Column Names
Naming conventions reveal relationships. A column named user_id in a transactions table likely references the users table. We detect these patterns from metadata alone.
2. Foreign Key Constraints
Explicit foreign keys are defined in information_schema.table_constraints. We read these constraint definitions without needing to access the underlying data.
3. Data Types
Type compatibility helps filter false positives. A VARCHAR column is unlikely to reference an INTEGER primary key. Data type information comes from information_schema.columns.
4. Statistical Signals (Optional)
At Security Level 2, we can run COUNT and COUNT(DISTINCT) queries to calculate cardinality for scoring relationship confidence. Even at this level, we never read actual values.
The Read-Only User Pattern
We strongly recommend creating a dedicated database user for Squish with access limited to metadata:
CREATE USER squish_readonly WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE your_db TO squish_readonly;
GRANT USAGE ON SCHEMA information_schema TO squish_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA information_schema TO squish_readonly;
This user cannot read your application tables even if it tried. The database enforces this at the permission level.
Credential Security
When you provide database credentials to Squish:
Encryption at Rest
Credentials are immediately encrypted with AES-256-GCM using customer-specific keys managed through Google Cloud KMS. The plaintext is discarded.
Decryption Only at Query Time
When a discovery job runs, credentials are decrypted in memory, used to establish a connection, and cleared from memory after the queries complete.
Never Logged
Credentials never appear in application logs, error messages, or API responses. If you search our entire codebase, you will not find a single log statement that outputs credential values.
How This Differs from Other Data Tools
Traditional data catalogs scan tables to profile data quality and detect PII. BI tools execute arbitrary SQL against production data. ETL pipelines extract and move rows between systems.
Squish operates at the schema level, not the data level. We deliver a comprehensive relationship map without touching your data.
Verifying Our Access
Enable query logging on your database and verify for yourself. Filter for the Squish user:
On PostgreSQL, set log_statement = 'all' and check logs after discovery. You will only see queries against information_schema and pg_catalog.
On Snowflake, check SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY filtered by the Squish user. Every query targets INFORMATION_SCHEMA views.
Getting Started Securely
Your data stays in your database. We only learn table and column names. That is enough to discover relationships across your schema.