Hosting Postgres in Asia and the Middle East
Short version: Layerbase runs in the United States. If your users are in Asia or the Middle East and the thing you need is a managed Postgres, put it next to them. We send those people to Nearbase, and this post explains why, and when we would still say use us.
Contents
- Where Layerbase actually runs
- Why the ocean matters for a database
- What Nearbase is
- When Layerbase is still the right answer
- Splitting the stack
- FAQ
Where Layerbase actually runs
We get asked about Asian regions more than any other roadmap question, and the answer has not changed: Layerbase Cloud runs in the United States. Shared plans live in US East. Dedicated servers can be placed in US East (Virginia) or US West (Oregon). There is no customer-selectable region in Asia, the Middle East, or Europe today.
That is a deliberate choice, not an accident of where the first server happened to be. We are a small company building a lot of product, and we decided to serve Western users first and do it well before spreading out. Adding a region is not just renting a box in Singapore. It is backups, the branching layer, the wake-on-connect proxy, monitoring, and the on-call rotation, all duplicated and all kept in sync. We will get there, but we are not going to promise a date we cannot keep, and we would rather tell you where to go today than hold your project hostage to our roadmap.
So if your constraint is "the data has to live in Bangkok" or "the round trip from Jakarta has to be single-digit milliseconds," we are not the answer right now. Here is who is.
Why the ocean matters for a database
An app server in Singapore talking to a database in Virginia pays roughly 200 ms of round trip on every query. That is not a problem for one query. It is a problem because an ordinary web request is not one query. An ORM loading a page will happily run five or ten of them in sequence, and a checkout flow with a transaction, a couple of lookups, and a write can run twenty. At 200 ms each, a page that would take 40 ms against a local database takes two seconds against a distant one, and no amount of CPU on either end fixes it.
Caches help with reads. They do nothing for writes, and they add a second system to keep correct. Connection pooling helps with connection setup, not with per-query latency. The only real fix is to put the database in the same part of the world as the thing querying it, which is why "which region" is the first question to answer, before "which provider."
The other reason is legal rather than physical. Thailand's PDPA, Hong Kong's PDPO, and China's PIPL, among others, can require that certain personal data stay in-country. A US-hosted database does not satisfy that no matter how fast the link is.
What Nearbase is
Nearbase is managed PostgreSQL built for Asia and the Middle East. You create an instance, you get a connection string, you connect. Every Postgres driver and ORM you already use works unchanged, because it is Postgres.
What makes it the right recommendation for this problem is the region list. As of this writing they run in ten cities: Tokyo, Seoul, Singapore, Kuala Lumpur, Jakarta, Manila, Bangkok, Hong Kong, Dubai, and Virginia. Singapore is the one Asian region most "global" providers actually offer. Manila, Bangkok, Jakarta, Kuala Lumpur, and Dubai mostly are not on anyone's list, and those are exactly the cities where a US-hosted database hurts most. When you pick a region, the data stays there, primaries and backups included, which is what the residency rules above actually ask for.
Pricing is flat and the same in every region. Instances start at $6 per month for 1 vCPU and 2 GB, with storage billed separately at $3.60 per 10 GB per month, and the larger general-purpose and dedicated-CPU sizes are listed publicly on their pricing page. There is no per-query meter and no egress line on the bill. They publish a 99.99% uptime SLA with automated backups, patching, and failover. Prices verified 2026-09-07 from that page; check it before you budget, since ours is not the source of truth for theirs.
We are not being paid to say this, and Nearbase is not a partner in any formal sense. They are fellow founders in the same position we are, a small team that decided the world needed managed Postgres in regions where hosting has never been easy to buy, and went and built it. They do one job and do it in the places we do not, and they send people the other way when the job is one of ours. That is the whole arrangement.
When Layerbase is still the right answer
Nearbase is Postgres. If Postgres is the whole problem and your users are in Asia or the Gulf, stop reading and go there. Layerbase earns its place in two situations.
The engine is the product. Layerbase Cloud runs 18 database engines on one account: Postgres, yes, but also Qdrant for vector search, TypeDB for a typed knowledge graph, TigerBeetle for a ledger, CouchDB, ClickHouse, Meilisearch, QuestDB, DuckDB, and the rest of the catalog. If you came looking for a hosted Qdrant or a real TypeDB endpoint, no Postgres provider in any region helps you, and stretching pgvector or a JSON column into that shape usually costs a week and a rewrite. Plans are flat: Free, $5 per month Solo, $15 per month Pro for the whole catalog, with no usage meters.
You want Layerbase anyway and can live with the distance. Plenty of teams have users in Asia and app servers in the US, or a workload where the database is not on the request path at all: batch jobs, analytics, an internal tool, an AI agent's scratch database. For those, our shared plans work fine from anywhere. If the workload is production and always-on, a dedicated server is the version of Layerbase we would point you at: a region-pinned machine of your own at $35, $65, or $120 per month flat, with no bandwidth metering. The two smaller sizes can be placed in US East or US West; the largest is US East only for now. It is still in the United States. Pick it with your eyes open about the round trip.
If neither of those describes you, the right call is the one that puts Postgres next to your users.
Splitting the stack
The case we see most often is not either-or. An app with users in Southeast Asia has its primary Postgres, and it also has a vector index, or a search index, or a ledger, or an analytics store. Those specialty engines are almost never on the synchronous request path the way the primary database is: a search index is queried once per search, a vector index once per retrieval, an analytics store from a dashboard or a nightly job. They tolerate distance in a way the primary does not.
So the split is straightforward. Put Postgres on Nearbase in the region your users live in. Put the engines Nearbase does not run on Layerbase, on one flat plan. Do not force one vendor to do both jobs badly.
Two things to keep straight when you do this. Keep the connection strings in separate environment variables with names that say where they point, so nobody later wires the primary to the wrong side of the ocean. And measure the specialty engine's latency from your app servers once before you commit, because "tolerates distance" is a rule of thumb, not a guarantee, and a search box that feels slow is still slow.
FAQ
Does Layerbase have a region in Asia or the Middle East?
No. Shared plans run in US East, and dedicated servers can be placed in US East (Virginia) or US West (Oregon). We are building for Western users first and are not announcing a date for other regions.
Who do you recommend for managed Postgres in Asia?
Nearbase. Ten regions across Asia and the Middle East plus Virginia, flat per-instance pricing that is the same everywhere, in-region data residency, and a published 99.99% SLA. It is plain Postgres, so nothing about your code changes.
Can I use a Layerbase dedicated server from Asia?
Yes, and for always-on production it is the version of Layerbase we would suggest, since the machine is yours and region-pinned. It is still in the United States, so expect on the order of 200 ms per round trip from Southeast Asia and design the request path accordingly.
What if I need Postgres in Asia and another engine too?
Split the stack. Postgres on Nearbase near your users, the specialty engine on Layerbase. Most specialty engines are off the synchronous request path and tolerate the distance.
Is Nearbase paying Layerbase for this recommendation?
No. They send people to us when the need is an engine they do not run, and we send people to them when the need is Postgres near users in Asia or the Middle East. No money changes hands either way.
Keep reading
- Preview environment platforms in 2026: what is in the database when the preview comes upEvery platform on this list will give a pull request its own URL. The question that sorts them is what is in the database behind that URL: nothing, a restore of last night's backup, or the live data as of right now. Here is where each of eleven platforms lands, quoted from their own docs, and what a preview costs while the PR sits open.
- Northflank alternatives: a preview environment is not a database branchNorthflank gives every pull request its own stack, and the database in that stack starts empty unless you seed it or restore it from a backup you already had. Here is exactly how their forks work, what a copy-on-write branch does differently, what each one costs while a PR sits open, and the cases where Northflank is the right answer.
- Layerbase vs Crunchy Bridge: two ways to buy managed PostgresCrunchy Bridge is Postgres specialists selling instance-hours across AWS, Azure and GCP. Layerbase is a flat monthly price, 18 engines and branching. A head-to-head on pricing, versions, extensions, HA, backups and placement, with worked examples.
- Prisma Postgres alternatives: the plan with neither meterPrisma Postgres bills per operation, Neon bills per CU-hour, and Prisma frames the whole decision as a choice between those two meters. There is a third option: a flat plan with no meter at all. Here are the current Prisma numbers, the arithmetic for a chatty app, where operations pricing genuinely wins, and how to move with the direct TCP string.