O dbSlice começou a ser vendido em 2026, mas não começou ali. Ele foi feito pela Thinwork, a partir de uma necessidade real: implantar o ERP da Thinwork e prestar consultoria em projetos de dados muito grandes para grandes empresas. Esses projetos pediam sempre as mesmas três coisas: exportar dados, replicá-los e mantê-los sincronizados, de um banco para outro e entre ambientes. O dbSlice é a ferramenta que saiu desse trabalho. Ele roda em produção de missão crítica há mais de seis anos, movendo e sincronizando dados todos os dias. Os dados e os nomes dos nossos clientes são privados; por isso, as histórias abaixo não têm nomes. Os números são reais, e cada um vem com as suas condições.
História 1: 12,96 bilhões de linhas para um novo microsserviço
A situação. Uma empresa com 20 anos de pedidos de compra estava levando esse histórico para o banco de um novo microsserviço. O microsserviço se integra ao Salesforce. A origem era uma tabela de produção em uso: 40 colunas e 9 índices, três deles em colunas de data e três em colunas de texto.
O que o dbSlice fez. Copiou os dados de banco para banco. A integração com o Salesforce é trabalho do próprio microsserviço, não do dbSlice. O dbSlice leu a origem página a página, pela chave, com leituras e gravações sobrepostas.
O resultado. 12,96 bilhões de linhas em 1 dia, 16 horas e 40 minutos, cerca de 88.500 linhas por segundo em média. A rede e os dois bancos foram ajustados para a carga. Numa configuração comum, os números são menores: veja as condições e um segundo número, sem ajuste (em inglês).
História 2: seis anos de sincronia diária entre data centers
A situação. Uma grande operação roda seus sistemas em vários data centers e servidores on-premises, em SQL Server, PostgreSQL, Amazon Aurora e InterSystems Caché/IRIS. Os dados precisam ficar consistentes entre esses sistemas todos os dias.
O que o dbSlice faz. Roda ali em produção há mais de seis anos: jobs agendados que mantêm as cópias sincronizadas.
Um desses fluxos mantém o PostgreSQL alimentado a partir do SQL Server. Dezenas de jobs noturnos rodam no modo Upsert: as linhas novas são inseridas e as alteradas são atualizadas pela chave. Eles rodam pela linha de comando, agendados no Agendador de Tarefas do Windows. O dbSlice substituiu uma ferramenta paga que fazia esse trabalho antes.
História 3: um banco Oracle de produção alimentando um BI em SQL Server
A situação. O sistema principal de uma empresa rodava em Oracle, em produção, com alto volume e alta disponibilidade. Uma equipe de análise separada mantinha um ambiente de BI em SQL Server. Esse BI precisava de um conjunto de tabelas-base e de cinco views do banco de produção para montar os relatórios gerenciais.
O que o dbSlice fez. Copiou essas tabelas e views do Oracle para o SQL Server num agendamento, lendo a origem de produção sem pará-la. Os relatórios eram críticos; então uma cópia que falhasse ou ficasse incompleta precisava aparecer na hora.
Todos os dias, uma carga completa atualizava a cópia do BI: as tabelas de destino eram esvaziadas e carregadas de novo a partir da produção.
História 4: retaguarda em SQL Server para um portal PHP em MySQL
A situação. A retaguarda de uma distribuidora rodava em SQL Server: produtos, suprimentos e estoque. Um novo portal de vendas foi feito em PHP sobre MySQL. Os preços passavam por um fluxo de aprovação; então o portal não podia mostrar um valor errado.
O que o dbSlice fez. Converteu as tabelas de produtos e de estoque do SQL Server para o MySQL e manteve o portal alimentado a partir da retaguarda.
Depois da conversão única, um Upsert diário manteve o portal em dia: os produtos novos eram inseridos e os preços e estoques alterados eram atualizados pela chave.
História 5: equipes de campo sem conexão
A situação. Uma empresa com operações de campo em áreas remotas usa o ERP da Thinwork. Cada região onde ela atua tem o seu próprio escritório de contabilidade, que precisa dos seus dados. As equipes de campo trabalham onde o 4G e o Wi-Fi são ruins, e registram os dados de campo em tablets.
O que o dbSlice faz. Ao lado do ERP, envia a cada escritório de contabilidade os seus dados. Ele também exporta arquivos SQLite que são carregados nos tablets antes do trabalho de campo. Quando as equipes voltam, os dados de campo voltam para o banco central.
O dbSlice também faz essa volta: lê os arquivos SQLite dos tablets e grava os dados de campo no banco central.
História 6: dados antigos em SQLite e Firebird a caminho do PostgreSQL
A situação. Uma empresa que estava trocando um ERP antigo (hoje ela usa o ERP da Thinwork) tinha o histórico dividido: os dados mais antigos em SQLite e os mais novos já levados para o Firebird. Esse banco agora está sendo refatorado para o PostgreSQL.
O que o dbSlice fez. Com o dbSlice, planejar e rodar a primeira migração levou cerca de 20 horas de trabalho. A estimativa da equipe com scripts escritos à mão, cargas e conversões era de vários dias. É a estimativa de um projeto, não um benchmark.
O que estas histórias não dizem
- O dbSlice roda em lote, não em tempo real. Estes jobs rodam num agendamento.
- A sua vazão vai ser outra. Ela depende de volume, rede, bancos, largura das linhas e ajustes.
Vai substituir um sistema e precisa de ajuda para desenhar a convivência? A Thinwork pode tocar o projeto com você.
Avalie a sua migração de graça · Baixe a versão gratuita na Microsoft Store
Atualizado em