Dolt adds wildcard filters so MySQL replicas can skip table families

Why it matters

Wildcard filters lower the cost of adding Dolt beside an existing MySQL or MariaDB system: teams can select the data they need and gain versioned history without first migrating the application.

DoltHub added wildcard table filters to Dolt's MySQL binlog replication in version 2.3.5, letting operators replicate selected families of tables or exclude them from a replica. The feature, described in a DoltHub blog post published on September 23rd, followed a user's request and, according to DoltHub, shipped in less than a week.

For founder and CEO Tim Sehn, the change fits the product's long-running pitch: bring version-control workflows to data without asking customers to replace their database on day one. Dolt can connect to an existing MySQL or MariaDB primary, receive its binlog events and turn selected transactions into versioned commits. A team can add queryable history and diffs while leaving its application on the existing database.

That incremental path is important for a database product asking teams to trust it with production data. A full migration is a large operational decision; an additional replica can be a narrower one. The new filters make that replica more useful when it only needs a subset of the source's tables.

A smaller replica, with Dolt history

Dolt already supported exact-table replication filters. Version 2.3.5 adds MySQL-compatible REPLICATE_WILD_DO_TABLE and REPLICATE_WILD_IGNORE_TABLE rules. The first admits row changes from matching tables and excludes unmatched tables. The second replicates normally while skipping tables that match a pattern.

The patterns use a database name and table name separated by a period. % matches a sequence of bytes and _ matches one byte, so an underscore meant literally must be escaped. A pattern such as sales.orders% can select tables whose names start with orders in the sales database. That is simpler to maintain than a growing list of exact table names when a dataset is split across a family of tables.

The use cases DoltHub describes include analytics replicas, service-specific read models, regional data sets and replicas that can omit scratch or archive tables. In the company's demonstration, a MySQL source sends row events for two breakroom case tables to Dolt while row changes in an employee-alibis table and a snack-inventory table are skipped. The playful lunch-theft scenario shows a useful boundary: a filter can restrict which rows arrive, while Dolt records the transactions it does receive in its own history.

Dolt's diagram shows matching row events reaching the versioned replica while other row events are skipped.

There are operational limits. The filters apply to row events, so DDL such as CREATE TABLE is still sent to the replica. They also affect new row events; they do not remove data already on the replica, which means an initial snapshot must be scoped separately. And Dolt's documentation in the post says filters set with CHANGE REPLICATION FILTER must be applied again after a server restart. Those details matter for operators treating a filtered replica as a carefully bounded data copy.