Replicator: copy many tables in one run
Pick the tables and copy them all in one run, parents before children, several tables in parallel. Use it to move a whole set of tables to another database or to refresh a test environment.
Data migration, replication and sync for the leading databases
Move the data. Keep both sides in sync. Prove they match.
Try it free — Microsoft Store ↗ See pricing →
In production for 6+ years · 14-day money-back · Runs on your machine
SOURCEsqlserver://erp.dbo.OrdersTARGETpostgres://erp.public.orders
- rows read
- 12,480,316
- rows written
- 12,480,316
- missing in target
- 0
- different values
- 0
IDENTICAL 00:04:12
keys 1027, 2210, 3348
Either side: SQL Server · PostgreSQL · Oracle · MySQL · MariaDB · Firebird · SQLite · Caché / IRIS
From first copy to cutover
-
Step 1
Migrate once
Copy tables between engines with type mapping, a key-by-key diff and on-screen checks before writing.
Migration guides →1 source · 2 target · 3 key column used to match rows -
Step 2
Keep in sync until cutover
Upsert, insert-new or incremental runs every night while the old system is still live. Legacy and new systems, on-premises and cloud, a database and a CRM — they share data for months. dbSlice keeps them in step as scheduled jobs, inside your own infrastructure.
Sync guide →Page 13: 1,300,000/1,452,372 processed Page 14: 1,400,000/1,452,372 processed Page 15: 1,452,372/1,452,372 processed Done: 1,452,372 read, 12,480 inserted, 3,911 upsert/update in 107.0s -
Step 3
Prove they match
Identify missing or divergent records, inspect column differences and export IDs for a focused correction.
Compare source and target →1 summary: 16 columns, 9 differences · 2 a column that exists only in the source -
Step 4
Cut over
Transactional batches, resume from a checkpoint, retries on transient failures, and a history of every run. One job, one schedule, one log. Resumes where it stopped and reports by e-mail and webhook.
How data coexistence works →1 Compare · 2 equal counts on source and target · 3 0 missing · 4 0 rows with different values
See the operation before you run it
Source, target, mode, mappings and progress in one screen.
Generate realistic fake data
Create mock rows from an existing table or a pasted model: names, e-mails, dates in a range, valid foreign keys and a NULL rate per column, with a seed to repeat the same set. Insert into a table or save to a file.
How synthetic data works →Reconcile keys, content and structure
Identify missing or divergent records, inspect column differences and export IDs for a focused correction.
Mask production data on the way out
Pick a treatment for each column (e-mail that keeps the domain, hidden digits, a template with the key, NULL or keep) and see the result on a sample record before the run. Keys and foreign keys are never changed, so the masked copy still joins.
Masked staging copy →Send data to APIs and message brokers
Read rows from a database, a JSON file or a CSV, map them to a JSON model and deliver each record to a REST API, Kafka, RabbitMQ and more. Preview the payload before the full run.
Assemble CLI jobs from the interface
Configure a run visually, then export the exact command and job file to schedule headless synchronization, export or clone.
Measured numbers, with their conditions
| Run | Rows | Time | Rate | Conditions |
|---|---|---|---|---|
| Copy/sync in production | 12.96 bn | 1 d 16 h 40 min | ≈88,500/s | Live production table, 40 columns and 9 indexes; network and databases tuned. Details |
| Initial load into Azure SQL | 31.4 m | ≈30 min | ≈17,200/s | SQLite source on a local disk, desktop app, September 2026, before our September and October optimizations. |
| Restore 1 million missing rows in PostgreSQL | 1 m | 10.6 s | Time before: 21 min | Temporary-table upsert option on; SQL Server 2022 → PostgreSQL 17 on the same host, lab. |
Throughput depends on volume, network, engines, row width, tuning and transformations. Your numbers will differ. Full method →
Made for production databases
Running in production for more than six years in mission-critical environments, across multiple data centers and on-premises, with SQL Server, PostgreSQL, Aurora and InterSystems Caché/IRIS. Read the customer stories →
- Environments you can't confuseDEV, QA, UAT and production are named and color-coded; dbSlice warns before an operation crosses them.
- Your database stays yoursIt reads and writes rows; it does not create objects in your databases by default.
- Protected credentialsConnection profiles are encrypted on your machine and job files carry no passwords.
- Safe runsTransactional batches, resume from a checkpoint, retries on transient failures, and a history of every run.
What touches your data
dbSlice runs where you put it: your Windows machine or server, or your own Docker. It reads the source by key in small batches and writes only rows to the target. By default it creates nothing in your databases, and dbSlice never sends database rows to Thinwork. If an unexpected error happens, you can choose to e-mail the details to support: you see the text before you send it.
Your network
Source databaseread by key, in small batches
↓
dbSliceyour Windows machine or server, or your own Docker
↓
Target databaseonly rows written; read-only asks first
By default, nothing is created in your databases: no triggers, tables or agents. dbSlice never sends database rows to Thinwork.
Leaves your network
With Thinwork, no database rows sent:
- license activation and renewal
- update check and download
- release notes list
- an error report e-mail, only if you choose to send it (you review it; an error text may quote a value)
Only if you set them up:
- e-mail (SMTP), webhook, REST API
- SOAP (and its WSDL), gRPC, broker
- your telemetry collector
The leading databases, either side
One license covers all of them. New databases arrive as regular updates. Also writes to MongoDB, Cassandra, Elasticsearch, Couchbase and Redis.
Any of these, as source or target:
- SQL Server
- PostgreSQL
- Oracle
- MySQL
- MariaDB
- Firebird
- SQLite
- Caché / IRIS
Including InterSystems Caché/IRIS and Firebird, which few migration tools cover.
Also on Linux, in Docker: the same tools in a browser, with a scheduler and an API. Linux edition →
One user. One device. Your eligible version remains yours.
Desktop Edition
US$ 89.99
1 named user · 1 activated device · one-time payment
Windows Server Edition
US$ 199.99
1 Windows Server installation · one-time payment
Linux Server Edition (Docker)
US$ 299.99 / year
1 Linux server, multiple instances (Docker) · annual subscription
See pricing and buy → Desktop and Windows Server: the license includes the Windows GUI, CLI, 12 months of updates and standard support.
Who builds dbSlice
A small team at Thinwork, a software company in business since 2007, led by Junior Oliveira (40 years in IT). Every e-mail is read by the people who build dbSlice. About Thinwork and dbSlice →
Guides
Migrate by pair
- SQL Server → PostgreSQLTypes, sequences and a sync until cutover
- MySQL → PostgreSQLLoad, types and keys
- SQL Server → MySQLLoad and type differences
- Oracle → PostgreSQLMoving Oracle tables
Sync until cutover
- Syncing a live production database without locking itReads by key, in small batches
- Sync guideNightly upsert and incremental runs
- Data coexistenceOld and new systems side by side
Prove and test
- Compare source and targetKey by key, with a report
- Masked staging copyKeys and foreign keys preserved
- Synthetic test dataRows that follow types and foreign keys