About DBPilot
What this handbook covers, who it is written for, and how to read it without drowning in engine-specific detail.
DBPilot is an open-source handbook for the people who run databases: backend engineers who own a schema, DevOps and SRE teams who own the cluster, architects choosing between engines, and DBAs who inherit all of it.
It is written around a simple observation. Most database outages are not caused by exotic bugs. They are caused by defaults that were never reviewed, a backup nobody restored, an index nobody measured, a connection pool nobody bounded, or a replication topology nobody tested a failover against. This handbook is a record of those failure modes and what to do instead.
What this covers
- Selection. How to match a workload to a category of database, and what each category gives up in exchange for what it is good at.
- Architecture. Replication, sharding, partitioning, consensus and consistency models — the vocabulary every engine reuses with slightly different names.
- Per-engine operation. Configuration, indexing, replication, backup, monitoring and the specific mistakes that recur with PostgreSQL, MySQL, Redis, ClickHouse, MongoDB, Cassandra and the rest of the 18 engines covered here.
- Production practice. Capacity planning, migrations, disaster recovery, security hardening, monitoring and incident response, written to apply regardless of engine.
- Troubleshooting. Symptom-first playbooks for the pages you open during an incident, not before one.
What this is not
This is not vendor documentation, and it does not replace it. Official documentation is the authority on syntax, flags and version-specific behaviour, and it changes with every release. This handbook covers the parts that documentation usually omits: which knob matters, what it costs, and what breaks in production when it is wrong.
It is also not a benchmark site. Published benchmark numbers are almost always measured on hardware, data and query mixes that do not resemble yours. Where performance is discussed here, it is discussed as a mechanism — why an access pattern is fast or slow — so you can reason about your own system.
How to Use This Guide
There are four ways in, depending on what you are doing.
Choosing a database. Start with Understanding Workload Types, then Choosing a Database, then the relevant comparison. Read the "When not to use it" section of any engine profile before the marketing page.
Preparing for production. Work through the Production Readiness Checklist, then the engine-specific checklist — for example PostgreSQL Production Checklist. The checklists are deliberately specific: "verify a restore into an isolated environment" rather than "set up backups".
Learning an engine. Each engine section starts with an overview and follows the same progression: architecture, configuration, indexing and query behaviour, replication, backup, monitoring, then a checklist.
Responding to an incident. Go straight to Playbooks and find the symptom. Every playbook labels its commands as read-only or destructive, so you can act quickly without guessing which ones change cluster state.
Conventions used here
Configuration guidance is always tied to a deployment tier, because a value that is correct on a laptop is wrong on a 64-core server:
Commands that can lose data, change replication topology or saturate a cluster are marked explicitly:
Contributing
Corrections are the most valuable contribution. If a command here is wrong, a default has changed in a newer version, or a recommendation does not hold for a workload you operate, open an issue or a pull request — every page has an "Edit this page" link. See CONTRIBUTING.md for the content standards, particularly the rule that configuration values must always state the assumptions they were sized against.