How to Manage Multiple Databases Locally

Your main app uses PostgreSQL. Caching runs through Redis. The new search feature needs Qdrant for vector embeddings. Someone on the team added ClickHouse for analytics dashboards. That's four database engines, each with its own install process, its own configuration format, its own default port, its own way of starting and stopping. And that's just one project.

Now add a second project. This one uses MongoDB and DuckDB. Different engines, different ports, different data directories. You're keeping track of six databases across two projects, and half of them conflict with each other if you're not careful.

This gets out of hand fast. Here's how to keep it simple.

The Problem: Every Engine Is Different
One CLI for All of Them
Project Isolation
The Onboarding Scenario
Managing Everything at Once
Layerbase Desktop: A GUI Alternative
Layerbase Cloud: Skip Local Entirely

The Problem: Every Engine Is Different

Each database has its own way of doing things.

PostgreSQL via Homebrew on macOS? It auto-starts as a LaunchAgent and runs under your system user. The config file lives in /opt/homebrew/var/postgresql@16/. You manage it with brew services start postgresql@16 and stop it with brew services stop postgresql@16. Except sometimes the LaunchAgent goes stale and you have to manually unload it.

Redis? You could use Homebrew for that too, but plenty of people run it through Docker because the Homebrew formula has its own quirks. Now you need Docker Desktop running in the background. That's a Linux VM consuming a few gigs of RAM just to run a key-value store.

Qdrant for vector search? There's no Homebrew formula. You download a binary from GitHub, make it executable, figure out where to put the config, create a data directory, and write a shell alias so you don't have to type the full path every time you start it.

ClickHouse? Another binary download. Or a Docker image. Or maybe Homebrew has it now. The install instructions differ depending on which blog post you found.

Each one has its own update process. Some auto-update (Homebrew). Some you have to manually re-download. Some you forget about for six months and suddenly you're four major versions behind.

Each one stores data in a different location. PostgreSQL in /opt/homebrew/var/, Redis in /usr/local/var/, Qdrant wherever you told it to, ClickHouse in yet another place. Want to wipe everything and start fresh? Good luck remembering where all the data directories are.

Each one starts and stops differently. brew services, docker compose, direct binary execution, systemd on Linux. There's no single command that shows you what's running and what isn't.

One CLI for All of Them

SpinDB manages all of these engines through one interface. Install it, create a named instance for each database you need, and SpinDB handles the binary download, data directory, port assignment, and lifecycle for every engine the same way.

Install SpinDB:

bash

npm i -g spindb    # npm
pnpm add -g spindb # pnpm

Now let's set up the stack from the intro: PostgreSQL, Redis, Qdrant, and ClickHouse.

bash

spindb create app-pg -e postgresql --start
spindb create app-redis -e redis --start
spindb create app-qdrant -e qdrant --start
spindb create app-ch -e clickhouse --start

Four commands. Four databases running. SpinDB downloads the binary for each engine (cached after the first time), creates an isolated data directory per instance, picks the right default port, and starts the process. No Homebrew, no Docker, no manual binary downloads.

Check what's running:

bash

spindb list

text

app-pg       postgresql   running   postgresql://127.0.0.1:5432/app-pg
app-redis    redis        running   redis://127.0.0.1:6379
app-qdrant   qdrant       running   http://127.0.0.1:6333
app-ch       clickhouse   running   clickhouse://127.0.0.1:9000

One view of everything. Engine, status, connection URL. No hunting through brew services list and docker ps and ps aux | grep qdrant to figure out what's running.

Get the connection URL for any instance:

bash

spindb url app-pg

text

postgresql://127.0.0.1:5432/app-pg

Drop into the native CLI for any instance:

bash

spindb connect app-pg      # opens psql
spindb connect app-redis   # opens redis-cli
spindb connect app-ch      # opens clickhouse-client

SpinDB bundles the CLI tools with the engine binary, so you don't need to install psql or redis-cli separately.

Stop everything when you're done for the day:

bash

spindb stop app-pg
spindb stop app-redis
spindb stop app-qdrant
spindb stop app-ch

Start them again tomorrow:

bash

spindb start app-pg
spindb start app-redis
spindb start app-qdrant
spindb start app-ch

Data persists between stops and starts. Each instance has its own data directory managed by SpinDB.

Project Isolation

Here's where things get interesting. Most developers work on more than one project, and those projects often use different databases. Without isolation, you end up with one PostgreSQL instance shared across everything, a Redis server with keys from three different apps mixed together, and port conflicts when two projects want the same engine on the same port.

SpinDB's named instances solve this naturally. Each instance is independent: its own data directory, its own port, its own lifecycle.

Say you have two projects. Your main web app uses PostgreSQL, Redis, and Qdrant. A data analysis side project uses MongoDB and DuckDB.

Set up the web app:

bash

spindb create webapp-pg -e postgresql --start
spindb create webapp-redis -e redis --start
spindb create webapp-qdrant -e qdrant --start

Set up the analysis project:

bash

spindb create analysis-mongo -e mongodb --start
spindb create analysis-duck -e duckdb --start

Five database instances across two projects. No conflicts. Each PostgreSQL instance has its own cluster, its own port (SpinDB auto-assigns if the default port is already taken), and its own data. The MongoDB instance doesn't know or care about the PostgreSQL instances.

bash

spindb list

text

webapp-pg       postgresql   running   postgresql://127.0.0.1:5432/webapp-pg
webapp-redis    redis        running   redis://127.0.0.1:6379
webapp-qdrant   qdrant       running   http://127.0.0.1:6333
analysis-mongo  mongodb      running   mongodb://127.0.0.1:27017
analysis-duck   duckdb       running   postgresql://127.0.0.1:5433/analysis-duck

Notice analysis-duck got port 5433 because 5432 is already taken by the PostgreSQL instance. SpinDB handles this automatically.

Working on the web app today? Start just those instances:

bash

spindb start webapp-pg webapp-redis webapp-qdrant

Switching to the analysis project? Stop the web app databases and start the analysis ones:

bash

spindb stop webapp-pg webapp-redis webapp-qdrant
spindb start analysis-mongo analysis-duck

Each project's databases are named in a way that makes them obvious. No guessing which PostgreSQL instance belongs to which project.

The Onboarding Scenario

This is where the multi-engine management really pays off. A new developer joins your team. They need to get the project running locally. Here's the difference.

The Traditional Approach

Install Docker Desktop (500 MB download, requires admin access, restart might be needed)
Clone the repo
Read the README section about local setup
Run docker compose up -d
Wait for four Docker images to download (potentially several GB on a fresh machine)
Discover that port 5432 is already in use because they have a Homebrew PostgreSQL installation from a previous job
Stop the Homebrew service, or edit the docker-compose.yml to use a different port
Run docker compose up -d again
Set up the .env file with the right connection URLs
Hope the volume mounts work on their OS

The SpinDB Approach

Clone the repo
Run three commands:

bash

npm i -g spindb
spindb create webapp-pg -e postgresql --start
spindb create webapp-redis -e redis --start
spindb create webapp-qdrant -e qdrant --start

Grab connection URLs:

bash

spindb url webapp-pg     # postgresql://127.0.0.1:5432/webapp-pg
spindb url webapp-redis  # redis://127.0.0.1:6379
spindb url webapp-qdrant # http://127.0.0.1:6333

Paste them into .env
Start building

No Docker Desktop. No image downloads. No port conflicts (SpinDB auto-assigns). No volume mount issues. The databases are running as native processes on their machine, using only the memory that each engine actually needs.

If the new developer already has something on port 5432, SpinDB picks another port and tells them. They use spindb url webapp-pg to get the actual URL, put it in their .env, and move on. No debugging, no editing compose files.

Managing Everything at Once

Here are the commands you'll use daily.

See all instances:

bash

spindb list

Start everything for a project:

bash

spindb start webapp-pg webapp-redis webapp-qdrant

Stop everything for a project:

bash

spindb stop webapp-pg webapp-redis webapp-qdrant

Get a connection URL to paste into your app config:

bash

spindb url webapp-pg

Open a database shell to poke around:

bash

spindb connect webapp-pg

Remove an instance you don't need anymore:

bash

spindb destroy analysis-duck

The commands are the same regardless of the engine. spindb stop works the same for PostgreSQL, Redis, MongoDB, ClickHouse, Qdrant, and every other supported engine. You don't need to remember that PostgreSQL uses pg_ctl stop while Redis uses redis-cli shutdown while ClickHouse uses clickhouse-server stop. It's just spindb stop <name>.

SpinDB supports 20+ database engines, including PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Valkey, ClickHouse, DuckDB, SQLite, Qdrant, Meilisearch, SurrealDB, CouchDB, InfluxDB, QuestDB, CockroachDB, Weaviate, FerretDB, and more.

Layerbase Desktop: A GUI Alternative

If you prefer a graphical interface, Layerbase Desktop wraps SpinDB in a macOS app. Create instances, start and stop them, view connection details, and manage everything visually. Same engines, same native binaries under the hood, just with buttons instead of commands.

Layerbase Cloud: Skip Local Entirely

Sometimes local isn't what you want. Maybe you're pairing with a remote colleague and you both need the same database. Maybe you're on a machine where you can't install things. Maybe you just don't want to manage anything.

Layerbase Cloud gives you managed database instances for many of the same engines SpinDB supports. Create an instance, grab the connection URL from Quick Connect, and point your app at it. TLS, backups, and infrastructure are handled for you.

Your application code stays the same. Swap the localhost URL for the cloud URL.

Wrapping Up

Managing multiple databases locally doesn't have to mean juggling Homebrew, Docker, and manual binary downloads. SpinDB gives you one tool that handles every engine the same way: create, start, stop, connect, done.

Install it and try it:

bash

npm i -g spindb
spindb create mydb -e postgresql --start
spindb url mydb

For the full list of supported engines and docs, see layerbase.com/spindb.

How to Manage Multiple Databases Locally

Contents

The Problem: Every Engine Is Different

One CLI for All of Them

Project Isolation

The Onboarding Scenario

The Traditional Approach

The SpinDB Approach

Managing Everything at Once

Layerbase Desktop: A GUI Alternative

Layerbase Cloud: Skip Local Entirely

Wrapping Up

Something not working?