Summary
UpGuard Research reports finding 16,326 Supabase databases with readable tables among about 300,000 candidate domains. Its analysis of database schemas found indicators of personal information in over half of those databases.
UpGuard Research reports that it found 16,326 Supabase databases with readable tables among about 300,000 domains it examined. The company’s analysis of database schemas found indicators of personally identifiable information (PII) in more than half of those databases. UpGuard says it inspected a limited number of records in selected cases to check for meaningful exposures and notified application owners when it found significant ones.
The findings point to a configuration risk in applications using Supabase, a hosted PostgreSQL database service: a database can be reachable from an app but still needs correctly configured access controls to keep information private. The study’s count describes databases with readable tables, not a confirmed count of affected people.
What the study found
UpGuard gathered about 300,000 unique domains with indications of Supabase use, then assessed whether their databases exposed readable tables. It used table schemas—the structures that describe fields and their types—to estimate what kinds of information might be stored, rather than reading every row across all the databases.
More than half had schema indicators of some PII. A smaller share had indicators of passwords or authentication tokens, while a very small number appeared to contain credit-card data. UpGuard also found signs that some sites used payment systems; the report treats that as an indicator of possible financial-process risk, not as proof that payment-card data was exposed.
Examples from cases the researchers examined illustrate the potential sensitivity. One database associated with an India-based adult-content platform reportedly contained 65,467 user records with identity and payout information, as well as more than 100,000 private messages. UpGuard also describes exposures involving a Philippine OTP service, a US valet business and a Canadian immigration service.
Why database access settings matter
Supabase uses PostgreSQL, which supports row-level security (RLS): policies that control which rows a database user can read or change. UpGuard says Supabase made changes so RLS is enabled by default for tables created through its Table Editor interface. In its account, tables created programmatically through the API—which is how coding agents interact with Supabase—do not have RLS enabled by default. Having RLS switched on is only part of the protection; the policies and credentials must also be configured appropriately.
That distinction matters as developers increasingly use AI coding agents to build applications. An agent can help create a working database-backed product, but database access rules remain a separate security concern. If a table is readable when it should be restricted, personal or business data may be exposed.
UpGuard’s estimate has a defined scope: it examined domains with indicators of Supabase use and focused its checks on accessible tables, including a commonly named user table. Schema analysis can flag the kinds of information a database may hold, but it does not count every exposed record. The 16,326 figure is therefore a count of databases identified by this method, not a measure of the total number of people affected.