Shared Database Services: One MySQL for Multiple Apps

The problem shared services solve

A bundled app template gives each app its own database container. That's simple and isolated, but on a small VPS, three apps each running their own MySQL is three sets of buffer pools competing for the same limited RAM — most of it doing nothing most of the time.

Creating a shared service

neo service create mysql main-db

Runs one MySQL instance (svc-main-db), independent of any single app's lifecycle.

Linking an app to it

neo service link main-db my-app

Creates a dedicated database and user inside that MySQL instance for my-app, and injects DATABASE_URL / DB_* environment variables into the app automatically — the app gets its own credentials and its own database, just inside a shared server process rather than a dedicated one.

neo service link main-db another-app

A second app links to the same instance, gets its own separate database and user, and neither app can see the other's data — isolation at the database/user level, not at the container level.

Managing the service

neo service info main-db      # connection details, including the password
neo service list              # every shared service and which apps link to it
neo service unlink main-db my-app   # removes the injected env vars, keeps the data
neo service remove main-db    # blocked while any app is still linked

When to use bundled vs. shared

A template's bundled database is the right default for a single small app, or during evaluation. Once you're running several apps on one server and RAM is the constraint, migrating to a shared service — or starting new apps linked to one from day one — is the difference between three half-idle databases and one properly-utilized one.