Data hosting is not one product - it is four, and picking the wrong one is how teams end up storing images in a database, running analytics against production, or keeping the only copy of anything on a single server’s disk.
The term is vague enough that search results for it range from game servers to big-data warehousing. That vagueness is the actual problem: people go looking for somewhere to put their data without first deciding what shape it is. Sort the data first and the hosting decision mostly makes itself.
Table of contents
- Four shapes of data, four different services
- Managed versus self-managed, honestly
- The three rules that prevent most data incidents
- Sovereignty, latency, and the boring constraints
- A default that works for most applications
- How this fits the rest of the stack
- FAQ
Four shapes of data, four different services
- Relational records. Users, orders, posts, sessions - things with relationships and constraints. This belongs in a managed relational database, Postgres or MySQL, and almost nothing else is a good answer.
- Files and blobs. Images, PDFs, video, user uploads, generated exports. These belong in object storage or attached persistent storage, never in a database column.
- Analytical history. Events, logs, metrics, anything you aggregate rather than fetch by id. This belongs in a warehouse or a time-series store, separate from the database serving your application.
- Ephemeral state. Caches, session tokens, rate-limit counters, job queues. This belongs in memory or a purpose-built store, and losing it should be survivable by design.
Most data problems in small applications are one of these four living in the wrong place. The classic is base64-encoding an image into a text column, which works fine until the table is forty gigabytes and every backup takes an hour.
Managed versus self-managed, honestly
Running your own database on a VM is cheaper per gigabyte and more expensive per hour. The instance cost is visible; the work is not.
The work is: initial tuning, connection limits, major version upgrades, replication if you want it, monitoring that alerts before disk fills rather than after, and backups. Backups specifically deserve their own sentence, because almost everyone sets them up and almost nobody tests a restore. An untested backup is a belief, not a backup.
A managed instance hands you connection limits, automated backups, private networking, and user management as configuration rather than as projects. You give up kernel-level tuning and unusual extensions. For the overwhelming majority of applications that is a good trade, and the ones for whom it is not usually know exactly why.
The decision point is not size. It is whether anyone on the team wants the job of being the database administrator, and whether they will still want it in a year.
The three rules that prevent most data incidents
- Never keep the only copy anywhere. Not on the application server’s disk, not in a single database with no backup, not in one region if the data would be expensive to lose. This is the whole discipline in one sentence.
- Keep files out of the database. Store the file in object storage and the reference in the database. This keeps backups fast, keeps the database small enough to restore quickly, and lets you serve files without going through the application.
- Keep analytics off the production database. A single unindexed aggregate query over a large table will happily take your application down at lunchtime. Replicate or export, then query the copy.
There is a fourth rule that matters more than any of them and is harder to write as a rule: know where every category of your data lives, right now, from memory. Teams that cannot answer that in one breath usually have a copy of something important somewhere nobody is backing up.
Sovereignty, latency, and the boring constraints
Two constraints override everything above and are worth checking before you design anything.
The first is where the data is legally allowed to live. If you handle personal data for users in a jurisdiction with residency rules, the region is not a performance decision, it is a compliance one, and it is not something you can retrofit cheaply.
The second is latency between the application and the database. These two should be close together - ideally on a private network in the same region. A database in one region serving an application in another adds a round trip to every query, and applications make far more queries per request than their authors think. This is one of the most common causes of a page that is mysteriously slow with no single slow component.
Private networking matters for security as well as speed. A managed database that is only reachable from your own services, rather than from the public internet, removes an entire category of exposure without you configuring anything.
A default that works for most applications
One managed relational database for records, with automated backups and private networking. Object storage or attached persistent storage for files, with references in the database. A separate destination for analytics if and when you actually need aggregation. Cache in memory and treat it as disposable.
That covers the overwhelming majority of applications, scales further than most teams expect, and has the useful property that every piece can be replaced independently when one of them outgrows the default.
How this fits the rest of the stack
Data hosting costs are usually the line item people estimate worst, because storage looks cheap per gigabyte and the bill is really about instance size, backups, and transfer. The RunxBuild hosting calculator separates the database, the storage, and the bandwidth so the total is visible before you commit to a shape. RunxBuild offers managed MySQL and Postgres with backups, connection limits, user management, and private networking, plus persistent storage attached to services.
Useful related references:
- Cloud Data Integration: Tools, Patterns, and When to Use Each
- Postgres Data Types: The Ones That Actually Change Your Schema
- Cloud Data Management: Lakes, Warehouses, and the Lakehouse Pattern
- Services on RunxBuild
FAQ
What is data hosting?
An umbrella term for anywhere application data lives: managed relational databases for records, object storage for files, warehouses for analytical history, and in-memory stores for ephemeral state. The term is vague enough to be unhelpful on its own - decide the shape of the data first, and the service follows.
Should I store images in a database?
No. Store the file in object storage or attached persistent storage and keep only the reference in the database. Files in database columns make backups slow, restores slower, and force every file request through your application. It works at small scale and degrades badly.
Is a managed database worth the extra cost?
For most teams, yes. The instance price is higher than a database you run on a VM, and it replaces version upgrades, connection tuning, monitoring, and - most importantly - backups you would otherwise configure once and never test. The exception is teams who need unusual extensions or kernel-level tuning.
Where should my database be relative to my application?
In the same region, ideally on a private network. Applications issue many more queries per request than people expect, so cross-region latency multiplies. A database reachable only from your own services also removes a large class of security exposure.
How do I keep analytics from slowing down my app?
Do not run aggregate queries against the database serving your application. One unindexed scan over a large table can take the whole application down. Replicate to a read copy or export to a separate analytical store, and query that instead.