Correcting a common assumption first
Most comparison content treats PDPA as a data residency law, requiring Singapore-based hosting. It is not. Singapore’s PDPA does not impose data localisation or data residency requirements. An organisation is not obliged to keep personal data physically inside Singapore, even when it is processed abroad.
What the PDPA actually requires is the Section 26 transfer limitation obligation: personal data can leave Singapore only if the receiving party provides a standard of protection comparable to the PDPA. This is satisfied through a contract with the overseas processor, or through a recognised certification such as APEC’s Cross-Border Privacy Rules. There is no legal requirement to pick the Singapore region specifically.
So why choose ap-southeast-1 anyway
Choosing a Singapore-region deployment does not satisfy a legal residency mandate that does not exist. It removes the transfer limitation question from the table entirely, since no cross-border transfer occurs if the data never leaves the region. That is a compliance simplification, not a legal requirement, and it is worth doing for the reduced paperwork alone: no contract clause to draft with an overseas processor, no certification to verify, one fewer control to document if a data protection audit ever happens.
Supabase’s actual mechanism
Supabase deploys each project into a region chosen at project creation, and Supabase’s own documentation states plainly that ensuring the project sits in the correct region is the customer’s responsibility, not something enforced automatically. Once ap-southeast-1 is selected, data stays in that region unless the customer also creates a read replica elsewhere.
Row Level Security is the second half of the PDPA-relevant picture. RLS defaults to deny-all once enabled on a table, meaning no row is readable or writable until an explicit policy grants access. This matters for the PDPA’s protection obligation, not just the transfer obligation. A misconfigured API that exposes a users table is a protection failure regardless of which region the database sits in, and RLS is the mechanism that prevents it at the database layer rather than relying on application code to remember to filter every query.
Firebase’s position
Firebase can deploy to the Singapore region (asia-southeast1) on Google Cloud infrastructure, which addresses the same practical goal of avoiding a cross-border transfer. Firebase offers no self-hosting path at all, since it is a fully managed proprietary service. For most Singapore founders this is not the deciding factor, since self-hosting has its own operational cost, but it removes a hypothetical option that some open-source-first teams weigh at the design stage.
The verdict
Neither platform is required by PDPA in a specific technical sense, since the law is about the standard of protection, not the physical location of the server. Both Supabase and Firebase can be deployed inside a Singapore region, which sidesteps the transfer limitation question in the simplest possible way.
The real decision driver is the database model rather than compliance. Supabase gives Postgres with SQL-based Row Level Security, self-hosting available if ever needed, and a data model suited to relational data like orders, users and inventory. Firebase gives a managed NoSQL document store with less relational structure and no self-hosting path. For a marketplace or ecommerce backend with relational data (orders linked to users linked to products), Supabase’s structure fits the domain more naturally, and its region selection plus RLS combination gives a clean, auditable story if a data protection question ever comes up.
Research Ledger (6 claims)
| Entity | Claim | Source | Status |
|---|---|---|---|
| Singapore PDPA | Does not impose data localisation or residency requirements | Chambers Global Practice Guides 2026 | VERIFIED |
| Singapore PDPA | Section 26 transfer limitation obligation requires comparable protection standard for overseas transfers, not physical residency | ResGuard, Chambers | VERIFIED |
| Singapore PDPA | APEC CBPR/PRP certification recognised as a valid basis for comparable protection | ICLG Singapore data protection chapter | VERIFIED |
| Supabase | Project region is chosen at creation, data stays in that region, region selection is the customer’s responsibility | Supabase Docs, SOC 2 Compliance page | VERIFIED |
| Supabase | Row Level Security defaults to deny-all once enabled, policies are SQL evaluated per query | Supabase RLS guides (multiple secondary sources) | VERIFIED |
| Firebase | Deploys to asia-southeast1 (Singapore) on Google Cloud, no self-hosting option exists | Secondary source (Thai SME comparison guide), region name should be reconfirmed on Firebase’s own docs | INFERRED |