O DBBridge traduz schema (e dados) entre 12 bancos SQL e NoSQL usando uma representação intermediária canônica — não um conversor escrito à mão pra cada par de bancos. Biblioteca open source com 1.550+ testes, ou a versão em nuvem com IA se você não quiser gerenciar infraestrutura.
Honesto sobre o estado de cada integração — o que é execução real validada e o que ainda é blueprint/simulação.
| Banco | Parser / Renderer | Compatibility Mode |
|---|---|---|
| SQLite | ✓ | ✓ |
| PostgreSQL | ✓ | ✓ |
| MySQL | ✓ | ✓ (via pymysql) |
| DuckDB | ✓ | ✓ (arquivo .duckdb real) |
| Snowflake | ✓ | ✓ (conta real) |
| SQL Server | ✓ | ✓ (pyodbc) |
| Oracle / DB2 | ✓ | integração em progresso |
| MongoDB | blueprint + simulação | simulação real via PyMongo |
| Neo4j / Cassandra / OpenSearch | semântico → Cypher/CQL/mapping | execução real validada por checksum |
Origem → parser do dialeto → representação intermediária → renderer do destino. Migrar SQLite→Postgres usa o mesmo motor que SQL→grafo.
Além da sintaxe, o Compatibility Mode traduz a exceção nativa de cada driver pra uma hierarquia canônica — código que trata UniqueViolationError funciona igual não importa o banco por trás.
Código procedural ou ambíguo vira REVIEW_REQUIRED em vez de tradução arriscada silenciosa.
12 sistemas: SQLite, PostgreSQL, MySQL, DuckDB, Snowflake, SQL Server, Oracle, DB2, MongoDB, Neo4j, Cassandra e OpenSearch — inclusive entre paradigmas diferentes (SQL → documento, SQL → grafo).
Sim, dbbridgekit no PyPI, licença MIT, 1.550+ testes, 88%+ de cobertura.
Não necessariamente — rode local via pip, ou use o DBBridge Cloud (mesma engine, interface web com IA, zero infraestrutura própria).
Fica marcado REVIEW_REQUIRED — o DBBridge avisa em vez de arriscar.
Roda o scan primeiro — descobre o que quebraria antes de decidir.