How do I own my CRM database?
Only with a dedicated database you can export in full. Most CRMs share one database across every customer and call a CSV download an export.
The short answer
- You own your CRM database only when the vendor gives you a dedicated database you can export in full, and ideally connect to directly. Not a shared database you have no direct access to.
- Most SaaS CRMs are multi-tenant. Every customer's rows sit in the same shared database, separated by a customer-ID column and application logic, not by a database boundary.
- On a multi-tenant platform, 'export' commonly means CSV downloads of the objects the vendor has chosen to expose. The relationships between records are flattened or dropped rather than preserved.
- A single-tenant CRM, where each customer gets a dedicated database instance, can offer a full database dump on request. There is no other customer's data in the same database to protect.
Why 'I can export my data' does not settle the question
Almost every CRM will tell you that you can export your data, and almost every CRM means something different by it. The distinction that matters is tenancy. Does your data live in a database that only you can see? Or does it live in a shared database beside every other customer's data, distinguished only by a column that says which customer a row belongs to?
Multi-tenant is the far more common architecture, because it is cheaper to run. One set of infrastructure serves every customer, and the vendor scales it once instead of once per client. The trade-off lands on the customer at export time. A multi-tenant vendor can give you your rows, typically as CSV files per object type. It cannot hand you the database itself, because the database also holds every other customer.
Single-tenant flips that. Each customer's data lives in its own database instance from the start, so a full export is just a database dump. In some cases you can connect to the database directly. The cost is usually higher for the vendor to run. That is why it is less common, and why it tends to appear on products built around data ownership as a feature rather than an afterthought.
Tenancy models and what export actually means
| Full export? | Direct database access? | Data residency choice? | |
|---|---|---|---|
| Multi-tenant (most SaaS CRMs) | CSVs of selected objects, typically | No, by design; your rows share tables with other customers | Rarely; the vendor's region is fixed |
| Single-tenant, database dump on request | Yes, a full database dump | Sometimes, if the vendor offers it | Sometimes, if chosen at setup |
| SalesCrew | Yes, a full Postgres dump plus CSVs everywhere | The client's own project; direct connection is the vendor's own infrastructure choice per instance | Yes, chosen at provisioning by Supabase project region |
Patterns described in general terms rather than named vendors, because tenancy is rarely stated on a vendor page. SalesCrew figures are our own, September 2026. Disclosure: SalesCrew is our product.
What to check in a contract or a trial before you rely on 'export'
Ask for the export format in writing, not the marketing claim. A vendor that says "you can always export your data" should be able to say whether that means every object, including attachments, activity history and custom fields, or a subset. Ask about the objects that are easy to forget: call logs, email threads, custom fields, and the relationships between records. Those are the pieces that get dropped first when an export is limited to the standard object list.
Then ask what happens to isolation if you ever need it proven, for a client, an auditor or your own security review. A multi-tenant vendor can describe row-level security and access controls. It cannot point to a database boundary, because there is not one.
Disclosure: SalesCrew is our product, and it takes the single-tenant approach. One Supabase project per client, meaning a separate Postgres database, storage and edge functions, with the region chosen when the instance is created. Export is a full database dump plus CSVs. On cancellation the pattern is read-only access, then export, then deprovisioning after 90 days as a human decision rather than an automatic delete.
'Export' in a contract often excludes what matters
Questions
- Isn't a CSV export the same as owning my data?
- Not quite. A CSV export typically covers the objects the vendor chose to include, in a flat format that drops the relationships between them. A contact linked to five deals and ten notes exports as separate files with foreign keys you have to rebuild, not as one connected record.
- Does single-tenant always cost more than multi-tenant?
- Usually yes. A dedicated database and its infrastructure cost more to run per customer than a shared one. That is the trade a vendor makes on your behalf: lower cost through shared infrastructure, or higher isolation and portability through a dedicated one. Neither is right for everyone.
- Can I ask a multi-tenant vendor for direct database access?
- You can ask, but most multi-tenant platforms cannot grant it. Your rows sit in the same tables as every other customer's rows. Direct access without exposing other customers' data usually requires the vendor to have built single-tenant infrastructure in the first place.