A database setup for software development agencies

If you build software for other people, you do not really have a stack. You have everyone else's.

One client runs Postgres and Redis. Another handed you a MongoDB app you would never have chosen. A new one wants ClickHouse behind the dashboard you are building them. You picked none of it, and you keep all of it running.

That is the part nobody warns you about with agency work. The code is the easy part. The databases are what sprawl. Every project has its own engines, its own local setup, its own host, its own credentials, and they all live in different places. Six months in you have a drawer full of .env files and no single view of what is running where.

Here is how to get it under one roof.

Start with local

Every client project has to run on your laptop, and every one of them wants different database software. The old way is a pile of Homebrew formulae and Docker Compose files, each with its own quirks, ports that collide, and data directories you will never find again.

SpinDB replaces all of that with one CLI that runs every engine the same way. (What is SpinDB?)

npm i -g spindb

Name an instance per client and engine, and the sprawl turns into a list you can actually read:

spindb create acme-pg -e postgresql --start
spindb create acme-redis -e redis --start
spindb create globex-mongo -e mongodb --start
spindb create initech-clickhouse -e clickhouse --start

spindb list

acme-pg              postgresql   running   postgresql://127.0.0.1:5432/acme-pg
acme-redis           redis        running   redis://127.0.0.1:6379
globex-mongo         mongodb      running   mongodb://127.0.0.1:27017
initech-clickhouse   clickhouse   running   clickhouse://127.0.0.1:9000

One view, every client, every engine. SpinDB downloads each binary (cached after the first time), gives every instance its own data directory, and picks a free port when the default is taken. When a project wraps, spindb destroy initech-clickhouse and it is gone, data and all. No service quietly running for a client you stopped invoicing in March.

The naming convention does the filing for you. Prefix every instance with the client and spindb list becomes your inventory.

Then the hosted side

Local is for building. Sooner or later every client needs a real database somewhere their staging and production apps can reach. This is where agencies usually end up with five vendor logins and five bills.

Layerbase Cloud puts all of it in one account. The same 20-plus engines SpinDB runs locally, hosted, with TLS, backups, and the infrastructure handled. One dashboard, one login, one bill, every client.

• Postgres for the app
• Redis for sessions and caching
• ClickHouse for the analytics dashboard

Each database has its own connection string on its detail page. Copy it into the client's deploy environment and you are done. No marketplace integration to wire up per project, no separate account to provision and remember.

An onboarding workflow

A new client lands. Their app is Postgres plus Redis. Here is the whole setup.

Local, so you can build:

spindb create newclient-pg -e postgresql --start
spindb create newclient-redis -e redis --start
spindb url newclient-pg     # paste into .env
spindb url newclient-redis  # paste into .env

Hosted, when it is time to deploy: create a Postgres and a Redis on Layerbase Cloud, grab the connection strings from each detail page, and drop them into the client's staging and production environments.

That is it. The same engine, the same wire protocol, the same drivers in both places. The only thing that changes between your laptop and their production is the URL.

Branching for the change you are scared to ship

The risky part of client work is the change you are not sure about. A migration against a database full of their real data. A bulk update. A schema change a junior wrote on a Friday.

Branch the database first. On Layerbase Cloud a branch is a copy-on-write fork of a running database: hit Branch, get an isolated copy in seconds, point staging at it, and run the scary thing there. If it goes wrong, delete the branch. The client's real data never moved. Branching is available on Postgres, MySQL, MariaDB, Redis, Valkey, FerretDB, libSQL, SQLite, and DuckDB.

You can do the same locally before you touch anything hosted:

spindb branch newclient-pg newclient-pg-migration
spindb connect newclient-pg-migration   # run the migration here first

If it works, run it for real. If it does not, spindb branch reset newclient-pg-migration puts it back and you try again. The longer version is in branching with any database.

A GUI when you want one

Not everyone on the team lives in a terminal. Layerbase Desktop wraps SpinDB in an app: create instances, start and stop them, open a query console, and browse data for every engine, including a document view for MongoDB and FerretDB. Same binaries underneath, buttons instead of commands. Good for the designer who needs to poke at staging data without learning psql.

The commands you will actually use

# Stand up a client's stack
spindb create <client>-pg -e postgresql --start
spindb create <client>-redis -e redis --start

# See everything, across every client
spindb list

# Grab a connection string for an .env
spindb url <client>-pg

# Open a shell to poke around
spindb connect <client>-pg

# Park a client's databases when you switch projects
spindb stop <client>-pg <client>-redis

# Offboard a finished project, data and all
spindb destroy <client>-pg

The point is not any single command. It is that the command is the same whether the client picked Postgres, MySQL, MongoDB, ClickHouse, or anything else in the catalog of 20-plus engines. You stop memorizing five tools and start running one.

Build locally with SpinDB, host on Layerbase Cloud, and keep every client's database in one place instead of five.