Everyone says you own your customer data. Here's how to check.
The phrase is on every commerce platform's marketing page, including ours. Four questions that tell you whether it means anything — with our own answers, including the unflattering ones.
"You own your customer data" appears on nearly every commerce platform's marketing page, and on its own it's nearly meaningless — Shopify exports customers too, and so does almost everyone else. The phrase only becomes useful when you ask what exactly comes out, what doesn't, whether it's gated, and whether it still works on the day you're leaving.
Here are the four questions, and our own answers. We've tried to make the unflattering ones as easy to find as the good ones.
Why the phrase doesn't mean much by itself
Export is table stakes. It has been for years. If a platform's claim to data ownership is "you can download a CSV", they are describing a feature their competitors also have, usually in the same menu.
Worse, "export your data" is vague in a way that hides the interesting details. Which data? In what shape? Everything, or the subset that happens to be easy? We know exactly how load-bearing that vagueness is, because our own /open-source page advertised a data export for months while no export code existed anywhere in our repo. Nobody lied; the phrase was just loose enough that nobody noticed it wasn't backed by anything.
That's why we now have a rule against writing "export your data" without naming the data. Which brings us to the first question.
1. What exactly comes out?
Ask for the file list, not the feature name.
Ours is a zip containing six CSVs and a README:
| File | What's in it |
|---|---|
products.csv | One row per product |
product-variants.csv | One row per variant, keyed to products by slug |
categories.csv | One row per category |
orders.csv | One row per order |
order-items.csv | One row per line item, keyed to orders by order number |
customers.csv | One row per customer |
The customers file carries email, name, when they signed up, when they last logged in, and their address. Amounts in the order files are exact decimals with no rounding applied, in the currency named on the same row.
That's the whole list. Three nouns: catalog, orders, customers.
2. What can't come out?
This is the question that separates a real answer from a marketing one, so here are ours.
Images are links, not files. Product and category images appear as web addresses on your own store domain. You can open one or fetch the column with a script, but the archive doesn't contain the image files themselves — a store's images can run to several gigabytes.
Only the first address per customer. If someone saved three delivery addresses, two of them aren't in the file.
Not your storefront. Your pages, your theme, and your tax and fulfilment settings aren't in there. The archive is a copy of your commercial records, not a backup of your shop's appearance. If you rebuilt elsewhere from this export, you'd be rebuilding the design by hand.
Never your customers' passwords. Those are stored as hashes and are deliberately excluded — the export uses a hardcoded list of allowed columns precisely so a future schema change can't quietly start including them.
3. Is it gated?
Ask whether the export sits behind a paid tier, an app, or a support request. This is where "you own your data" most often turns out to have an asterisk.
Ours has no entitlement check at all. It runs on every plan including Free, deliberately, and there's no upsell in front of it. A trial-tier merchant with thirty products can take their records and go, and we'd rather that than have the claim be conditional.
4. Does it work on the day you're leaving?
The moment data portability matters is the moment the relationship is ending — you're annoyed, or you've been outbid, or something has gone wrong. A feature that works beautifully while you're happy and requires an email to support when you're not isn't portability.
Ours is the same button either way, on the same plan you were already on. It doesn't degrade when a subscription lapses, because it never checked your subscription.
The bit people conflate: your data isn't your database
Worth separating, because we got this wrong on our own site until recently.
If you self-host Niblr, the Postgres database is yours outright. It's on your infrastructure, you have the connection string, and there is nothing between you and the tables.
If you're on our hosted plan, you don't have that. You have the export — the six files above, whenever you want them — but not credentials to the database your store runs in. For months, several pages on this site blurred those two things and implied hosted merchants could walk off with the database. They can't, and we've since corrected every one of those claims.
It's a smaller promise than "you own your database", and it has the advantage of being true.
What ownership looks like beyond the export
Two other things belong in this conversation, because they're where data ownership is usually lost quietly rather than at export time.
Your payment relationship. Because you bring your own gateway, your customers' payment records live in a merchant account in your name. If you leave, you don't re-onboard with a processor or lose your transaction history — the gateway stays yours and the storefront moves.
Your domain. Your store runs on a domain you registered and control. Moving it is a DNS change, not a negotiation.
Neither of those is an export feature, and both matter more than one.
Try the questions on us
They're better questions than "do you own your data", and they work on any platform, including this one. If you want the mechanics rather than the argument, the export is documented here — what's in each file, what isn't, and how to download it.
And if the answers here made you think Niblr is a poor fit, that's a reasonable conclusion to reach from a page we wrote. We'd rather you find that out now than in month seven.