Open source · 18 engines · 277 pages
Run databases
like you have done it
a hundred times
DBPilot is the production playbook the docs never gave you: architecture patterns, tuned configuration, operational checklists and incident playbooks for 18 database engines — written for the person who gets paged.
No sign-up, no tracking, no paywall. Apache-2.0, and every page has an edit link.
- database engines
- 18database engines
- documentation pages
- 224documentation pages
- incident playbooks
- 23incident playbooks
- engine comparisons
- 12engine comparisons
- commands and configs
- 784commands and configs
Three ways in
Most people arrive here doing one of three things. Pick the one that matches your afternoon.
Choose a database
Start from the workload rather than the engine, and see the trade-off each option commits you to.
Selection guideShip to production
Work through the readiness checklist for your engine: topology, backups, limits, monitoring and failover.
Readiness checklistFix an incident now
Symptom-first playbooks with every command labelled read-only or destructive, so nothing surprising happens at 3am.
All playbooks
9 categories, one decision
A category describes how an engine stores and distributes data — and what it gives up in exchange. It narrows the choice further than any feature matrix.
Relational
Row-oriented engines with schemas, joins and ACID transactions on a single primary node.
Typical use
- Transactional application state
- Reporting over normalised data
- Systems that need constraints and foreign keys
Key-Value
In-memory stores addressed by key, optimised for sub-millisecond reads and simple data structures.
Typical use
- Caching
- Rate limiting
- Session storage
- Job queues
Document
Schema-flexible stores that persist JSON-like documents and index their fields.
Typical use
- Aggregate-oriented domain models
- Content and catalogue data
- Rapidly evolving schemas
Column-Oriented
Analytical engines that store data by column and scan large ranges with vectorised execution.
Typical use
- Event and log analytics
- Product and business intelligence
- Aggregations over billions of rows
Wide Column
Masterless, partition-keyed stores built for linear write scaling across many nodes.
Typical use
- Very high write throughput
- Time-ordered records per entity
- Multi-datacenter replication
Distributed SQL
Horizontally scalable SQL engines with consensus-replicated ranges and distributed transactions.
Typical use
- Transactional workloads that outgrow one node
- Multi-region applications
- Survivable-by-design deployments
Time Series
Engines specialised for timestamped measurements, with retention, downsampling and compression built in.
Typical use
- Infrastructure and application metrics
- IoT and sensor telemetry
- Long-term trend analysis
Search Engines
Inverted-index engines for relevance-ranked full-text search and ad-hoc aggregation.
Typical use
- Full-text search over documents
- Log search and observability
- Faceted navigation
Embedded
Libraries that run inside the application process and store data in local files.
Typical use
- Client-side and edge applications
- Local state for services
- Storage engines inside other databases
Most-opened guides
The pages teams reach for while planning a launch — or halfway through an incident.
- PostgreSQLPostgreSQL Production ChecklistSpecific, verifiable checks to complete before a PostgreSQL cluster carries production traffic.1 min read
- Redis and ValkeyRedis Memory ManagementSetting maxmemory, choosing an eviction policy, and diagnosing fragmentation and unexpected memory growth.3 min read
- ClickHouseClickHouse Partitioning StrategyChoosing a partition key for retention and pruning, and why over-partitioning is the most common ClickHouse mistake.2 min read
- MongoDBMongoDB Index DesignThe ESR rule for compound indexes, covered queries, partial and TTL indexes, and how to find indexes that earn nothing.3 min read
- CassandraCassandra Consistency LevelsPer-query consistency, replication factor, and the quorum arithmetic that decides what a read is guaranteed to see.3 min read
- MySQLMySQL ReplicationSetting up asynchronous and semi-synchronous replication with GTIDs, parallel apply, and how to diagnose a stopped replica.3 min read
- OperationsBackup StrategiesChoosing between logical, physical, incremental and snapshot backups, and building a schedule from a stated recovery objective.3 min read
- Production Best PracticesZero-Downtime MigrationsThe expand-and-contract pattern for schema changes, applied to renames, type changes, splits and index builds while traffic continues.3 min read
Start from the workload
Most selection mistakes come from picking an engine first and then discovering the access pattern it cannot serve. Pick what you are building instead.
Reads and writes of application state where correctness, constraints and multi-row atomicity matter.
The decisive question: Does the write volume fit on one node? If yes, a single-primary relational engine is simpler to run than anything distributed.
- PostgreSQLDesigned for this
Strict types, real constraints, serializable isolation. One writable primary per cluster.
- MySQLDesigned for this
Mature replication tooling and predictable InnoDB behaviour. Weaker DDL and type strictness than PostgreSQL.
- CockroachDBWorks with caveats
Removes the single-writer ceiling, at the cost of higher write latency from consensus round trips.
- MongoDBWorks with caveats
Multi-document transactions exist but are more expensive than single-document updates; model to avoid needing them.
Ratings describe fit for this workload only. An engine rated “only in narrow cases” here may be the right choice for a different one.
Before you take traffic
Eight areas decide the first bad day
Each one has a checklist written as verifiable actions — not “configure security”, but “verify that backups restore into an isolated environment”.
- SecurityAuthentication, least-privilege roles, network isolation and TLS between clients and nodes.
- BackupsA backup schedule matched to your RPO, stored outside the primary's failure domain and verified by restore.
- ReplicationA replica topology that matches the durability you promised, with lag monitored and failover rehearsed.
- MonitoringSaturation, latency, error and replication metrics collected before you need them, not during an incident.
- Capacity planningHeadroom for storage, memory, connections and IOPS, with a forecast of when each runs out.
- Schema managementVersioned, reviewed migrations that are safe to apply while the application is serving traffic.
- Connection managementBounded pools, explicit timeouts and a plan for what happens when the pool is exhausted.
- Incident responseNamed owners, runbooks for the failures you expect, and a rollback path for every change.
Find the page you need in two keystrokes
Search covers every title, heading, tag and engine name across the whole handbook — entirely in your browser, with nothing sent anywhere.
PressCtrlKanywhere on the site
Found a command that is wrong, or a default that changed? That is the most valuable contribution you can make.