Your sales dashboard shows a sudden spike at 02:00 UTC. One client launched a data export that swept through a 10 GB table, locking rows for hours. Within minutes the WordPress sites of three unrelated customers start returning 502 errors. The culprit? A single shared database instance choked by a runaway query, and every site on the server was waiting on it.
That scenario is common on many low-cost shared-hosting plans. They run one MySQL or PostgreSQL server that houses every customer's tables, separated only by usernames and passwords. When one tenant sends a heavy query, a massive transaction, or accidentally triggers a lock, the whole machine feels the pressure. CPU, memory, and disk I/O are all drawn into the same process pool, so the impact spreads like a ripple.
At TrueCore we built a different model. Every Ember, Blaze, and Inferno account receives its own PostgreSQL 16 instance, isolated at the process level by our flame-bubble container system. The isolation is not just logical; it is enforced by the kernel. Each database runs in its own cgroup with hard limits on memory and CPU, just like we described in our Kernel-Enforced Limits post. The result is that a misbehaving query stays inside the offending customer's boundary and never touches anyone else.
The Problem with Shared-DB Hosting
A typical shared-DB stack looks like this:
- One PostgreSQL service listening on
127.0.0.1:5432. - All customers connect using credentials stored in the same
pg_hba.conf. - Connection pools, buffer caches, and temporary file directories are common to every user.
When a query scans an entire table, PostgreSQL allocates buffers, consumes CPU cycles, and writes temporary files. If the query runs for minutes, every other connection waits for locks or for I/O bandwidth. A large INSERT ... SELECT or a badly indexed JOIN can fill the shared buffer cache, evicting pages that other sites rely on. In extreme cases the database process exceeds its memory limit, the kernel kills it, and the whole server restarts. All sites go down, even those that never touched the database.
Because the limit is soft in most hosts, the overshoot is often only noticed after the damage is done. Alerts come too late, and the hosting provider has to scramble to reboot the machine, losing minutes of uptime for every customer.
TrueCore's Per-Customer PostgreSQL Isolation
Our approach puts each customer in a separate bubble. When you sign up for Ember (£20 / mo), you get a dedicated PostgreSQL 16 instance at an internal address like 10.88.0.1:5432. The address is reachable only from your own container, never from the public internet. The credentials appear under the Database tab in the portal.
Connecting is the same as on any standard host:
# psql from your SSH shell
PGHOST=10.88.0.1 PGPORT=5432 PGUSER=your_user PGPASSWORD=your_password psql -d your_dbBecause the database lives in its own cgroup, the kernel enforces limits on RAM, CPU and I/O. If your process tries to allocate more memory than the plan allows, the kernel kills it instantly. Other customers' cgroups are untouched. This mirrors the behaviour we explained in Kernel-Enforced Limits - the hard caps protect the whole server, not just the offending account.
Isolation also simplifies security. Even if a password is compromised, the attacker can only reach the tables belonging to that account. There are no other customers' schemas in the same instance, so the breach cannot spread laterally.
Cost vs Value: Why the Slightly Higher Price Pays Off
The Flameling plan (£10 / mo) offers static sites only - no PHP runtime, no database. If you need dynamic content, Ember is the next step at £20 / mo and includes the per-customer PostgreSQL. The price difference is £10 per month, or about £120 per year.
Consider the potential loss from a shared-DB outage:
- Lost sales during a two-hour downtime can easily exceed £200 for a small e-commerce site.
- Customer trust erodes; a single incident may cause churn that costs more than the annual price difference.
- Manual recovery—restoring a corrupted database from backups, re-running migrations—can take hours of developer time.
Paying an extra £10 a month buys you:
- Predictable performance - your queries never compete with strangers.
- Clear security boundaries - a compromised password does not expose others.
- Simpler troubleshooting - the database logs belong only to you, no noisy entries from other accounts.
- Peace of mind - you know the platform enforces hard limits, so a runaway script cannot take down the whole server.
In practice, most customers see no noticeable performance penalty from the isolation. The container overhead is tiny; PostgreSQL runs natively inside the bubble, using the same kernel version (6.18.x) and Alpine Linux 3.23.4 as the rest of the fleet.
What You See in the Portal
The TrueCore control panel lists your database under Add-ons → Databases. Clicking the entry shows:
- Host:
10.88.0.1 - Port:
5432 - Database name, user, and a one-click password reset button
- Backup interval (12-hourly for Ember, 6-hourly for Blaze, 30-min for Inferno)
Backups are taken with restic and stored encrypted in Backblaze B2. You can download a dump at any time, or restore from the portal if needed. Because the database is per-customer, the restore process touches only your container - other accounts remain online.
Bottom Line
Shared-DB hosting may look cheap, but the hidden cost is the risk of one tenant's bad query taking down everyone. TrueCore's per-customer PostgreSQL isolation, combined with kernel-enforced resource limits, contains that risk at the process level. The modest price increase from Flameling to Ember buys you performance stability, security confidence, and a clear recovery path. For any site that runs PHP, WordPress, or a custom app, that trade-off is worth the extra £10 per month.
If you're still on a plan that shares a single database server, consider upgrading to Ember or higher. Your site will run faster, safer, and with fewer surprises when traffic spikes or a script misbehaves.