Bring your stack. Keep your drivers.
SynergyDB implements the wire protocols your applications already speak. The client library, the connection string style, and the queries stay the same — you change where they point. That means you can move one service at a time instead of betting the whole system on a single migration.
The protocols your code was written for
One endpoint answers many wire protocols, so a mixed stack talks to a single engine.
PostgreSQL & MySQL
Your SQL apps connect over the native protocols — simple and extended query, prepared statements, transactions. The driver doesn't know the difference.
MongoDB
Document apps talk the MongoDB wire protocol — CRUD, queries, and updates — against the same engine that stores your relational data.
Redis
Point your cache and session clients at SynergyDB's Redis-compatible interface — keys, expiry, and common commands — with no separate cache to run.
Neo4j Bolt
Graph queries run over the Bolt protocol, so relationship-heavy features use the driver they already do — no data export to a separate graph store.
Kafka
Producers and consumers use the Kafka-compatible interface to publish and read events — alongside, not bolted onto, the data those events change.
The ORMs on top
Because compatibility is at the wire, the ORMs and query builders layered above your driver — the ones your team already writes against — keep working.
Migrate one connection string at a time
Because the protocol is the same, moving a service can be as small as changing where it connects. Bring the cache over first, then a document store, then the primary SQL database — each on its own schedule, each reversible, without a big-bang cutover.
- Repoint a service instead of rewriting it
- Consolidate services onto one engine incrementally
- Roll a step back by pointing it at the old system
See it on your own stack
Bring a service and its driver, and we'll connect it to SynergyDB live and show you what runs unchanged — using sample or your own non-production data.