DBngin alternatives for when you need a terminal

Ask a room of developers how to run PostgreSQL locally without Docker and someone will say DBngin. They are not wrong. You install it, click a plus button, pick a version, and there is a Postgres server on port 5432 about two seconds later. No Homebrew formula that auto-starts a LaunchAgent you did not ask for. No 400 MB image pull. No YAML.

It has stayed good, too. The team behind TablePlus still ships it, there is a Windows build now alongside the Mac one, and the July 2026 release added PostgreSQL 18.4 and MySQL 9.7.1. Anyone telling you DBngin is abandoned macOS-only software is working from an old memory.

So this post is not a takedown. It is about the specific wall people hit, which is not a bug and not neglect. DBngin is a desktop app, and a desktop app cannot be typed into a script.

Contents

• What DBngin is actually good at
• Where it stops
• Two different replacements
• Side by side
• The CLI in about two minutes
• A database per project
• The part that only a CLI can do
• When DBngin is still the right tool
• The same engines, hosted

What DBngin is actually good at

The install-to-running time is the whole product, and it is genuinely short. Multiple versions of the same engine can sit side by side on different ports, which is the thing that makes upgrading a project's Postgres from 15 to 17 a five minute experiment instead of an afternoon. It is free. It does not run a Linux VM in the background to do any of this.

If your work is one or two projects on a Mac, all of them on Postgres, and you never need to reproduce your local setup anywhere else, DBngin is very close to the correct amount of tool. Most of the people who churn off it are not leaving because it broke.

Where it stops

Three things, and they compound.

The engine list is short. DBngin's own site names PostgreSQL, MySQL, MariaDB, and Redis. That covers a large fraction of applications, and it stops covering yours the day someone adds a vector store for a search feature, or ClickHouse for the analytics page, or a time-series database for metrics. Then you are back to downloading a binary from a GitHub release and writing a shell alias so you do not have to type the path.

There is no Linux build. Mac and Windows only. If your team is mixed, the setup instructions in your README fork immediately, and the person on Ubuntu gets the Docker path while everyone else gets the nice one.

The one that actually matters: there is no command line. DBngin has no terminal interface, which means nothing you set up in it can be scripted, committed to the repo, or executed by a machine that has no screen. Onboarding a new engineer is a paragraph of instructions with screenshots. Your CI pipeline uses a completely different mechanism from your laptop, so the two drift, and you find out they drifted in a pull request at 6pm.

Two different replacements

People searching for a DBngin alternative are usually asking one of two questions, and they want different answers.

If you want the click-a-button experience and just need it on Linux, or need an engine DBngin does not carry, the comparison is Layerbase Desktop. It is a GUI over local database instances, it runs on macOS, Windows, and Linux, and it covers 21 engines. Create, start, stop, query, back up, all visually. Nothing to learn if you are coming from DBngin.

If the reason you are shopping is the scripting gap, the answer is the Layerbase CLI. It runs the same native binaries with no Docker daemon involved, but every operation is a command, which means it also works over SSH, inside a Makefile, and on a GitHub Actions runner. That is the part DBngin structurally cannot do, and it is worth most of this post. (What is the Layerbase CLI?)

They are the same underlying thing. Use whichever interface you actually enjoy, and use both if you want the GUI on your laptop and the commands in CI.

Side by side

The row that decides it for most people is not the engine count. It is the CI row, because that is the one that changes how the rest of your project is built.

The CLI in about two minutes

Install it once:

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

Create a Postgres instance and start it:

lbase create shopdb -e postgresql --start

The first run downloads the PostgreSQL binary for your platform and caches it, initializes a data directory, picks a port, and starts the server. Subsequent creates skip the download.

Ask for the connection string:

lbase url shopdb

postgresql://127.0.0.1:5432/shopdb

That goes straight into your .env. If you would rather land in a shell immediately, --connect opens the engine's own client as soon as the instance is up:

lbase create shopdb -e postgresql --start --connect

You get psql without having installed psql. The client tooling ships with the engine, which is one of the quieter conveniences here, because the usual alternative is a Homebrew install of libpq and a PATH argument with someone's blog post open in another tab.

Adding the rest of a stack is more of the same:

lbase create shop-cache -e valkey --start
lbase create shop-search -e qdrant --start
lbase create shop-analytics -e clickhouse --start

lbase list

shopdb            postgresql   running   postgresql://127.0.0.1:5432/shopdb
shop-cache        valkey       running   redis://127.0.0.1:6379
shop-search       qdrant       running   http://127.0.0.1:6333
shop-analytics    clickhouse   running   clickhouse://127.0.0.1:9000

Stop and start are what you would guess, and data survives both:

lbase stop shopdb
lbase start shopdb

lbase delete shopdb removes an instance and its data directory when you are done with a project.

A database per project

DBngin's model is one server per engine version, shared across everything on your machine. Two projects that both want Postgres 17 share a server and live in separate logical databases inside it. That works until one project needs a different extension, or a different locale, or you want to wipe one project's data without touching the other.

The CLI's unit is an instance, and instances are cheap. Naming them after projects is the pattern that pays off:

lbase create acme-api -e postgresql --start
lbase create bitmark-api -e postgresql --start

Two Postgres servers, two data directories, two ports assigned automatically. No port collision to resolve by hand, and deleting one project's database is one command that cannot touch the other's.

Pinning a version is a flag rather than a dropdown, which matters when the version is a fact about the project rather than a preference:

lbase create legacy-api -e postgresql --db-version 15 --start

The part that only a CLI can do

Here is the thing a desktop app cannot give you at any quality level: the same database setup running on a machine with no display.

A CI job that needs a real Postgres usually gets one of two treatments. Either a service container, which means your local setup and your CI setup are two different systems that happen to agree today, or a managed test database, which is a shared resource that two concurrent jobs will eventually fight over. With a CLI, the CI step is the same three lines you run locally:

- name: Start test databases
  run: |
    npm i -g layerbase
    lbase create ci-pg -e postgresql --start
    echo "DATABASE_URL=$(lbase url ci-pg)" >> $GITHUB_ENV

Your test suite reads DATABASE_URL and does not know or care that it is talking to a native binary rather than a container. Nothing is shared with another job. Nothing has to be cleaned up, because the runner is discarded.

The same property makes onboarding a script instead of a document. Put this in the repo:

#!/usr/bin/env bash
set -euo pipefail

lbase create acme-api -e postgresql --start
lbase create acme-cache -e valkey --start

echo "DATABASE_URL=$(lbase url acme-api)" > .env.local
echo "REDIS_URL=$(lbase url acme-cache)" >> .env.local

New engineer clones the repo, runs the script, and has a working environment. No screenshots to keep current. For anything that needs to parse the output rather than read it, --json is on the commands that return data:

lbase list --json
lbase url acme-api --json

When DBngin is still the right tool

I would not switch someone off DBngin for the sake of it.

If you are on a Mac, your projects are Postgres and Redis, and you have never once wanted to automate the setup, the thing you would gain by moving is mostly theoretical. DBngin's install is smaller than a Node toolchain, and if you do not have Node on the machine already then npm i -g layerbase is a real prerequisite rather than a footnote.

There is also a category of person who simply does not want a terminal in this part of their work, and that preference is legitimate. The Layerbase answer for them is Desktop, not the CLI, and the case for switching is Linux support and the longer engine list rather than anything about automation.

Where I would push is if you have ever written a paragraph in a README explaining which buttons to click in a GUI. That paragraph is a script that has not been written yet, and it goes stale the week after you write it.

The same engines, hosted

At some point the local database stops being the interesting problem. You want a teammate to hit the same data, or a preview deployment needs a real database, or you would rather not have four servers running on a laptop that is also compiling something.

Layerbase Cloud runs the hosted side of the same engine set: 18 engines, one account, TLS and backups handled. The free tier is $0 with no card, and Pro is $15/month flat rather than a meter that moves with your traffic. Your application code does not change, because the only difference is which URL is in DATABASE_URL.

The local instances and the cloud ones coexist fine. Develop against lbase url, point staging at a cloud database, and keep the same driver on both ends.

Wrapping up

DBngin solved the right problem and solved it cleanly. If it is doing the job for you, keep it.

What it cannot do is participate in anything automated, because there is nothing to type. If your database setup has to exist in a repo, run on a Linux CI runner, or cover an engine outside the ones DBngin's site names, that is the moment a CLI stops being a stylistic preference.

npm i -g layerbase
lbase create mydb -e postgresql --start --connect

A Postgres shell opens in a few seconds. For a GUI version of the same thing across macOS, Windows, and Linux, there is Layerbase Desktop, and for the hosted version there is Layerbase Cloud.