Product positioning

DBProxy is a lightweight database edge proxy for existing MySQL, PostgreSQL/TimescaleDB, Redis, and Valkey deployments. It is not intended to become another Vitess or to remain in front of a database platform that already owns routing, retries, failover, and shard topology.

The problem DBProxy solves

Many teams need connection control and deterministic placement before they need a distributed database control plane. Their databases may already run in RDS, Aurora, Cloud SQL, TimescaleDB, or another managed service. Their shards may correspond to tenants, regions, regulatory boundaries, or dedicated customers and change infrequently.

DBProxy fits this stage by providing:

• one Rust executable for MySQL, PostgreSQL/TimescaleDB, Redis, and Valkey;
• MySQL connection pooling and statement-level read/write routing;
• transparent PostgreSQL and Redis role routing;
• hash, range, and exact-value placement over a declared topology;
• bounded non-atomic fanout where partial completion is accepted, or constrained MySQL XA for allowlisted autocommit DML with durable per-instance recovery;
• consistent health, admission limits, operation identifiers, and metrics;
• no required topology database, operator, or per-database agent.

Run separate DBProxy deployments where protocol or tenant isolation is needed. Using the same software and operating model does not require putting every database behind one process or accepting one shared failure domain.

When to choose DBProxy

DBProxy is a reasonable choice when:

• one primary still owns writes and replicas provide enough read capacity;
• shards are predefined and movement is an intentional operational event;
• the application has a stable tenant, region, or entity shard key;
• database infrastructure must remain under an existing managed service;
• a small team values a one-command deployment and a small operational surface;
• several database protocols need comparable routing and telemetry.

DBProxy is less compelling for a single unsharded database that only needs one specialized feature. PgBouncer, ProxySQL, a cloud provider proxy, or a native Redis client may be the smaller solution for those cases.

When to choose a distributed database platform

Use Vitess for MySQL when the platform must continuously operate the shard fleet: online shard splits and merges, VReplication, traffic switching, data validation, topology management, fleet-wide failover, distributed planning, or cross-shard transaction coordination.

Multigres is the closest PostgreSQL-oriented architectural reference, with Multigateway, Multipooler, Multiorch, topology, materialization, and sharded query-serving concepts. It is still an early-stage project, so production selection requires an independent maturity and compatibility review, especially for TimescaleDB extensions.

Redis Cluster should own dynamic Redis/Valkey slot topology. Sentinel should own primary election for non-clustered replication. DBProxy can now consume Sentinel address quorum or a native Cluster slot map when a mandatory unified edge policy justifies the extra hop; it does not replace either system's provisioning, consensus, replication, or resharding control plane.

Do not double proxy by default

The normal production paths are:

application -> DBProxy -> existing database topology

or:

application -> Vitess, Multigres, or Redis Cluster

Permanently placing DBProxy in front of VTGate, Multigateway, or Redis Cluster adds latency and another failure domain while duplicating authentication, timeouts, retries, routing, and observability. Such a hop is justified only by a measured, mandatory edge policy that the underlying platform cannot provide; it is not the default DBProxy architecture.

Graduation path

DBProxy is the simple step between a single database and a full distributed database platform:

single database
    -> DBProxy pooling and replicas
    -> DBProxy deterministic sharding
    -> export, validate, and migrate routing metadata
    -> Vitess, Multigres, or Redis Cluster

Graduation should remove DBProxy from the data path. Future migration tooling may generate a Vitess VSchema draft, produce Multigres-compatible routing metadata, compare old and new shard decisions offline, and report uncovered queries. It must not silently convert topology or switch production traffic.

Decision table

The intentional boundary is part of the product: DBProxy does not need to own database provisioning, replication, or automatic resharding to be useful.

References

• Vitess architecture
• Vitess VSchema
• Vitess online resharding
• Multigres repository and maturity statement
• Multigres architecture
• Multigres MVP plan