Managed Postgres, Redis and more in São Paulo: dedicated servers for Brazil
Layerbase dedicated servers can now be placed in South America (São Paulo). If your app runs in Brasil, or your users are there, you can put the database on the same continent as the traffic instead of paying for a trip to Virginia on every query.
This post covers what the Brazil option actually is, what it costs, how to buy one, and where the honest limits are.
Contents
- Why the region matters
- What you get
- What the transfer allowance means
- Setting one up
- What runs on it
- Data residency, stated plainly
- What Brazil does not get
- FAQ
Why the region matters
Two reasons, and only one of them is about speed.
The first is physics. An app server in São Paulo talking to a database in São Paulo is a same-metro round trip: single-digit milliseconds, near enough to free that you stop thinking about it. The same app server talking to a database in US East is a cross-continent round trip, typically over 100 ms, and every query pays it. That is fine for one query. It is not fine for a page load, because a page load is rarely one query. An ORM rendering a list will run five or ten in sequence, and a checkout with a transaction, a couple of lookups and a write can run twenty. Multiply and you get seconds of wall time that no amount of CPU on either end can give back.
Caching hides some of it on reads and none of it on writes, and it adds a second system you now have to keep correct. Connection pooling helps with connection setup, not with per-query latency. The only real fix is to move the database closer, which is why the region question comes before the provider question.
The second reason is where the bytes sit. Plenty of teams have a customer, an auditor, or an internal policy that asks where the data physically lives, and "a machine in Virginia" is not the answer they want. A server in São Paulo is a machine in São Paulo. We say exactly what that covers further down, including the part it does not cover.
What you get
A dedicated server is a single-tenant virtual machine that runs only your databases. Nobody else has a workload on it. It is billed at one flat monthly price, always on, and never hibernated or paused.
Three sizes are sold in São Paulo:
| Size | vCPU | RAM | Disk | Outbound transfer | Price |
|---|---|---|---|---|---|
| Dedicated 4GB | 2 | 4 GB | 100 GB NVMe | 5 TB per month | $45/mo |
| Dedicated 8GB | 4 | 8 GB | 180 GB NVMe | 6 TB per month | $95/mo |
| Dedicated 16GB | 2 | 16 GB | 100 GB NVMe | 6 TB per month | $155/mo |
The 16GB size trades cores for memory on purpose. It is the one to pick when the working set is what hurts: a Postgres database whose indexes you want resident, a large Redis or Valkey keyspace, a vector index you would rather not page off disk.
What comes with the box, regardless of size:
- No database cap. Run as many databases as fit the memory and the disk. There is no per-database fee and no branch cap on your own server.
- Every Layerbase Cloud engine. All 18 engines, on the same machine, from the same dashboard.
- Client certificates (mTLS) on Postgres, if you want connections authenticated by certificate rather than password alone.
- Hourly backups with 30-day rolling retention, per database, with a lighter schedule available per database if hourly is more than you need.
- One bill. The server is a line on your existing Layerbase subscription, not a second invoice.
What the transfer allowance means
Our US servers run on hardware where outbound transfer is not metered, so the copy for those says exactly that: no bandwidth metering. The São Paulo machines are a different product line and their transfer is metered, so each size carries a stated monthly allowance, listed in the table above.
For a normal database workload this is a number you will never look at. Query responses are small, and 5 TB a month is a lot of rows. The cases that get close are the ones where the database is also the delivery path: continuous full dumps out of the region, an analytics store feeding a public dashboard, a search index serving a high-traffic front end directly.
We do not publish an overage price, because we would rather size the plan correctly than surprise you with a line item. If you expect to go over, contact us and we will size a plan for you.
Setting one up
- Go to the dedicated servers page or the Dedicated servers section of your plan page in the dashboard.
- Pick Brazil on the location picker. The size list changes to the three São Paulo sizes and their prices.
- Pick a size and pay. The server is added to your existing subscription and charged today.
- Wait. The build is automatic, with no ticket and no email thread, and is usually ready in about 30 minutes. A banner shows in the dashboard while it runs, and we email you when the machine is live.
- Create databases on it. In the normal create flow, a server picker lets you place the new database on your box. Everything after that is an ordinary Layerbase database: connection strings, the query console, backups, and branching all behave the same way they do on the shared cloud.
Engine binaries download to the server the first time you create a database of that type, so there is nothing to install up front.
What runs on it
Everything in the Layerbase Cloud catalog, which is the actual point of a single-tenant box. The stack we see most often on one machine is unremarkable and that is the recommendation: Postgres for the application data, Redis or Valkey for sessions and queues, Meilisearch for the search box. Three engines, one server, one price, one dashboard, and all three in the same building as your app.
Past that, the same box will happily run ClickHouse or QuestDB for analytics, Qdrant for vector search, CouchDB, MySQL or MariaDB, FerretDB when you want the MongoDB wire protocol, TigerBeetle for a ledger. Nothing about the engine list changes because the server is in Brazil.
The practical constraint is the box, not the plan. Memory and disk are what you are buying, and a 4 GB machine running Postgres plus Redis plus a search index is a real 4 GB machine with three things on it. Size for the working set, not for the row count.
Data residency, stated plainly
The database runs on that machine in São Paulo. The files on disk are there, the process is there, and queries are served from there.
Backups are the exception and we are not going to bury it: they go to Cloudflare R2, which is global object storage and may store data outside the region. We do not offer a contractual data residency guarantee, in Brazil or anywhere else, and we are not going to claim LGPD compliance on your behalf. What we will tell you is precisely where things sit, which is the data residency page, kept current.
If your requirement is a signed commitment that every byte including backups stays in country, say so before you buy. That is a conversation, not a checkbox on a pricing page.
What Brazil does not get
Four things, listed because finding them out after you pay is worse.
Shared plans are still United States only. Free, Solo and Pro all run in US East, and there is no region choice on the shared fleet. Brazil exists on dedicated servers and nowhere else today. If you need a database in São Paulo, a dedicated server is the way to get one.
No prepaid terms. US dedicated servers can be prepaid for a stretch of months at a discount. The São Paulo sizes bill monthly only right now.
Backups leave the region. Covered above, and it is the honest asterisk on the residency story.
No Europe, no Asia. Brazil is the first location we have added outside the United States. It is not the start of an announced rollout with dates we would then miss. If your users are in Asia or the Middle East and what you need is Postgres, we wrote up who we would send you to instead.
FAQ
Is the database really in Brazil?
Yes. The machine is in São Paulo and the database runs on it. Backups are stored in Cloudflare R2, which is global and may keep copies outside the region, and we do not offer a contractual residency guarantee. See the data residency page for the full footprint.
Can a Free account buy one?
Yes. A dedicated server is separate from the shared plans, so you do not need to upgrade first. Buying one starts a Custom plan that covers the server. If you also want the shared cloud and pool blocks, Pro is $15 per month and runs alongside it on the same bill.
Is there a São Paulo shared plan?
No. Shared plans run in the United States with no region choice. The dedicated server is the only way to get a Layerbase database in Brazil today.
Which engines can I run in São Paulo?
All of them. Every engine in the Layerbase Cloud catalog is available on a dedicated server, and there is no cap on how many databases you run on your own box beyond its memory and disk.
How long does it take to get one?
About 30 minutes for a São Paulo server, built automatically. You do not have to do anything while it builds, and we email you when it is live.
Ask for the next one
We added Brazil because people asked for Brazil, repeatedly and specifically, and we could build it properly rather than announce it. That is the whole mechanism.
If the region you need is not on the list, email ops@layerbase.com and tell us where and what for. We would rather hear a real request than guess at a map. The dedicated servers page has the current catalog, and the docs cover provisioning, placement, and what happens when you cancel.
Keep reading
- Fly.io is raising Machine memory prices 20% on October 1Fly emailed customers that Fly Machines memory prices rise 20% on October 1, 2026. CPU stays the same, and Sprites get cheaper. Here is what that does to a Postgres cluster, and how to move the database without moving the app.
- Aiven vs Vercel Postgres: a decision guideVercel Postgres is not a product anymore, so this is really Aiven versus a Neon project bought through the Vercel Marketplace. Which one fits, what each costs as of September 2026, and the questions to put in front of a proof of concept before anyone signs.
- Keep Neon-style branching, drop the compute meterThe reason people pick Neon is branching. The reason they leave is the bill that arrives once branching becomes a habit: a compute meter per branch, a branch-month past the included ten, and the arithmetic before every pull request. Here is what a branch-per-PR workflow costs on a meter, what the same workflow looks like inside a flat plan, and the honest list of what Neon still does better.
- Hosting Postgres in Asia and the Middle EastLayerbase runs in the United States and Brazil, and neither one is near Asia. If your users are in Asia or the Middle East and what you need is Postgres, put the database near them. We recommend Nearbase for that, and here is how the two products split the work.