Where your customer data physically sits
Your customers' names and phone numbers sit on a disk in a building somewhere. Most teams can name the vendor. Far fewer can name the country, and fewer still chose it. On Airtable's pricing page today, European data residency appears in exactly one column: Enterprise Scale, priced on request. On a Postgres database you run, the region is a dropdown you set once and never think about again.
The question that arrives from a lawyer
Nobody asks where the rows live until someone does. It comes from a client's legal team during procurement, or from a customer in Germany, or from a clinic that cannot sign anything without an answer. The question has one correct form: name the jurisdiction where this personal data rests.
Airtable will answer it, for a price. Its pricing page lists the Business plan at $45 per seat per month billed annually, with the admin panel and SAML single sign-on included. European data residency is not on that tier. It sits one step up under Enterprise Scale, next to HIPAA compliance, audit logs and data loss prevention, on a plan with no published price. So the honest answer to a German client while you are on Business is that your rows are wherever Airtable keeps them, and changing that runs through a sales process rather than a settings page.
None of this makes Airtable unreasonable. Operating separate regional infrastructure costs them real money, and they charge the customers who need it. The issue is the shape of the control. It belongs to the vendor, so it carries a price and a procurement cycle, and you reach it by escalating instead of by deciding.
On infrastructure you run, it is a dropdown
Supabase deploys each project to one primary region. Its docs list seventeen specific AWS regions, including Frankfurt, Paris, Stockholm, Mumbai and Sao Paulo. Choose a specific EU region and your Postgres database, Auth service and Storage objects are pinned to that exact AWS region. The control costs nothing. You use it while creating the project.
Supabase's own documentation is careful about what that buys you, and the care is worth copying. The general "Europe" grouping includes London and Zurich. Both sit under adequacy regimes, neither is an EU member state. The docs say in plain words that region selection is a data-location control and not proof of regulatory compliance. A team in Lima learns the same lesson in reverse: the nearest specific region is Sao Paulo, so Peruvian customer data lands in Brazil unless someone decides otherwise.
Ownership does not make the question easier. It changes who answers it. When we moved Stay World Class off Webflow and Xano onto Next.js, NestJS and Supabase, the migration ran as a four stage ETL that mapped every legacy ID to a Postgres UUID. The part that matters here is dull and useful. Once the rows live in a database you control, moving them to another region is a dump and a restore. You schedule it for a Sunday. Nobody quotes you for it.
The parts that leak
Picking a region for the database is the easy half. Supabase publishes what still escapes it: backups, logs, data exported to external systems, Edge Function execution, and sub-processors. Any of those can leave a copy of a row somewhere you did not choose, and the list is honest enough to work as a checklist.
The same leaks exist on a no-code stack, with one difference. You cannot see them and you cannot move them. Your automation layer runs where the vendor runs it. Each integration keeps its own copy in its own region under its own terms. Cloudflare's Data Localization Suite, which governs where traffic metadata and logs stay and where HTTPS traffic gets decrypted, is an Enterprise-only paid add-on, so even the network layer charges for the answer.
Webflow's published site plans measure bandwidth, static pages and form submissions. Nothing in that list is a region. The Team plan starts at $2,500 a month on an annual contract and the step after it is Enterprise at a custom price. If your marketing site collects form submissions carrying names and email addresses, and most do, that is worth knowing before a client asks rather than after.
When the platform's answer is the right answer
Plenty of teams should ignore everything above. If the personal data you hold is a mailing list and a few hundred contact form entries, no lawyer is going to ask and no regulator is going to care which US region they sit in. Residency is a cost of being wrong, and that cost scales with how sensitive the rows are and how many of them exist. A 300 record CRM and 40,000 medical bookings are not the same object.
If your customers all live in one country and your vendor already stores data in a jurisdiction that country accepts, you have an answer and it was free. Write it down with the date you checked it, then go back to building the business. The teams that get hurt are the ones who assume they have an answer without ever looking.
The damage happens in the gap between those two states. A team sells into a European enterprise from an Airtable base, the security questionnaire shows up, and the only route to a yes runs through a plan with no published price. That is when the migration gets decided, under a deadline, which is the worst possible time to decide it. Checking where your rows sit today takes about twenty minutes.
