VeloDB Customer Offboarding Guide
How to leave VeloDB completely, with the data deletion scope for SaaS and BYOC.
Version 1.0
Before You Begin
This guide explains how to permanently leave VeloDB and what happens to your data afterward. It is written for customers who want a clean and verifiable exit. Read it in full before you start, because some steps cannot be reversed.
Follow this guide only if you intend to leave VeloDB completely. The steps below delete your data and resources permanently. They are not meant for pausing, downgrading, or temporarily suspending a deployment.
Start with the Terminology and Scope sections, which apply to everyone. Then follow the single path that matches your deployment:
| Your deployment | Follow |
|---|---|
| VeloDB runs your warehouse | SaaS Offboarding |
| Your warehouse runs in your own cloud account | BYOC Offboarding |
Each path is complete on its own. You do not need to read the other.
Terminology
| Term | Meaning |
|---|---|
| SaaS | The deployment model where VeloDB runs your warehouse inside the VeloDB cloud account. VeloDB owns the infrastructure and storage. |
| BYOC | "Bring Your Own Cloud." The deployment model where your warehouse runs inside your own cloud account on AWS, GCP, or Azure. You own the infrastructure and storage; VeloDB manages it through a cross-account role. |
| Warehouse | The VeloDB database instance that holds your data and runs your queries. |
| Export | Writing your table data out of the warehouse to object storage using SQL unload. This is the only supported way to take data out of VeloDB. |
| Backup | A snapshot of warehouse data created by the built-in backup feature. Backups cannot be copied or downloaded. |
| Cross-account role | An IAM role in your cloud account that VeloDB assumes to manage a BYOC deployment. |
| Private link | The private network connection between your cloud account and VeloDB: AWS PrivateLink, GCP Private Service Connect (PSC), or Azure Private Link. |
| Object storage | Cloud storage such as Amazon S3, Google Cloud Storage, or Azure Blob Storage. |
| Legal hold | A requirement to preserve specific data for legal reasons, which overrides deletion. |
| Residual records | The limited set of records VeloDB keeps after offboarding for legal, billing, or security reasons. These never include your warehouse data. |
Scope
This guide covers both VeloDB SaaS and VeloDB BYOC. BYOC coverage includes deployments on AWS, GCP, and Azure.
The fundamental difference is who owns the infrastructure, which decides who deletes the data.
| SaaS | BYOC | |
|---|---|---|
| Where the warehouse runs | VeloDB cloud account | Your cloud account |
| Who owns the storage | VeloDB | You |
| Who deletes the data | VeloDB, on your request | You, by deleting your own resources |
| Who removes access | VeloDB | You, with VeloDB confirming |
| Cloud resource cleanup | None for you | You clean up your own resources |
Pre-Offboarding Checklist
Complete this checklist before you delete anything, whichever path you follow. It protects you from losing data you still need and from violating any legal obligation.
- Confirm the termination date with your VeloDB account team in writing, so both sides agree on when access ends.
- Decide what you need to export or migrate, including warehouse data, saved queries, and dashboards.
- Check for any legal hold on your data. If a hold exists, do not delete the affected data until your legal team clears it.
- Close or resolve any open support tickets, because tickets and their attachments may otherwise remain in the support system.
- Understand who deletes your data. In SaaS, VeloDB deletes it on your request. In BYOC, you delete it yourself by removing your own resources after revoking VeloDB's access.
SaaS Offboarding
In SaaS, VeloDB owns the infrastructure and performs the deletion. Your job is to export what you need, request deletion, and confirm it is done.
Steps at a glance
| Step | Action |
|---|---|
| 1 | Export your data |
| 2 | Delete the warehouse |
| 3 | Confirm backup deletion |
| 4 | Revoke access |
| 5 | Handle support artifacts |
Step 1 — Export your data
Exporting is the only way to take your data out of VeloDB. Once the warehouse is deleted, the data cannot be recovered.
Export two things:
- Warehouse data, using the standard SQL unload paths to write tables to object storage. Backups cannot be copied or downloaded.
- Saved objects, including saved queries, scheduled tasks, and dashboard definitions, which you save from the console. These are not part of warehouse data exports.
For the detailed export steps and supported formats, see the data export documentation.
Step 2 — Delete the warehouse
When your exports are complete and verified, delete the warehouse. For the step-by-step procedure, see the product documentation. In SaaS, deleting the warehouse also removes its underlying storage, because VeloDB owns it.
Warning — Warehouse deletion is permanent. Once a warehouse is deleted, the data cannot be recovered by you or by VeloDB.
Step 3 — Confirm backup deletion
VeloDB-managed backups follow the retention period in your service configuration, commonly up to thirty days, after which they are removed automatically. If you want them deleted sooner, request this during offboarding.
Step 4 — Revoke access
- Remove all VeloDB console users and disable single sign-on for the organization.
- Revoke API keys, service accounts, and personal access tokens.
Step 5 — Handle support artifacts
- Tickets and their message history remain in the support system as business records unless you request deletion.
- Diagnostic bundles, attachments, and screenshots can be deleted on request, subject to any legal hold.
- Session logs from support connections are retained for a limited period and then removed automatically.
To have support artifacts deleted, send a written request to VeloDB support listing the tickets and attachments you want removed.
BYOC Offboarding
In BYOC, you own the infrastructure, so you perform the cleanup yourself. VeloDB only removes its managed components and confirms it no longer holds access.
Steps at a glance
| Step | Action |
|---|---|
| 1 | Export your data |
| 2 | Delete the warehouse |
| 3 | Revoke access |
| 4 | Clean up cloud resources |
| 5 | Confirm backup deletion |
| 6 | Handle support artifacts |
Follow the steps in this order: export, delete the warehouse, revoke access, then delete your own resources.
Step 1 — Export your data
Exporting is the only way to take your data out of VeloDB. Once the warehouse is deleted, the data cannot be recovered.
Export two things:
- Warehouse data, using the standard SQL unload paths to write tables to object storage. Backups cannot be copied or downloaded.
- Saved objects, including saved queries, scheduled tasks, and dashboard definitions, which you save from the console. These are not part of warehouse data exports.
For the detailed export steps and supported formats, see the data export documentation.
Step 2 — Delete the warehouse
When your exports are complete and verified, delete the warehouse. For the step-by-step procedure, see the product documentation.
In BYOC, deleting the warehouse stops the managed service and releases the compute. Because you own the bucket and the rest of the infrastructure, the recommended approach is to take control of the cleanup yourself: revoke VeloDB's access (Step 3), then delete your own resources, including the bucket data (Step 4). This gives you full control over what is deleted and when, and it produces your own audit trail.
Warning — Warehouse deletion is permanent. Once a warehouse is deleted, the data cannot be recovered by you or by VeloDB.
Step 3 — Revoke access
The access resources live in your own cloud account, so you hold the permission to remove them and you perform the revocation. VeloDB cannot delete them for you; its role is to confirm it no longer holds or uses the credentials once you have removed them. Revoke access here, right after deleting the warehouse, so that you control the cleanup of your own resources in Step 4.
In your own account, revoke the access that VeloDB was granted when the deployment was created. Work from the BYOC setup steps you followed during onboarding and reverse them, removing the cross-account role, its trust relationship, and the private link resources that were created for VeloDB.
Also revoke organization-level access:
- Remove all VeloDB console users and disable single sign-on.
- Revoke API keys, service accounts, and personal access tokens.
After you finish, ask VeloDB to confirm in writing that it has stopped using the role and no longer holds access. This is a safety check: if you missed a role, trust relationship, or connection, VeloDB's confirmation surfaces it so you can clean it up.
Step 4 — Clean up cloud resources
These resources were created in your account during deployment and remain after the warehouse is deleted. Remove them in the order shown to avoid dependency errors.
| Resource | What to do | Notes |
|---|---|---|
| Object storage bucket (S3 / GCS / Blob) | Empty, then delete | Holds warehouse data and backups; export first |
| IAM role and policies | Detach policies, then delete the role | Includes the cross-account role used by VeloDB |
| Instance profile | Delete after the role is removed | Tied to the compute instances |
| KMS key | Schedule key deletion | Disable first; deletion has a waiting period |
| VPC and private link endpoint | Delete the endpoint and related routes | Remove the endpoint before deleting the VPC |
| Security groups | Delete after the endpoints are gone | Cannot be deleted while still attached |
All resources that VeloDB created in your account are tagged. Find them by filtering on the VeloDB resource tag in your cloud console, then remove everything that carries it. If you are unsure which tag identifies these resources, ask VeloDB to confirm it.
Step 5 — Confirm backup deletion
In BYOC, backups live in your own object storage, so deleting the bucket in Step 4 removes them. Retention is fully under your control because the storage is yours.
Step 6 — Handle support artifacts
- Tickets and their message history remain in the support system as business records unless you request deletion.
- Diagnostic bundles, attachments, and screenshots can be deleted on request, subject to any legal hold.
- Session logs from support connections are retained for a limited period and then removed automatically.
To have support artifacts deleted, send a written request to VeloDB support listing the tickets and attachments you want removed.
Reference: What VeloDB May Retain
Some operational data may remain in VeloDB systems or third-party systems after you leave. This data supports billing, security, and service operation, and is not part of your warehouse data.
| Data | Where it may remain | Deletable on request? |
|---|---|---|
| Service and query metadata | VeloDB operational systems | Yes, deleted on your request with no conditions |
| Diagnostic and performance telemetry | VeloDB monitoring systems | Expires and is deleted over time; no fixed retention period is guaranteed |
| Support and observability data | Third-party support and monitoring tools | Partly; some is anonymized |
| Cloud provider logs (BYOC) | Your own account | Controlled entirely by you |
VeloDB may also keep a limited set of residual records for legal, financial, or security reasons, governed by the agreement and applicable law.
| Record | Why it is retained | Retention |
|---|---|---|
| Account metadata | Identify the former customer | Retained; not deleted at this time |
| Billing and legal records | Tax, accounting, and contract law | As required by law, often years |
| Audit logs | Security and compliance evidence | Per the security program |
| Support tickets | Service history and business records | Per the support retention policy |
Your warehouse data is never part of these records. Once it is deleted, it is gone.
Escalation and Contacts
| Topic | Contact | Use for |
|---|---|---|
| Support | VeloDB support team | Export help, ticket cleanup, deletion confirmation |
| Account | Your account manager | Termination date, scope, and timeline |
| Legal | VeloDB legal team | Legal hold, data processing, and contract records |
| Security | VeloDB security team | Confirming access removal and audit evidence |
If a request is not handled within the expected time, ask your account manager to escalate it. Keep all offboarding requests in writing so there is a clear record.