Skip to content
LayerbaseLayerbase

How to Manage Multiple Databases Locally

7 min readSpinDBDatabasesDeveloper Tools

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.

Contents

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

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

Install the Layerbase CLI:

bash
npm i -g layerbase    # npm
pnpm add -g layerbase # pnpm

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

bash
lbase create app-pg -e postgresql --start
lbase create app-redis -e redis --start
lbase create app-qdrant -e qdrant --start
lbase create app-ch -e clickhouse --start

Four commands. Four databases running. The CLI 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
lbase 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
lbase url app-pg
text
postgresql://127.0.0.1:5432/app-pg

Drop into the native CLI for any instance:

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

The Layerbase CLI 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
lbase stop app-pg
lbase stop app-redis
lbase stop app-qdrant
lbase stop app-ch

Start them again tomorrow:

bash
lbase start app-pg
lbase start app-redis
lbase start app-qdrant
lbase start app-ch

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

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.

The Layerbase CLI'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
lbase create webapp-pg -e postgresql --start
lbase create webapp-redis -e redis --start
lbase create webapp-qdrant -e qdrant --start

Set up the analysis project:

bash
lbase create analysis-mongo -e mongodb --start
lbase create analysis-duck -e duckdb --start

Five database instances across two projects. No conflicts. Each PostgreSQL instance has its own cluster, its own port (the CLI 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
lbase 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. The CLI handles this automatically.

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

bash
lbase start webapp-pg webapp-redis webapp-qdrant

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

bash
lbase stop webapp-pg webapp-redis webapp-qdrant
lbase 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

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

The Layerbase CLI Approach

  1. Clone the repo
  2. Run three commands:
bash
npm i -g layerbase
lbase create webapp-pg -e postgresql --start
lbase create webapp-redis -e redis --start
lbase create webapp-qdrant -e qdrant --start
  1. Grab connection URLs:
bash
lbase url webapp-pg     # postgresql://127.0.0.1:5432/webapp-pg
lbase url webapp-redis  # redis://127.0.0.1:6379
lbase url webapp-qdrant # http://127.0.0.1:6333
  1. Paste them into .env
  2. Start building

No Docker Desktop. No image downloads. No port conflicts (the CLI 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, the CLI picks another port and tells them. They use lbase 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
lbase list

Start everything for a project:

bash
lbase start webapp-pg webapp-redis webapp-qdrant

Stop everything for a project:

bash
lbase stop webapp-pg webapp-redis webapp-qdrant

Get a connection URL to paste into your app config:

bash
lbase url webapp-pg

Open a database shell to poke around:

bash
lbase connect webapp-pg

Remove an instance you don't need anymore:

bash
lbase destroy analysis-duck

The commands are the same regardless of the engine. lbase 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 lbase stop <name>.

The Layerbase CLI runs 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 desktop 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 the Layerbase CLI 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. The Layerbase CLI 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 layerbase
lbase create mydb -e postgresql --start
lbase url mydb

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

Keep reading