Skip to main content

Singapore region fully open on the domestic site: deploy your backend nearby for Southeast Asia

CloudBase TeamCloudBase Team
7 min read

CloudBase has fully opened the Singapore region on its domestic site.

If your product is serving (or about to serve) Southeast Asian users, you've probably run into these:

  • Servers deployed domestically, with obvious latency for users in Singapore, Malaysia and Indonesia — a degraded experience;
  • Data-export compliance requirements getting more detailed, and "can the data stay local" becoming an unavoidable question;
  • Wanting to validate an overseas business quickly, but not wanting to set up a whole new account system or learn a new cloud product just for a new region.

Now there's no need to start from scratch: CloudBase has officially opened the Singapore region on the domestic site, and developers keep using the domestic account and console while deploying backend services nearby in the Singapore data center.

Singapore region fully open, PostgreSQL exclusively

Domestic-site users can now select the "Singapore" region when creating a CloudBase environment. The Singapore region exclusively provisions PostgreSQL (PG) database environments.

1. Singapore region fully open

This release removes the whitelist restriction for the Singapore region and opens it to all users. Just select "Singapore" in the region selector on the purchase page — operation is exactly the same as the Shanghai region, no extra application, no switching to the international site.

2. Singapore ships PostgreSQL exclusively

The Singapore region only provides PostgreSQL database environments, and doesn't support document databases / MySQL for now.

CloudBase for Supabase is the serverless backend cloud service CloudBase built on top of PostgreSQL, aligned with the industry-mainstream PG-first backend approach (fully Supabase-compatible), unifying database, permissions, authentication and storage into one SQL language system:

CapabilityDescription
PostgreSQL 17 managed databaseComplete SQL: tables/views/indexes/transactions/triggers/stored procedures/window functions/partitioning, all in
PostgREST automatic REST APICreate a table, get an API — front end directly select/insert/update, no hand-written backend
Two-layer permission modelTable-level GRANT (what operations) + row-level RLS Policy (which data you can see), all permissions in one SQL language
JWT authenticationBuilt-in email/phone/third-party login, multi-factor auth; the user table lives in the database for direct SQL joins
Object storageFile metadata in the database storage schema, permissions in the same RLS language
Serverless cloud functionsComplex business logic and third-party integrations via cloud functions

5 concrete benefits of the Singapore region

1. Deploy nearby, faster access in Southeast Asia

The data center physically sits in Singapore. Serving users in Singapore, Malaysia, Thailand and Indonesia, network paths are shorter and API responses faster — a clear upgrade for latency-sensitive scenarios (social, e-commerce, utility apps).

2. Data stays put, compliance easier

Domestic nodes only load domestic-site data; the Singapore region handles site-data loading per compliance policy, isolated at the architecture level to satisfy "data localization" and "regional compliance" requirements.

3. Same account, no international-site signup

Still the domestic account, domestic payment methods, domestic console — no international-site registration, no language switching. Pick a region and you get an overseas node. Dev habits, CLI tools and SDK usage stay basically unchanged.

4. One SQL for data, permissions, accounts and storage

Traditional backends split database, auth service and file storage into three systems with three permission languages, raising integration and maintenance costs. CloudBase for Supabase converges them into one PostgreSQL system:

  • How business data is stored → create a table;
  • Who can read, who can write → GRANT + RLS Policy;
  • Who the user is → a table in the auth schema;
  • How file permissions work → still RLS Policy.

For developers, mastering SQL covers most of data modeling, permission design and cross-module collaboration.

5. Zero ops

Database instance creation, high availability and backup are all platform-managed. Developers don't touch machine specs, scaling or patching; after creating the environment, you create tables and write code right away.

Choosing the "Singapore" region

The whole flow is identical to the CloudBase purchase flow you know, plus one "pick a region" step:

Step 1: Enter the purchase page and select the Singapore region

Open the CloudBase purchase page and select "Singapore" in the region selector — once selected, the database type locks to PostgreSQL automatically (the Singapore region offers no other database type).

Step 2: Pick a plan, place the order and pay

Choose a plan (Personal / Standard / Enterprise) and go through the standard order and payment, same as the Shanghai region.

Step 3: Automatic environment initialization

After the order, the system automatically:

  1. Creates the CloudBase environment;
  2. Creates the PostgreSQL database instance;
  3. Initializes system roles and default permissions;
  4. Configures the API service gateway.

Usually done in minutes, no manual intervention.

Step 4: Enter the console

Once the environment is created, go straight into the PG console to use table management, RLS policy config, connection-info viewing, cloud functions, cloud storage, static hosting and authentication.

Step 5: Connect from code, a few lines

For a web front end, connect to the database directly via SDK, with permissions auto-checked by RLS:

import cloudbase from '@cloudbase/js-sdk';

const app = cloudbase.init({
env: '<environment ID>',
accessKey: '<Publishable Key>',
});

const db = app.rdb();

const { data } = await db
.from('todos')
.select('id, title, is_completed')
.eq('is_completed', false);

await db.from('todos').insert({ title: '写一篇出海文档' });

If you don't use the front-end SDK, you can use the standard REST API (PostgREST spec) from any language or backend framework:

curl "https://<envId>.api.tcloudbasegateway.com/v1/rdb/rest/todos?is_completed=eq.false" \
-H "Authorization: Bearer <Publishable Key>"

For complete table creation, permission config (GRANT + RLS) and advanced usage, see the official docs: PostgreSQL database initialization guide.

A few questions you might ask

Q: Can the Singapore and Shanghai regions coexist?

Yes. Region is an environment-level choice; one account can hold both Shanghai and Singapore environments, created, managed and billed independently per business need.

Q: Will Singapore support cloud database (MySQL / document database) later?

The Singapore region is PG-exclusive for now, focused on doing PostgreSQL deeply. Any plans for other database types will be announced separately.

Q: Already on a Shanghai-region PG environment — can I migrate code to Singapore directly?

Yes. Singapore and Shanghai share the same PostgreSQL stack, SDK and API specs; business code needs almost no changes, just point to the new environment's env at initialization.

Q: How are data security and isolation guaranteed?

The Singapore region is fully isolated at the network layer from domestic regions, following the platform's data-flow isolation and compliance policies — no domestic node accesses overseas data, or vice versa.

Q: Singapore doesn't support Cloud Run — what about existing backends on Cloud Run?

The Singapore region doesn't provide Cloud Run for now, but standard cloud functions (including HTTP triggers) are fully available. We recommend moving lightweight backend logic to web cloud functions — expose them as standard REST APIs through the HTTP gateway. Compared with Cloud Run, web cloud functions have clear advantages in the Singapore scenario:

  • Zero ops, no container management: no image builds, no instance specs — upload code and it runs;
  • Pay-as-you-go, zero idle cost: billed by call count + resource usage time, no charge when there are no requests, no reserved instances needed to avoid cold starts;
  • Easier autoscaling: the platform scales by concurrency automatically, and pre-provisioned concurrency further reduces cold-start impact;
  • Seamless PG integration: cloud functions read/write the same environment's PostgreSQL directly and reuse the RLS permission system — no extra network wiring for data validation, third-party integration or scheduled jobs.

Note: if your business depends on long connections (WebSocket/SSE), persistent processes or full web-framework routing middleware, cloud functions aren't a complete Cloud Run replacement — watch for Cloud Run's future Singapore opening for those cases.

Closing

Going overseas no longer requires building a whole overseas infrastructure before you start. Pick a region, go through the familiar purchase flow, and a few minutes later you have a ready-to-use serverless PostgreSQL backend deployed in Singapore.

If your business is reaching (or already reaching) Southeast Asian users, now is a good time — check the Singapore region in the console, click "Read more" for the purchase page, and create your first table.

Learn more:

Build your next app on CloudBase

An all-in-one backend covering database, cloud functions, static hosting, and AI capabilities.