Supabase and Google Play Data safety: how to review your app's answers

What Google Play is asking you to review

Google Play's Data safety section describes data collected and shared by your app, including processing performed by SDKs and hosted services that your app uses. The useful unit of review is not the name of a vendor. It is the path from a user action, through your app, to Supabase Auth, your database, or another service.

Start by making an inventory of production behavior. Identify whether you use Supabase Auth, database tables, Storage, Realtime, Edge Functions, or only a subset of those features. Then check the mobile build that you plan to publish, not a development configuration. A feature that exists in a repository but is disabled in the release build should not be treated the same way as an enabled feature.

Declora separates this review into an App Passport, App Facts, and the store-specific output. The catalog suggests an App Fact with a confidence level and reason; you, as the developer, confirm whether it describes your production app. That distinction matters for Supabase because the platform is flexible and your schema, policies, and Auth methods determine much of the answer.

Supabase Auth changes the review

If you use Supabase Auth for accounts, inspect the sign-in methods you have enabled and the values your app persists. Email sign-in can involve an email address. Other methods can provide a user identifier or different profile fields. Do not infer that every possible Auth field is collected simply because Supabase Auth is installed.

Ask yourself these questions:

• Is Supabase Auth enabled in the production project?
• Do users create accounts, or can they use the app without signing in?
• Do you offer email sign-in, password reset, magic links, or an identity provider?
• Does your app keep the Auth user ID in its own records or send it to other services?
• Do you store an email address, name, phone number, or other profile value after sign-in?

The Service Profile treats a Supabase user ID and email address as configuration-dependent. In Declora, those App Facts should remain suggestions until you confirm them. If your app uses Auth but only keeps an opaque account reference, review how that reference maps to your actual implementation rather than assuming it is an email address.

Your database schema is part of the answer

Supabase database features do not impose a fixed personal-data schema on your app. The answer depends on the columns you create and the records your app writes. A notes app, a marketplace, and a team dashboard can all use Supabase while processing very different information.

Review your migrations, row-level security policies, insert and update calls, and any server-side jobs. Look for fields that contain account identifiers, contact details, user-generated content, purchase records, or location information. Also check whether logs, analytics events, or error reports receive copies of those values. A value can be collected by your app even when Supabase is the service that stores it.

Keep the Google form aligned with the complete data flow. If your app sends a user ID to Supabase and then sends that same ID to an analytics provider, review both paths. If a field is generated only for internal database joins and never reaches the Android app, document that distinction in your internal review rather than using a generic vendor checklist.

Collected, shared, optional, and deleted are different questions

Do not collapse Google Play's questions into one yes-or-no decision. Collection asks whether data is transmitted from or generated by your app. Sharing concerns transfer to another company. Optionality asks whether users can choose not to provide the data. Deletion asks whether your app supports the relevant deletion behavior.

For example, an email address used for account creation may be collected and may be optional only if your app offers a genuine path to use the feature without providing it. A Supabase Auth user ID can support account management without being an advertising identifier. A database row may be deleted from your system while backups, audit records, or a separate provider still require a documented retention review.

Declora's Google output keeps these dimensions separate. If a value is suggested but not confirmed, the output should ask for confirmation instead of presenting an assumption as settled. Use the prompts to inspect the release configuration, then record the developer-confirmed answer in the App Passport.

A practical review sequence

1. Open the production Supabase project and list enabled Auth methods and data services.
2. Trace account creation, sign-in, profile updates, and account deletion through the client and server code.
3. Map each stored field to the real user-facing purpose; do not label a field from its column name alone.
4. Check whether data is sent to Supabase, another provider, or both.
5. Confirm whether account and contact fields are required, optional, or never requested.
6. Review encryption in transit and the deletion behavior implemented by your app and backend.
7. Run a Consistency Check across your Google Play answers, privacy notice, and product behavior.

Keep evidence close to each decision: a migration, an API call, an Auth setting, or a release-build test. You do not need to copy a database schema into the guide or into your store listing. You do need enough internal evidence to explain why each confirmed App Fact matches production behavior.

Where Public Pages and Safe Mode help

Use Public Pages when you need a stable, shareable explanation of the privacy information your product presents to users. Public Pages are not a substitute for reviewing the Data safety form, but they give your team and reviewers a consistent place to inspect the product's stated data practices.

Safe Mode is useful when you want a deliberate review before changing a confirmed fact or preparing store-facing output. Keep questions unresolved until someone with knowledge of the production app can answer them. That is safer than converting a likely fact into an unsupported certainty.

Declora is not a law firm, and it cannot guarantee store approval. Its catalog and Consistency Check help you organize evidence and spot mismatches; you remain responsible for confirming your app's behavior and completing Google Play's form.

FAQ

Does installing Supabase mean I collect email addresses?

No. Supabase supports several features and Auth configurations. Review the production sign-in methods and confirm whether your app receives, stores, or sends an email address. Declora can suggest the App Fact, but you confirm it.

Does Supabase automatically make data shared with a third party?

You should review the transfer to Supabase in the context of your Data safety answers and the way your app uses the service. The relevant question is what your app transmits and how the provider processes it, not merely whether a package appears in a dependency list. Confirm the answer for your architecture and current provider terms.

What should I do when my Supabase schema contains user-generated content?

Trace which content the Android app accepts, where it is stored, and whether it is sent to another service. Confirm the related App Fact only when that behavior exists in production. Also review deletion, access controls, and the wording users see in your privacy information.

Can Declora fill in the Data safety form for me?

Declora can organize App Facts, show catalog-derived guidance, and run a Consistency Check. You still confirm the facts and submit the store form. Declora is not a law firm and cannot guarantee store approval.