Connectors

Connect Row Zero to your warehouse

Step-by-step setup for all five supported warehouses. Each section covers minimum permissions, authentication options, and the most common problems during first connection.

Connector setup guides

Row Zero connects to five analytical warehouses. All connections use encrypted credential storage. Row Zero never copies your warehouse data to our infrastructure: queries execute at the warehouse and only result rows are returned to the browser.

Required permissions: The Snowflake role you connect with needs USAGE on the database and schema, SELECT on tables you want to open, and OPERATE on the virtual warehouse that will execute queries.

Authentication: Row Zero supports both username/password and OAuth for Snowflake. OAuth is recommended because it scopes credentials to Row Zero and lets your Snowflake admin revoke access without changing passwords.

Connection string format: Paste your Snowflake account URL in the format orgname-accountname.snowflakecomputing.com. Row Zero will prompt for credentials after verifying the host resolves.

Common problems: The most frequent issue is a virtual warehouse in suspended state. Row Zero auto-resumes a warehouse if it has the OPERATE privilege, but if that privilege is missing, queries fail with a timeout error that looks like a connection problem. Check warehouse status in Snowflake if you see intermittent timeouts.

Required permissions: The Google Cloud service account or user you connect with needs the BigQuery Data Viewer and BigQuery Job User roles on the project. Data Viewer alone is insufficient because Row Zero needs to run jobs to execute queries.

Authentication: Row Zero connects via OAuth using your Google account. During setup, you will see a Google OAuth screen asking for BigQuery access. If your organization restricts third-party OAuth, you can use a service account JSON key instead.

Cost controls: BigQuery bills by bytes processed. Row Zero uses query pushdown to avoid full-table scans wherever possible. Enable project-level billing alerts in your Google Cloud console if you want hard cost ceilings.

Common problems: If Row Zero shows permission errors but your service account has the correct roles, check that the BigQuery API is enabled in your project. The API is off by default in new projects.

Required permissions: Your Databricks user or service principal needs CAN USE on the SQL warehouse and SELECT on the catalog tables you want to open. Unity Catalog is supported.

Authentication: Use a Databricks personal access token (PAT) or a service principal OAuth token. PATs can be generated in your Databricks user settings under Access Tokens. Service principal tokens are recommended for shared team connections.

SQL warehouse vs. cluster: Row Zero connects to Databricks SQL Warehouses, not interactive clusters. SQL Warehouses are designed for analytical queries and support JDBC/ODBC connections, which is what Row Zero uses under the hood.

Common problems: Cold-start latency on a Serverless SQL Warehouse can make the first query in a session appear slow. This is normal. If your warehouse does not auto-start, check the auto-stop and start settings in your SQL Warehouse configuration.

Required permissions: The Redshift user needs USAGE on the schema and SELECT on tables. If you use Redshift Spectrum to query S3-based external tables, the user also needs USAGE on the external schema.

Authentication: Row Zero connects to Redshift using a connection string in the format host:port/database plus username and password. IAM authentication is supported for Redshift Serverless.

Network access: Redshift clusters are often deployed in a VPC with no public endpoint. You may need to configure a VPC endpoint or add Row Zero IP ranges to your cluster's security group inbound rules. Contact support for the current IP ranges.

Common problems: Connection timeouts are usually a security group or VPC configuration issue rather than a credential problem. Check that port 5439 (default Redshift port) is open to inbound traffic from Row Zero's addresses.

Supported deployments: Row Zero connects to DuckDB instances exposed as a MotherDuck cloud database. Local DuckDB file databases are not supported directly; the database needs a reachable endpoint.

Authentication: Connect with your MotherDuck access token. You can generate a token in the MotherDuck console under Account Settings. The token gives Row Zero query access to the databases in your MotherDuck account.

Use cases: DuckDB via MotherDuck is a good option for teams with large Parquet or CSV files on S3 or Google Cloud Storage. DuckDB can query those files directly and Row Zero's query pushdown works the same way as with hosted warehouses.

Common problems: Token expiry is the most common issue. MotherDuck tokens have a configurable expiry; set a long-lived token or configure auto-rotation in your MotherDuck account to avoid repeated reconnection prompts.

How query pushdown works

Every operation you perform in Row Zero, including sorting a column, filtering by a value, writing a formula, or running a pivot, is compiled to SQL before any data moves. The compiled SQL runs on your warehouse. Only the result rows are sent back to your browser.

This means your laptop never processes a billion rows. The warehouse's compute cluster does the work, and you see the answer. Row Zero's query compiler handles the translation from spreadsheet operations to warehouse-specific SQL dialects. The formula =SUMIF(region,"US",revenue) becomes SELECT SUM(revenue) FROM table WHERE region = 'US'. A sort becomes an ORDER BY. A filter becomes a WHERE clause.

Row Zero optimizes the SQL it sends to the warehouse by predicate pushdown (filters are applied before aggregations), column projection (only columns needed for the current view are selected), and query batching (multiple cell formulas that reference the same source are combined into a single warehouse query).

Security model

Row Zero stores an encrypted reference to your warehouse credentials, not the credentials themselves. The encryption key is stored separately from the credential data. Neither key nor credential is stored in the same system.

Row Zero never reads data from your warehouse except in response to an explicit user action such as opening a table or running a formula. We do not run background queries, index your data, or cache table contents on our servers.

Row-level security

Row-level security (RLS) policies configured in your warehouse apply automatically when analysts open tables in Row Zero. Because Row Zero sends SQL to your warehouse using the connected user's credentials, the warehouse's own access control logic runs on every query. An analyst who shares a view in Row Zero does not share data their credentials cannot access.

For Snowflake, this means row access policies on tables apply to Row Zero queries. For BigQuery, column-level security and row-level access policies both apply. Redshift's row-level security feature works the same way. Row Zero does not need any special configuration for RLS; it inherits whatever your warehouse enforces.