dbSlice went on sale in 2026, but it did not start then. It was built by Thinwork, out of a real need: rolling out Thinwork's ERP, and consulting on very large data projects for large corporations. Those projects kept asking for the same three things: export data, replicate it and keep it in sync, from one database to another and between environments. dbSlice is the tool that came out of that work. It has run in mission-critical production for more than six years, moving and syncing data every day. Our customers' data and names stay private, so the stories below have no names. The numbers are real, and each one comes with its conditions.
Story 1: 12.96 billion rows into a new microservice
The situation. A company with 20 years of purchase orders was moving that history into the database of a new microservice. The microservice integrates with Salesforce. The source was a live production table: 40 columns and 9 indexes, three of them on date columns and three on text columns.
What dbSlice did. It copied the data database to database. The Salesforce integration is the microservice's own job, not dbSlice's. dbSlice read the source page by page, by key, and the reads and writes overlapped.
The result. 12.96 billion rows in 1 day, 16 hours and 40 minutes, about 88,500 rows per second on average. The network and both databases were tuned for the load. On a plain setup the numbers are lower: see the conditions and a second, untuned number.
Story 2: six years of daily sync across data centers
The situation. A large operation runs its systems across several data centers and on-premises servers, on SQL Server, PostgreSQL, Amazon Aurora and InterSystems Caché/IRIS. Data has to stay consistent between those systems every day.
What dbSlice does. It has run there in production for more than six years: scheduled jobs that keep copies in sync.
One of those flows keeps PostgreSQL fed from SQL Server. Dozens of nightly jobs run in Upsert mode: new rows are inserted and changed rows are updated by key. They run from the command line, scheduled in the Windows Task Scheduler. dbSlice replaced a paid tool that did this work before.
Story 3: a production Oracle database feeding a SQL Server BI
The situation. A company's main system ran on Oracle, in production, with high volume and high availability. A separate analytics team kept a BI environment on SQL Server. That BI needed a set of base tables and five views from the production database to build its management reports.
What dbSlice did. It copied those tables and views from Oracle into SQL Server on a schedule, reading the production source without stopping it. The reports were critical, so a failed or partial copy had to be visible right away.
Every day, a full load refreshed the BI copy: the target tables were emptied and loaded again from production.
Story 4: SQL Server back office to a PHP portal on MySQL
The situation. The back office of a distributor ran on SQL Server: products, supplies and stock. A new sales portal was built in PHP on MySQL. Prices followed an approval workflow, so the portal could not show a wrong value.
What dbSlice did. It converted the product and inventory tables from SQL Server to MySQL and kept the portal fed from the back office.
After the one-time conversion, a daily Upsert kept the portal current: new products were inserted and changed prices and stock were updated by key.
Story 5: field teams without a connection
The situation. A company with field operations in remote areas runs Thinwork's ERP. Each region where it operates has its own accounting office that needs its data. The field teams work where 4G and Wi-Fi are poor, and they record field data on tablets.
What dbSlice does. Next to the ERP, it sends each accounting office its data. It also exports SQLite files that load onto the tablets before the field work. When the teams come back, the field data goes back into the central database.
dbSlice also does that return: it reads the SQLite files from the tablets and writes the field data into the central database.
Story 6: old SQLite and Firebird data on its way to PostgreSQL
The situation. A company replacing an old ERP (today it runs Thinwork's ERP) had its history split: older data in SQLite, newer data already moved to Firebird. That database is now being refactored for PostgreSQL.
What dbSlice did. With dbSlice, planning and running the first migration took about 20 hours of work. The team's estimate with hand-written scripts, loads and conversions was several days. That is one project's estimate, not a benchmark.
What these stories do not say
- dbSlice is batch, not real time. These jobs run on a schedule.
- Your throughput will differ. It depends on volume, network, engines, row width and tuning.
Planning a system replacement and need help designing the coexistence? Thinwork can run the project with you.
Assess your migration for free · Get the free version on the Microsoft Store
Last updated