Production Postgres. Nothing exotic.
Standard PostgreSQL 16, 17 or 18 on dedicated European hardware — with resources enforced by the kernel, pooled and direct endpoints, and a connection address that stays the same whatever happens underneath.
- PostgreSQL 16, 17 and 18
- Pooled and direct endpoints
- TLS on every connection
- Host
- db-8f2a41.fsn1.baltadb.net
- Port
- 25438
- Database
- app
- User
- app_owner
- Password
- ••••••••••••Reveal
These ports are this service’s own. Yours are on its Connect tab.
Example view with sample data.
What every service includes.
CPU, memory, storage and I/O reserved for your service and enforced by the kernel.
New services start on 18. Minor updates are validated first, then applied in your maintenance window.
Connection pooling for web and serverless workloads, and a direct endpoint for full session features.
Your connection address never changes, even when your service moves to new hardware.
Resources
Enforced, not advertised.
Each service runs in its own control group with a hard memory limit equal to your plan. The total across every service on a host, plus the host’s own reserve, never exceeds the memory the machine actually has — so the memory on your plan is memory you can use.
CPU has a hard ceiling per service, and a host’s allocations never add up to more CPU than it has. Your storage is a dedicated, pre-allocated volume on mirrored NVMe, so the space you bought is space that exists.
- CPU
- 4 vCPU, with a hard ceiling
- Memory
- 8 GiB, enforced by the kernel
- Storage
- 160 GiB dedicated volume on mirrored NVMe
- Connections
- 150, plus a pooled endpoint
- Databases
- 25, all included
Versions
Upgrades on your terms.
New services start on PostgreSQL 18, with 17 and 16 available for existing applications. Minor updates are validated in staging first, then applied in your service’s maintenance window.
Major upgrades are yours to start, when you’re ready. Balta runs a compatibility check, confirms your extensions exist on the new version, and takes a backup before anything changes — with a documented way back if you need it.
- Minor updates validated before they reach you
- Major upgrades only when you start them
- A backup before anything changes
- Compatibility check passed
- All 6 extensions available on PostgreSQL 18
- Backup taken before upgrade
- Rollback path documented
Example view with sample data.
Access
A real admin role.
You get a managed admin role that owns your databases, creates schemas and roles, reads every statistics view and installs extensions — without waiting for us. What you don’t get is superuser or host access, which is exactly what keeps your service isolated from everyone else’s.
Install trusted extensions yourself, in any database you own: pgvector for embeddings and AI search, pg_trgm, pgcrypto, uuid-ossp, citext, hstore, ltree, unaccent, btree_gin, btree_gist and more.
-- Trusted extensions install straight from your own role CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE EXTENSION IF NOT EXISTS citext; CREATE INDEX customers_name_trgm ON customers USING gin (name gin_trgm_ops);
Connections
Two endpoints, one service.
Every service includes a pooled endpoint — PgBouncer in transaction mode, running inside your own isolated resources — for web apps, serverless functions and anything that opens connections fast. And a direct endpoint for the features that need a full PostgreSQL session.
| Feature | Pooled | Direct |
|---|---|---|
| Queries, transactions and prepared statements | Yes | Yes |
| LISTEN / NOTIFY | No | Yes |
| Session-level advisory locks | No | Yes |
| SET outside a transaction | No | Yes |
| WITH HOLD cursors | No | Yes |
| Temporary tables across transactions | No | Yes |
| High connection churn and serverless functions | Recommended | Not recommended |
What works on each endpoint. Use the pooled endpoint by default.
Scaling
Grow when you need to.
Add storage online, with no restart and no maintenance window. Move to a larger plan whenever you’re ready: more memory and CPU take effect after a short restart at a time you choose, and if your new plan needs a bigger host, your service moves in an announced window — at the same connection address.
Before you confirm any change, your dashboard tells you exactly what it involves. Nothing is ever changed without you.
- A short restart to apply the new memory and CPU limits.
- Scheduled in your next maintenance window, or now if you choose.
- Your connection address stays the same.
Settled by the day on your next invoice.
Example view with sample data.
Four steps to a production database.
- 01Choose
Pick a location, a PostgreSQL version, a plan and how much backup history to keep.
- 02Reserve
Your CPU, memory, storage and I/O are reserved on a host before anything is built.
- 03Build
Your service gets its own operating-system user, isolated resources and storage volume.
- 04Connect
Copy your pooled or direct connection string. Your first backup is already running.
Questions about the service.
Which PostgreSQL versions can I run?
Can I use superuser?
Which endpoint should my application use?
What happens when my service moves to another host?
Early access is open. Tell us about your workload and we'll reserve your place — and help you plan the move.