Database Cluster Consulting — PostgreSQL, MySQL, TiDB & Beyond
The cluster that keeps your business alive. Planned failover in seconds, backups you have actually restored, and upgrades performed while the application keeps writing.
What this usually looks like
Your database has one primary, no rehearsed failover, and a backup job whose restore has never been timed. Everything else in your infrastructure is safer than this.
- Failover means waking someone up and hoping the replication lag was zero.
- The backup ran successfully for two years and has never been restored once.
- A schema change requires a maintenance window because there is no online DDL path.
- Read replicas exist but the application still reads from the primary.
Three ways to buy this
Audit if you want to know how bad it is. Build if you have the team and want the capability. Managed if you don't want to own the pager. Most engagements start with the audit and decide afterwards.
Audit
A fixed-price health check — the cheapest way in
- Replication topology and lag analysis under real load
- Backup restorability test — we actually restore it, and time it
- Failover readiness review: witness, quorum, split-brain exposure
- Query and index review for the top resource consumers
Build
One-off delivery: design, code, hardening, handover
- PostgreSQL HA with Patroni + etcd/Consul, PgBouncer pooling, pgBackRest or WAL-G PITR
- MySQL/MariaDB HA: Galera or Group Replication + MySQL Router + ProxySQL
- Distributed SQL where it genuinely fits: TiDB, CockroachDB, YugabyteDB, Vitess
- MongoDB replica sets and sharded clusters, Cassandra/ScyllaDB rings
- ClickHouse clusters with ReplicatedMergeTree + Keeper; ES/OpenSearch with shard planning
- Online schema change pipeline (gh-ost, pt-online-schema-change)
Managed
Build plus 7×24 on-call, SLA and quarterly drills
- Version upgrades executed with the application online, and a rollback plan
- Backup verification: restore into an isolated environment quarterly, timed
- Replication health, lag alerting, and disk-growth forecasting
- Vacuum/bloat management, slow-query triage, and capacity review
What we actually deploy
Specific tooling, not categories. If a version matters to your decision, ask — we will tell you which one we would pick and why, including when the answer is the older one.
PostgreSQL
- Patroni
- pgBackRest
- WAL-G
- PgBouncer
- pgpool-II
- Citus
- TimescaleDB
- pg_partman
- pg_stat_monitor
- PG 15/16/17 rolling upgrades
MySQL / MariaDB
- Galera Cluster (PXC, MariaDB)
- Group Replication + MySQL Router
- InnoDB Cluster
- ProxySQL
- gh-ost
- pt-online-schema-change
- Percona XtraBackup
Distributed SQL
- TiDB + TiKV + PD
- CockroachDB
- YugabyteDB
- OceanBase
- Vitess (sharded MySQL)
NoSQL
- MongoDB replica set / sharded
- Cassandra
- ScyllaDB
- HBase
- Redis Cluster
- Redis Sentinel
- Valkey
- Dragonfly
OLAP & columnar
- ClickHouse + Keeper
- ReplicatedMergeTree
- StarRocks
- Apache Doris
- Greenplum
- DuckDB (embedded analytics)
Search
- Elasticsearch 8.x
- OpenSearch
- cross-cluster search
- Meilisearch
- Typesense
Vector stores
- Milvus
- Qdrant
- Weaviate
- pgvector
Cross-cutting
- read/write splitting
- sharding and resharding
- dual-site active/active with a witness
- PITR
- logical replication
- connection pooling
What we will be measured on
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Automatic primary failover under 30 seconds by default — configurable, and configured to your measured tolerance.
- A completed restore-from-backup exercise with a real RPO number. If it has not been restored, we do not call it a backup.
- Online DDL on large tables with the application writing throughout.
- Replication lag alerting that fires before the application notices.
- Every upgrade path tested on a restored copy of production before it touches production.
What we would build, and where the weak point is
The consensus store (etcd/Consul) is as critical as the database itself — lose quorum there and Patroni will refuse to fail over, correctly. It gets the same backup and monitoring treatment as the primary.
marks a single point of failure we would raise with you rather than hide. Every architecture has one; the question is whether you know where it is.
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Requires partner
Application query optimisation and ORM rewriting
We deliver evidence — index proposals, EXPLAIN plans, slow-query analysis. Your developers change the code.
- Requires partner
Database migration from proprietary engines (Oracle, SQL Server, DB2)
We do the target platform and the cutover plan; schema and stored-procedure conversion needs a migration specialist alongside us.
- Out of scope
Signing as a data processor / accepting your compliance liability
Your data stays yours and your compliance framework stays yours. We supply implementation and evidence, not legal cover.
- Out of scope
Multi-region active/active for databases that cannot support it
Asynchronous multi-region active/active means conflict resolution, and that means application-level design. Where the engine cannot do it safely, we will say no.
What it looked like last time
A fintech PostgreSQL estate with 11-minute unplanned outages: Patroni + etcd quorum rebuilt across three failure domains, PITR configured and restored, measured automatic failover of 8 seconds and a documented restore completing in 14 minutes.
Anonymised under NDA. No client names, no logos, no invented metrics. Full case library on the work page.
Talk to the database engineer about your database clusters
Send us the architecture, or just describe what broke most recently. You'll get an engineer's answer, not a discovery questionnaire.
Talk to a database engineer: botonwa@gmail.com · +86 130 5181 3099