Database Cheat Sheet for 21 Engines

Short version: 21 engines, grouped by what they are for, with the one-line reason to pick each and the exact command to run it locally. Start at PostgreSQL if you have no strong opinion. Reach past it when the workload has a shape a generalist handles badly: a cache, a time-series firehose, vectors, columnar analytics, or a ledger that has to balance. The quick reference table at the bottom has every engine, its flag, its default port, and the npm client to connect with.

Here's every database engine the Layerbase CLI supports, what each one does, and when to pick it. Bookmark this page and come back whenever you're choosing an engine for a new project.

Install the Layerbase CLI

Every engine below runs locally with a single command. The Layerbase CLI is the open-source tool formerly called SpinDB, now shipped as the layerbase npm package with the lbase binary. Install it first:

npm i -g layerbase

Then create any engine with lbase create <name> -e <engine> --start. Each section below includes the exact command.

Relational

PostgreSQL

The generalist. Extensions for full-text search, JSON, geospatial, and more. If you're unsure which database to use, start here.

Best for: general-purpose applications, complex queries, any workload that benefits from strong ACID guarantees.

lbase create pg1 -e postgresql --start

What's new in PostgreSQL 18 | Docs

MySQL

The most widely deployed relational database. Massive ecosystem of tools, hosting providers, and community knowledge.

Best for: read-heavy web applications, WordPress/PHP stacks, and projects where ecosystem breadth matters.

lbase create mysql1 -e mysql --start

Getting started with MySQL | Docs

MariaDB

A MySQL fork with extras: sequences, temporal tables, system-versioned rows, and the Aria storage engine. Drop-in compatible with MySQL in most cases.

Best for: MySQL workloads that need temporal queries, sequences, or Oracle-to-open-source migrations.

lbase create maria1 -e mariadb --start

Getting started with MariaDB | Docs

CockroachDB

Distributed PostgreSQL. Spreads data across nodes automatically with strong consistency. Survives node and region failures without manual intervention.

Best for: globally distributed applications that need horizontal scaling with PostgreSQL compatibility.

lbase create crdb1 -e cockroachdb --start

Getting started with CockroachDB | Docs

Document

MongoDB

The most popular document database. Flexible schemas, a rich query API, and aggregation pipelines for complex transformations.

Best for: applications with evolving schemas, nested/hierarchical data, or rapid prototyping where schema flexibility matters.

lbase create mongo1 -e mongodb --start

Getting started with MongoDB | Docs

FerretDB

The MongoDB API running on top of PostgreSQL. Gives you MongoDB's query language with PostgreSQL's storage and reliability. Fully open-source.

Best for: teams that want MongoDB compatibility without the SSPL license, or that want to use existing PostgreSQL infrastructure.

lbase create ferret1 -e ferretdb --start

Getting started with FerretDB | Docs

CouchDB

An HTTP-native document database with built-in multi-master replication. Syncs data between nodes (or between server and client) with automatic conflict resolution.

Best for: offline-first applications, multi-datacenter replication, and scenarios where devices need to sync data reliably.

lbase create couch1 -e couchdb --start

Getting started with CouchDB | Docs

Key-Value / Cache

Redis

An in-memory data structure store with sub-millisecond latency. Supports strings, lists, sets, sorted sets, hashes, streams, and more. Far more than a simple cache.

Best for: caching, session storage, rate limiting, leaderboards, real-time counters, and pub/sub messaging.

lbase create redis1 -e redis --start

Getting started with Redis | Docs

Valkey

An open-source fork of Redis (Linux Foundation) using the same wire protocol. Compatible with Redis clients and commands.

Best for: the same workloads as Redis, for teams that prefer a BSD-licensed alternative.

lbase create valkey1 -e valkey --start

Getting started with Valkey | Docs

Search

Meilisearch

A typo-tolerant, full-text search engine with sub-50ms response times out of the box. Zero configuration needed for relevance.

Best for: user-facing search bars, autocomplete, product search, and any feature where typo tolerance and speed matter.

lbase create meili1 -e meilisearch --start

Getting started with Meilisearch | Docs

Qdrant

A vector database for similarity search. Store embeddings and query by semantic meaning rather than keywords.

Best for: semantic search, recommendation engines, RAG pipelines, image similarity, and anomaly detection.

lbase create qdrant1 -e qdrant --start

Getting started with Qdrant | Docs

Weaviate

A vector database with built-in vectorizer modules. Supports hybrid search (vector + keyword) and integrates with OpenAI, Cohere, and Hugging Face for automatic embedding.

Best for: hybrid search, multimodal search (text + images), and applications that want vectorization handled by the database.

lbase create weav1 -e weaviate --start

Getting started with Weaviate | Docs

Time Series

QuestDB

A time-series database that speaks SQL. The SAMPLE BY clause aggregates time-series data in one line. Columnar storage with high ingestion throughput.

Best for: IoT sensor data, application metrics, financial tick data, and any workload with timestamped append-only data.

lbase create quest1 -e questdb --start

Getting started with QuestDB | Docs

InfluxDB

A time-series database with its own Flux query language and built-in retention policies that automatically expire old data.

Best for: infrastructure monitoring, application metrics, and time-series workloads that need automatic data lifecycle management.

lbase create influx1 -e influxdb --start

Getting started with InfluxDB | Docs

Analytics

ClickHouse

A columnar database built for analytical queries at massive scale. Vectorized execution processes billions of rows per second.

Best for: real-time dashboards, log analytics, event tracking, and any workload that aggregates large datasets.

lbase create click1 -e clickhouse --start

Getting started with ClickHouse | Docs

DuckDB

An embedded analytical database. Think SQLite, but for OLAP. Runs in-process with no server. The Layerbase CLI exposes it through a PostgreSQL-compatible proxy.

Best for: local analytics, data science workflows, CSV/Parquet file querying, and replacing pandas for SQL-native analysis.

lbase create duck1 -e duckdb --start

Getting started with DuckDB | Docs

Embedded

SQLite

A single-file database with zero configuration. No server, no daemon. The most deployed database engine in the world. The Layerbase CLI exposes it through a PostgreSQL-compatible proxy.

Best for: local-first apps, embedded systems, CLI tools, prototyping, and any application where simplicity beats scalability.

lbase create sqlite1 -e sqlite --start

Getting started with SQLite | Docs

LibSQL

A fork of SQLite that adds server mode, replication, and vector search extensions. Backwards-compatible with SQLite files.

Best for: SQLite workloads that need a server mode, multi-client access, edge replication, or built-in vector search.

lbase create libsql1 -e libsql --start

Getting started with LibSQL | Docs

Multi-Model

SurrealDB

A multi-model database combining document, graph, and relational paradigms in one engine. Uses its own query language (SurrealQL) with graph traversals, record links, and schema flexibility.

Best for: applications that need graph traversals alongside document storage without running separate databases.

lbase create surreal1 -e surrealdb --start

Getting started with SurrealDB | Docs

Specialized

TypeDB

A database for knowledge graphs with a type system and built-in inference rules. Define logical rules and TypeDB derives new facts automatically.

Best for: knowledge graphs, drug discovery pipelines, fraud detection, and any domain where you need to reason over relationships.

lbase create typedb1 -e typedb --start

Getting started with TypeDB | Docs

TigerBeetle

A purpose-built financial transaction database. Designed for double-entry bookkeeping with strict consistency guarantees and zero-copy I/O.

Best for: ledgers, payment systems, account balances, and any workload where financial correctness is non-negotiable.

lbase create tiger1 -e tigerbeetle --start

Getting started with TigerBeetle | Docs

Quick Reference Table

Wrapping Up

Every engine above runs locally with lbase create <name> -e <engine> --start and connects with a standard npm package. No Docker, no manual binary downloads.

Need a managed instance instead? Layerbase Cloud provisions 18 of these engines in seconds. The three it cannot host are MongoDB, CockroachDB, and SurrealDB, which are licensed in ways that rule out a managed offering; for documents in the cloud, FerretDB speaks the MongoDB wire protocol and your driver connects unchanged. Or grab Layerbase Desktop for a GUI over the whole 21.

lbase list        # see all running instances
lbase url <name>  # get the connection string
lbase stop <name> # stop an instance
lbase start <name> # restart it

Read more at layerbase.com/docs/cli.

FAQ

Which engine should I pick if I have no idea?

PostgreSQL. It handles JSON, full-text search, and geospatial through extensions, so a project that starts general and gets specific usually does not have to move. The engines below it in this list exist because a particular shape of workload, a cache, a metrics firehose, a vector index, defeats a generalist, not because Postgres is a poor default.

What is the difference between MongoDB and FerretDB here?

FerretDB implements the MongoDB wire protocol on top of PostgreSQL, so the same mongodb:// string and the same driver work against it. Both run locally through the CLI. In the cloud only FerretDB is available, because MongoDB's license does not permit us to host it, which is also why FerretDB is the document answer on Layerbase Cloud.

Do I need Docker for any of these?

No. The CLI downloads and runs real engine binaries directly, so lbase create <name> -e <engine> --start is the whole setup, and there is no daemon in the way. The Docker Compose comparison goes through what that changes about a local dev loop.

Why do SQLite and DuckDB list port 5432?

Because the CLI puts a PostgreSQL-wire proxy in front of them, so psql and the pg npm client connect to an embedded engine as if it were a Postgres server. It is a convenience layer over a file-backed database, not a client-server engine underneath.

Can I run several of these at once?

That is the normal case, and each instance gets its own port and its own connection string. Managing multiple databases locally covers lbase list, per-project conventions, and keeping ports straight when a machine is running six of them.