DEV Community: dbslice

Edge Read Slices: Take Read Load Off Your Central Database

dbslice — Fri, 30 Oct 2026 18:44:26 +0000

In many companies a single SQL Server or PostgreSQL database answers every read: microservices, web and
mobile apps, branches and point-of-sale terminals. As usage grows, reads compete with writes, and the central
database becomes the bottleneck for everyone.

This video shows a practical pattern: keep writes on the central database and move read-only slices of
the data to where they are used, in SQLite, PostgreSQL or MariaDB, refreshed by dbSlice on a schedule.

Who it is for

Architects looking for a way to cut read traffic on the central database without rewriting the apps.
Teams running branches or terminals that need local data, even when the link to headquarters is slow.
DBAs who want the copy to be a scheduled job with a log, not a script someone has to remember.

What the video shows

One synchronization per slice. A WHERE filter per branch, a key column, Upsert, and an incremental column such as updated_at that brings only the rows changed since the last run.
Reference tables with the Replicator. Tables every branch needs in full are copied in foreign-key order.
Automation. The same job.json runs from the Windows command line (with Task Scheduler) or on a cron schedule in the Linux Server Edition (Docker), with run history and webhooks on success or failure.
Checks. Structure compare and key-by-key Record Diff show whether the slice matches the source.
Dev and test. Copies for development can have sensitive columns masked while they are written.

Honest notes

This is not real-time replication: local data is as fresh as your schedule. The incremental column brings
inserts and updates, not deletes, so plan a periodic full reload of each slice. And measure performance on
your own data before you size the schedule.

The written guide, with the setup step by step, is in
SQLite at the edge. For scheduling jobs from the command line, see
database sync from the CLI. The free version is on the
Microsoft Store.

Originally published on the dbSlice blog. dbSlice is a Windows app for data migration, replication and sync between the leading databases.

dbSlice in 3 Minutes: Migrate, Replicate and Sync Data

dbslice — Fri, 30 Oct 2026 18:39:40 +0000

Most teams that move data between databases end up with a toolbox: one product per engine, a script for the
nightly copy, another for comparing the two sides, and something else to push changes to an API or a queue.
This three-minute video shows how dbSlice puts those jobs in one Windows app and one Linux edition, under one
license.

Who it is for

DBAs and SREs who keep a copy of production up to date and need a job they can schedule, log and rerun.
Teams replacing a system that must run old and new databases side by side for months.
Product owners who need data moved without a developer writing a one-off script.

What the video shows

The tour runs on real screens:

Migrate, replicate, compare and sync across the leading databases: SQL Server, PostgreSQL, Oracle, MySQL, MariaDB, Firebird, SQLite and InterSystems Caché/IRIS, with MongoDB, Cassandra, Elasticsearch, Couchbase and Redis as NoSQL targets.
Synchronize, with five modes, from a full copy to only the rows that changed.
The Replicator, which copies a whole set of tables in foreign-key order.
Compare and Record Diff, to check both sides key by key.
Selective masking, so a test copy does not carry real customer data.
Export, Send Data and command-line jobs: files, REST APIs, message brokers, and jobs you can run from Task Scheduler or cron.
The Linux Server Edition, which runs in a Docker container on your own servers, with several users and sessions in parallel.

Why one tool matters

When migration, sync and comparison live in different products, each one has its own connection settings,
its own logs and its own idea of what a "key" is. In dbSlice, the Synchronize tab, the Replicator and the
command-line jobs share the same engine. A run you test in the app behaves the same way when it runs at
night on a schedule.

Try it

The free version is on the
Microsoft Store. To see how a long-running coexistence
project works in practice, read data coexistence. For speed, with the
conditions behind each number, see how fast is dbSlice.

Originally published on the dbSlice blog. dbSlice is a Windows app for data migration, replication and sync between the leading databases.

How to Read a Database Sync Speed Number

dbslice — Fri, 30 Oct 2026 18:16:53 +0000

"Millions of rows per minute" appears on many product pages, including ours. Before you plan a cut-over
weekend around a number like that, it is worth asking what was actually measured. These five questions apply
to any tool, and they are the same ones we answer on our own performance page.

1. Which mode?

An initial load into an empty table is the easiest case: no lookups, no conflicts, just bulk inserts. An
upsert has to find each key on the target and decide between insert and update. "New rows only" and
incremental modes depend on how fast the target can tell what is missing. A number from one mode says little
about another. In our lab, the same PostgreSQL target was 66 to 118 times faster at upsert and "new rows only"
with one option turned on, while the initial load did not change at all.

2. Which engines, and where?

SQL Server to SQL Server on the same host is not the same job as SQLite on a laptop to Azure SQL in another
region. Ask for the source, the target and where each one ran.

3. What about the network?

Over a WAN link, the network is often the slowest side. A tool that reads and writes at the same time, as
dbSlice does, moves at the pace of whichever side is slower, so the same job can be fast on one link and slow
on another.

4. How wide are the rows?

A table of three integer columns and a table with long text and binary columns can differ by an order of
magnitude in rows per second while moving similar bytes. If the benchmark does not say, assume narrow rows.

5. Was anything tuned?

Indexes dropped during the load, a bigger log, a dedicated network: all legitimate, and all worth knowing.
Our largest run, 12.96 billion rows in about 41 hours (≈88,500 rows/s on average), came from a live production
table of purchase orders with 20 years of history, 40 columns and 9 indexes, migrated into the database of a
new microservice that integrates with Salesforce; the network and both databases were tuned for the load. Next to it we publish a plain-setup number: 31.4 million rows into Azure SQL in
about 30 minutes (≈17,200 rows/s), initial-load mode, SQLite source on a local disk.

The only number that counts

Is the one from your own tables, on your own network. Run the job you plan to run, in the mode you plan to
use, and time it. The free version of dbSlice is on the
Microsoft Store; the numbers and conditions we measured are
on how fast is dbSlice, and the video walkthrough is in
12.96 billion rows in 41 hours.

Originally published on the dbSlice blog. dbSlice is a Windows app for data migration, replication and sync between the leading databases.

DEV Community: dbslice

Edge Read Slices: Take Read Load Off Your Central Database

Who it is for

What the video shows

Honest notes

Read more

dbSlice in 3 Minutes: Migrate, Replicate and Sync Data

Who it is for

What the video shows

Why one tool matters

Try it

How to Read a Database Sync Speed Number

1. Which mode?

2. Which engines, and where?

3. What about the network?

4. How wide are the rows?

5. Was anything tuned?

The only number that counts