Skip to content
LayerbaseLayerbase

How to Run Databases Locally Without Docker

7 min readSpinDBDatabasesDeveloper Tools

You open a new project. You need PostgreSQL. Maybe Redis too, for caching. And a vector database because the feature spec mentions semantic search. So you write a docker-compose.yml, pull three images, wait for them to download, configure ports and volumes, troubleshoot a permissions issue on the mounted data directory, and eventually get everything running. Docker Desktop is using 4 GB of RAM in the background. Your laptop fan starts spinning. You haven't written a single line of application code yet.

I've done this hundreds of times. Docker is great for production, for CI, for shipping containers to a cluster. But for local development, it's a heavyweight solution to a lightweight problem. You don't need a Linux VM to run PostgreSQL on your Mac. You just need the binary.

There's a simpler way.

Contents

What Is the Layerbase CLI?

The Layerbase CLI (formerly SpinDB) is a command-line tool that downloads and runs database engines as native binaries. No containers, no VMs, no Docker daemon. You install it with npm, create a named instance, and the database is running. It handles port assignment, data directories, and lifecycle management for 20+ engines. (What is the Layerbase CLI?)

The key difference from Docker: the Layerbase CLI runs the actual database binary directly on your machine. PostgreSQL runs as a native process, not inside a Linux container running inside a hypervisor. Redis runs as Redis. The overhead is the overhead of the database itself, nothing more.

Install and Create Your First Database

Install the Layerbase CLI globally:

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

Now create a PostgreSQL instance:

bash
lbase create mypostgres -e postgresql --start

That's it. The Layerbase CLI downloads the PostgreSQL binary for your platform (if it hasn't already), creates a data directory, initializes the cluster, and starts the server. The whole process takes a few seconds on the first run, and is nearly instant after that because the binary is cached.

Check the connection URL:

bash
lbase url mypostgres
text
postgresql://127.0.0.1:5432/mypostgres

Let's keep going. Create a Redis instance and a Qdrant instance:

bash
lbase create myredis -e redis --start
lbase create myqdrant -e qdrant --start

Three databases, three commands, running in seconds. No YAML files. No image pulls. No waiting.

bash
lbase list
text
mypostgres   postgresql   running   postgresql://127.0.0.1:5432/mypostgres
myredis      redis        running   redis://127.0.0.1:6379
myqdrant     qdrant       running   http://127.0.0.1:6333

Each engine gets its own default port. The CLI handles port conflicts automatically if you create multiple instances of the same engine.

Docker Compose vs Layerbase CLI: Side by Side

Let's say your project needs PostgreSQL for data, Redis for caching, and Qdrant for vector search. Here's what setup looks like with each approach.

The Docker Compose Approach

Create a docker-compose.yml:

yaml
version: '3.8'

services:
  postgres:
    image: postgres:16
    ports:
      - '5432:5432'
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: postgres
      POSTGRES_DB: myapp
    volumes:
      - pgdata:/var/lib/postgresql/data

  redis:
    image: redis:7
    ports:
      - '6379:6379'
    volumes:
      - redisdata:/data

  qdrant:
    image: qdrant/qdrant:latest
    ports:
      - '6333:6333'
      - '6334:6334'
    volumes:
      - qdrantdata:/qdrant/storage

volumes:
  pgdata:
  redisdata:
  qdrantdata:

Then run it:

bash
docker compose up -d

The first time, Docker pulls all three images. That's potentially a few gigabytes of downloads depending on what's already cached. The PostgreSQL image alone is 400+ MB. Once running, Docker Desktop sits in the background consuming RAM for the VM that hosts the containers. On macOS, file system performance through the VM's volume mounts is noticeably slower than native disk access.

This works. Millions of developers use this setup every day. But it's a lot of ceremony for "I want PostgreSQL running on localhost."

The Layerbase CLI Approach

bash
lbase create mypostgres -e postgresql --start
lbase create myredis -e redis --start
lbase create myqdrant -e qdrant --start

Three commands. No configuration file. No image downloads (the Layerbase CLI's binaries are much smaller than Docker images because they're just the database, not an entire Linux userland). No background VM. The databases run as native processes, so disk I/O is native speed and memory usage is only what each database actually needs.

Your connection URLs work the same way:

bash
lbase url mypostgres  # postgresql://127.0.0.1:5432/mypostgres
lbase url myredis     # redis://127.0.0.1:6379
lbase url myqdrant    # http://127.0.0.1:6333

Same ports, same protocols, same connection strings you'd use with Docker. Your application code doesn't change at all.

Managing Your Instances

The Layerbase CLI gives you a small set of commands that cover the full lifecycle.

Stop and Start

bash
lbase stop mypostgres   # Stop PostgreSQL
lbase start mypostgres  # Start it again

Data persists between stops and starts. The CLI manages the data directory for each instance.

Get Connection Details

bash
lbase url mypostgres
text
postgresql://127.0.0.1:5432/mypostgres

Pipe this into your .env file or pass it directly to your app. The URL format matches what every driver and ORM expects.

Connect Directly

bash
lbase connect mypostgres

This drops you into the database's native CLI. For PostgreSQL, that's psql. For Redis, redis-cli. No need to install the CLI tools separately.

List All Instances

bash
lbase list

See every instance you've created, its engine, its status (running or stopped), and its connection URL. One view of everything.

The Full Workflow

Here's what a typical day looks like. You start your project's databases in the morning:

bash
lbase start mypostgres
lbase start myredis

You work all day. Your app connects to localhost:5432 and localhost:6379 like it always has. At the end of the day:

bash
lbase stop mypostgres
lbase stop myredis

No Docker Desktop running in the background overnight. No VM using memory while you sleep. Start the databases when you need them, stop them when you don't.

When Docker Still Makes Sense

I want to be fair here. The Layerbase CLI is a local development tool. Docker does things the Layerbase CLI doesn't try to do, and there are real scenarios where Docker is the right choice.

Production parity. If your production environment runs containers on Kubernetes or ECS, running the same containers locally ensures your development environment matches. Configuration, init scripts, and runtime behavior are identical. The Layerbase CLI gets you a running database quickly, but it's not replicating your exact production setup.

CI/CD pipelines. GitHub Actions, GitLab CI, and most CI systems have first-class Docker support. Spinning up a PostgreSQL container in a CI pipeline is well-documented and reliable. The Layerbase CLI is focused on your local machine.

Complex networking. If your development setup involves multiple services talking to each other through Docker's internal networking (service discovery by container name, custom networks, network policies), Docker Compose handles that natively. The Layerbase CLI runs databases on localhost.

Custom images. If you need a PostgreSQL instance with specific extensions pre-installed, custom postgresql.conf settings, or init scripts that seed data on first boot, a Dockerfile gives you that reproducibility.

Team standardization. A docker-compose.yml committed to the repo means every developer gets the exact same setup. The CLI's instances are local to each machine. Both approaches work for teams, but Docker has a longer track record here.

The short version: use Docker when you need containerization. Use the Layerbase CLI when you just need a database running.

Layerbase Cloud: Skip the Local Setup Entirely

Sometimes you don't want to run anything locally at all. Maybe you're on a low-powered machine, or you're collaborating with someone who needs access to the same database, or you just want a connection URL without managing any infrastructure.

Layerbase Cloud gives you managed database instances for PostgreSQL, Valkey, Qdrant, and many other engines. Create an instance, grab the connection URL from the Quick Connect panel, and point your app at it. TLS is included, backups are handled, and the database runs on dedicated infrastructure instead of your laptop.

Your application code stays the same. Just swap the localhost URL for the cloud URL.

Layerbase Desktop: A GUI Alternative

If you prefer clicking over typing, Layerbase Desktop wraps SpinDB in a desktop GUI. Create instances, start and stop them, view connection details, and manage everything visually. Same engines, same native binaries under the hood, just with a graphical interface instead of a terminal.

Wrapping Up

Docker is a powerful tool that solves real problems. But for local database development, it solves them with more overhead than most projects need. The Layerbase CLI gives you the same databases, running natively, with less setup and less resource usage.

Install the Layerbase CLI and try it:

bash
npm i -g layerbase
lbase create mydb -e postgresql --start
lbase url mydb

The Layerbase CLI supports 20+ database engines, from PostgreSQL and MySQL to MongoDB, ClickHouse, Qdrant, and SurrealDB. One CLI for all of them.

To manage your instances:

bash
lbase stop mypostgres   # Stop PostgreSQL
lbase stop myredis      # Stop Redis
lbase stop myqdrant     # Stop Qdrant
lbase start mypostgres  # Start PostgreSQL again
lbase list              # See all instances

Keep reading