Databases & services

Pinned versions.
On paths you can open.

Postgres, MySQL, MariaDB, Redis, MongoDB and Elasticsearch run as containers you version yourself, on your server, with data on host paths you can inspect and back up. They change when you change them, never on an OS timer.

Backing services

Choose the engine and the exact version.

Every service is a pinned image. No implicit “latest,” no surprise majors: the version you pick is the version that runs until you decide otherwise.

PostgreSQL

The default for most apps.

16.3 · 15.7 · 14

MySQL

Drop-in for existing stacks.

8.4 · 8.0

MariaDB

Community MySQL fork.

11.4 · 10.11

Redis

Cache, queues, sessions.

7.4 · 7.2

MongoDB

Documents, first-class.

8.0 · 7.0

Elasticsearch

Search & analytics.

9.4 · 8.19

Version lists shown are illustrative. The picker always reflects images currently offered.

/srv/sproobo/pg-main · on your box
# your data is a directory you can see ls /srv/sproobo/pg-main/data base/ pg_wal/ postgresql.conf ... # back it up with tools you already trust tar czf pg-main-$(date +%F).tgz /srv/sproobo/pg-main
Data ownership

Bind-mounted, not buried.

Service data lives on ordinary host paths, not opaque named volumes. You can list it, snapshot it, rsync it off-box and reason about exactly where every byte sits. It survives docker volume prune because it was never a hidden volume to begin with.

  • inspectableOpen the directory. It's just files.
  • portableCopy it anywhere. No lock-in, no export ritual.
  • yoursLeaving the platform never means leaving data behind.
Upgrades on your schedule

A version bump is a reviewed change, not a surprise.

Changing an engine version is a plan you approve: see the diff, apply when you're ready. Nothing upgrades itself behind an apt timer.

plan · postgres minor upgrade
~service: pg-main
-image: postgres:16.3
+image: postgres:16.4
data: /srv/sproobo/pg-main (unchanged)
The bill

Stop paying per database.

Managed databases like Supabase, Neon, PlanetScale and Upstash are each their own subscription, growing with projects, branches and storage. On Sproobo a database is a container on the server you already pay for. The tenth instance costs what the first did: nothing new.

Instances are free moves

A staging copy, a per-client database, a throwaway box for an experiment. On usage-billed platforms each one is a purchasing decision. Here it's a click, on capacity you already own.

No usage meter

No per-request pricing, no per-GB egress, no per-branch charges. Your server's disk and RAM are the only budget a database draws from.

Caps, not prices

Plan tiers cap how many services you can create (2 on Free, 10 on Pro, unlimited on Team), but no tier ever prices a database individually.

Coming from Vercel with a Neon or Supabase stack next to it? Read Sproobo vs Vercel for the full cost-model comparison, or Vercel alternatives for four options weighed side by side.

Straight answers

Common database questions.

Yes. Each service exposes a standard connection string on the server's internal network. Your app container talks to it exactly as it would to any Postgres, MySQL, MariaDB, Redis, MongoDB or Elasticsearch instance.
Because data sits on bind-mounted host paths, you can use any backup tooling you already trust: filesystem snapshots, pg_dump, rsync to another host. Nothing is locked inside a proprietary volume.
Majors are always an explicit, reviewed plan, never automatic. You see the change as a diff and apply it when you choose, with the previous data directory left intact for rollback.
No. Each service is a self-contained container with its own pinned dependencies. A host apt upgrade can't shift a database version out from under you.
Get started

Pin a database. Keep the data.