Weld moves your data into your warehouse. Here is what we keep along the way, and for how long.
Weld reads from the sources you connect and loads into the warehouse you choose, such as Snowflake, BigQuery, Databricks or Postgres. During a sync, rows are staged as files in Weld’s storage in the EU and deleted once the sync has succeeded, or within 7 days if it fails.
On Redshift and Databricks, load files are copied into storage in your own account, an S3 bucket or a Unity Catalog volume, and stay there under your control.
What Weld keeps
- Synced rows
- Staged in Weld’s EU storage during a sync and deleted when it succeeds, or within 7 days if it fails.
- Weld managed BigQuery
- If you choose one, your data is stored there for the length of your subscription, in the EU or US multi-region you pick when you set it up.
- Run history and sync errors
- Kept for the life of your account so you can see what ran and why it failed. Error messages can contain values from the rows that failed.
- Ed conversations
- Kept as part of your account, including any query results in them.
- Credentials
- Connection credentials are stored in Google Cloud Secret Manager.
- Configuration and logs
- Connection settings, metadata and the logs needed to run the service.
Ed reads your data only if you allow it. It runs in the EU, only reads, and never trains a model on your data.
Ed is Weld’s AI agent. By default it works with your workspace’s metadata only: schema, table and column names, column types and SQL. It can’t run queries or see values from your data. An admin can let Ed read data under Settings → AI. Ed can then run read-only queries against your warehouse, and a limited sample of each result is sent to the model. The same setting applies to AI tools connected through the MCP server.
Ed runs on AI models hosted by AWS in Amazon Bedrock, in EU regions only. Under Amazon Bedrock’s terms, the model provider has no access to your prompts or Ed’s answers.
We don’t use your data, or what goes into and comes out of the AI features, to train AI models, and we only use AI providers whose terms don’t allow it either.
If you let Ed read data, it has the access of the user who asks it, and only reads. Every query is checked against that user’s data access before it runs.
Conversations, including any query results in them, are kept as part of your account and covered by the Data Processing Agreement.
How the data access check works
- Access groups
- Admins restrict data per connector through access groups. Restrictions apply to everyone except admins, and are available on BigQuery warehouses.
- Before each query
- Ed’s query is checked against the user’s access before it runs. It is refused if it reads restricted data, or if the check can’t tell what it reads.
- What Ed still sees
- The names and columns of restricted tables, not their rows.
- Your part
- Restrict the connectors that hold personal or sensitive data, and avoid entering such data in a conversation with Ed unless the task needs it.
Error analysis for failed syncs
When a sync fails, we use an AI model to explain the error and suggest a fix. This runs on Gemini models in Google Cloud’s Vertex AI, in the EU. Error messages can contain values from the rows that failed.
You decide who gets in, and what they can do. People, API keys and AI tools each get only the access you give them.
- Sign-in
- Authentication runs on Auth0. Two-factor authentication is available to every user, and single sign-on where your plan includes it.
- Roles
- Admin, editor and viewer roles decide what each person can change in your workspace.
- Audit log
- On plans that include it, admins can see who changed what in the workspace and export it.
- API keys
- Only admins can create API keys, and each key has full administrator access to the workspace. Treat them as administrator credentials, and revoke keys you no longer use.
- MCP server
- Connect AI tools with OAuth where the tool supports it. OAuth limits the tool to what the signed-in user is allowed to do. Tools you connect are yours to choose and aren’t Weld sub-processors.
- Your systems
- Weld doesn’t need super-user access to your warehouse and asks for the fewest OAuth scopes a connector needs. Warehouses in a private network can be reached through an SSH tunnel.
- Weld staff
- Our data experts and support staff access your systems and data only as far as the services you’ve asked for need it.
Encrypted in transit, hosted in the EU. On AWS in Frankfurt and Google Cloud in the EU.
- In transit
- TLS 1.2 or later from your browser to Weld and between our own services and databases. Connections from Weld to your warehouse and apps use TLS 1.2 or later wherever the other system supports it.
- At rest
- The data pipeline is encrypted at rest.
- Hosting
- Our servers run on AWS in Frankfurt, Germany, in private subnets that aren’t reachable directly from the internet. Google Cloud in the EU holds credentials and, in Belgium, drafts saved in the SQL editor. MongoDB Atlas on Google Cloud in Belgium holds incoming webhook data, sync job records and the workspace audit log. These data centres are certified to SOC 2 and ISO 27001.
- Weld managed BigQuery
- Stored in the Google Cloud multi-region you choose: the EU, which can use data centres in other EU countries, or the US.
- Resilience
- Daily backups, kept for 7 days, to restore service after an incident, and security updates applied in line with our patch management process.
- Vulnerability management
- Regular vulnerability scanning, and an independent penetration test of the Weld platform at least once a year, with findings fixed by severity. The penetration test report is available under NDA.
- Monitoring
- Real-time monitoring and alerts for unusual activity. Uptime and incident history are on our status page.
Audited, and written into the contract. What this page describes is backed by the DPA and Terms.
- SOC 2 Type II
- Independent audit of our controls. The SOC 2 Type II report is available under NDA and the SOC 3 report on request.
- Breach notification
- We notify you within 48 hours of becoming aware of a personal data breach or unauthorised access.
- Transfers
- Transfers outside the EEA rely on an adequacy decision, including the EU-U.S. Data Privacy Framework, or on the EU Standard Contractual Clauses.
- Audits
- We show compliance first with our SOC 2 Type II report and written answers, with a virtual audit if you need more.
- Restricted data
- Weld isn’t for health information covered by HIPAA or card data covered by PCI DSS, unless agreed with us in writing.
Sub-processors
| Sub-processor | Purpose | Data processed in |
|---|---|---|
Amazon Web Services Hosting, and AI models for Ed on Amazon Bedrock | Hosting, and AI models for Ed on Amazon Bedrock | EU (Germany); Bedrock in EU regions |
Google Cloud Secrets, SQL editor drafts, Weld managed BigQuery, failed-sync analysis on Vertex AI | Secrets, SQL editor drafts, Weld managed BigQuery, failed-sync analysis on Vertex AI | EU; managed BigQuery in the EU or US |
MongoDB Managed database for webhook data, sync job records and the audit log | Managed database for webhook data, sync job records and the audit log | EU (Belgium) |
Datadog Infrastructure monitoring and logs | Infrastructure monitoring and logs | EU |
Sentry Application error tracking | Application error tracking | EU |
Slack, Google Workspace and Intercom are used only when you work with our support or data experts. Sign-in (Auth0) and product analytics (Mixpanel) handle data about your users as Weld’s own data, under our Privacy Policy. The full list and its terms are in Appendix B of the DPA.