LayerbaseLayerbase

How to Run Databases Locally Without Docker

SpinDBDatabasesDeveloper 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 SpinDB?

SpinDB is a CLI 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.

The key difference from Docker: SpinDB 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 SpinDB globally:

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

Now create a PostgreSQL instance:

bash
spindb create mypostgres -e postgresql --start

That's it. SpinDB 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
spindb url mypostgres
text
postgresql://127.0.0.1:5432/mypostgres

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

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

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

bash
spindb 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. SpinDB handles port conflicts automatically if you create multiple instances of the same engine.

Docker Compose vs SpinDB: 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 SpinDB Approach

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

Three commands. No configuration file. No image downloads (SpinDB'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
spindb url mypostgres  # postgresql://127.0.0.1:5432/mypostgres
spindb url myredis     # redis://127.0.0.1:6379
spindb 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

SpinDB gives you a small set of commands that cover the full lifecycle.

Stop and Start

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

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

Get Connection Details

bash
spindb 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
spindb 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
spindb 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
spindb start mypostgres
spindb 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
spindb stop mypostgres
spindb 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. SpinDB is a local development tool. Docker does things that SpinDB 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. SpinDB 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. SpinDB 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. SpinDB 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. SpinDB 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 SpinDB 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 macOS 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. SpinDB gives you the same databases, running natively, with less setup and less resource usage.

Install SpinDB and try it:

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

SpinDB 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
spindb stop mypostgres   # Stop PostgreSQL
spindb stop myredis      # Stop Redis
spindb stop myqdrant     # Stop Qdrant
spindb start mypostgres  # Start PostgreSQL again
spindb list              # See all instances

Something not working?