Changelog

November 2026

1. CONNECTORSNOVEMBER 2, 2026READER V0.1.640

   Bring your own CA and client certificates for MySQL sources

   MySQL and MariaDB source connectors accept a CA certificate for servers signed by a private root, and a client certificate and key for servers that require mutual TLS.

   Read more: Bring your own CA and client certificates for MySQL sources

   Artie verified a MySQL server's certificate against the system's trusted roots, which is fine for a public CA and useless for a private one. Google Cloud SQL is the common case: every instance has its own CA, and its server certificate is named after the project and instance rather than the host, so verification could never pass. Servers that require a client certificate had no way to get one from Artie at all.

   The MySQL source form, which MariaDB uses too, now has three optional PEM fields once TLS mode is set to required: a CA certificate, a client certificate, and a client key. With a CA certificate, Artie verifies the server's certificate chain against it, the way MySQL's VERIFY_CA does, and skips the host name check, so use a CA dedicated to that server. Without one, host verification against the system roots runs as before. A client certificate and key go in together, and the key is encrypted at rest and masked in the API and the activity history.

   A related fix for anyone connecting through an SSH tunnel: Reader reaches the database as localhost through the tunnel, so TLS host verification compared the certificate against the wrong name and failed even though the connection test passed. The Dashboard now hands Reader the real endpoint host to verify against. IPv6 database hosts are also built correctly now, as [2001:db8::1]:3306 rather than an unparseable string.

   This is for MySQL and MariaDB teams whose servers use a private certificate authority or require client certificates.

   Why this matters

   • Connect to Cloud SQL and other servers with a per-instance or private CA without turning verification off
   • Meet a mutual TLS requirement from the connector form, with the key stored encrypted
   • TLS verification through an SSH tunnel checks the real host, not the tunnel's localhost

2. RELIABILITYNOVEMBER 2, 2026TRANSFER V1.29.314

   Delta Lake deduplication keeps the update timestamp on rewritten rows

   Rows rewritten during Delta Lake deduplication no longer lose __artie_updated_at, so later deduplication runs can still tell which duplicate is newest.

   Read more: Delta Lake deduplication keeps the update timestamp on rewritten rows

   When Artie deduplicates a Delta Lake table, it rewrites the surviving rows after stripping its own bookkeeping columns. That strip was too eager: it also removed __artie_updated_at, so every rewritten row came back with a null update timestamp. The timestamp is what deduplication uses to decide which of two duplicates is newer, and a null always loses, so a later run could no longer order the rows it had already cleaned against new duplicates and could keep the wrong one.

   Deduplication now keeps __artie_updated_at on every row it rewrites. Only __artie_only_set_delete, and __artie_delete when soft deletes are off, are stripped. Rows that already lost their timestamp in an earlier run are not repaired retroactively.

   This is for teams running Artie deduplication on Delta Lake destinations.

   Why this matters

   • Last-write-wins deduplication keeps picking the newest row across runs
   • Downstream logic that reads __artie_updated_at sees a value on every row going forward

3. CONNECTORSNOVEMBER 2, 2026

   Export DynamoDB tables to an S3 bucket in another AWS account

   The DynamoDB backfill form takes an optional bucket owner account ID, so an export to a bucket owned by a different AWS account no longer fails with access denied.

   Read more: Export DynamoDB tables to an S3 bucket in another AWS account

   A DynamoDB backfill works by asking DynamoDB to export the table to S3, then reading the export files. When that bucket belongs to a different AWS account than the table, DynamoDB refuses the export with an access denied error unless the request names the bucket's owner, and Artie had nowhere to put that.

   The DynamoDB backfill form now has a Bucket owner account ID field. Enter the 12-digit AWS account ID that owns the bucket when it is not the account the table lives in, and leave it blank for a same-account bucket. The value is used when the export starts rather than saved on the pipeline, so enter it each time you start a cross-account backfill. Your data plane needs to be on dataplane-api v0.1.503 or later for the field to take effect; older data planes ignore it.

   This is for DynamoDB teams whose export bucket lives in a central or separate AWS account.

   Why this matters

   • Cross-account exports work without moving the bucket or the table
   • Same-account backfills are unchanged

4. PRODUCTNOVEMBER 2, 2026

   Export pipeline metrics to New Relic, CloudWatch or any OTLP endpoint

   A new OpenTelemetry integration sends Artie's pipeline metrics to New Relic, Amazon CloudWatch, or any OTLP/HTTP endpoint, with pipeline, table, source, destination and environment attributes attached.

   Read more: Export pipeline metrics to New Relic, CloudWatch or any OTLP endpoint

   Artie's pipeline metrics could reach Datadog and Grafana. Teams standardised on New Relic, CloudWatch, or an OpenTelemetry collector had to watch pipeline health in the Artie Dashboard instead of where the rest of their alerting lives.

   Settings now has an OpenTelemetry integration. Pick New Relic (US or EU endpoint, authenticated with your license key), Amazon CloudWatch (commercial regions, authenticated by an IAM role you create with the trust policy and cloudwatch:PutMetricData permission the connect dialog shows, plus an external ID), or any other OTLP/HTTP endpoint with custom headers. Header values and keys are encrypted at rest, the endpoint has to be HTTPS on port 443, and connecting runs a live export before saving. The existing Grafana integration moved into the same row and is unchanged.

   The metrics are the same six Artie already exports elsewhere: rows processed, ingestion lag, row lag, flush time, flush count and replication slot size, each tagged with pipeline, environment, source, destination, table and operation. Counts are sent as one-minute deltas and gauges as raw points with their original timestamps, and delivery is at-least-once, so a retried request can occasionally repeat a point. Only one metrics destination can be connected at a time besides Datadog, and connecting it needs a company admin.

   This is for teams whose dashboards and alerting live in New Relic, CloudWatch, or an OpenTelemetry pipeline.

   Why this matters

   • Alert on pipeline lag and throughput where your on-call already looks
   • CloudWatch access is a scoped IAM role, with no Artie credentials to rotate
   • The same metrics and attributes as Datadog and Grafana, so dashboards port over

   Monitoring integrations docs

5. PRODUCTNOVEMBER 2, 2026

   Managed Kafka preview: create, size and operate clusters from the Dashboard

   Companies in the Managed Kafka preview can now create real clusters from the setup flow, resize them from the cluster page, and let storage autoscaling grow disks before they fill.

   Read more: Managed Kafka preview: create, size and operate clusters from the Dashboard

   Artie-managed Kafka is in preview with a set of invited companies. Until now the setup flow stopped short of actually provisioning, and changing a running cluster's capacity meant asking us.

   The setup flow now creates a real cluster and follows its deployment in the Dashboard, from Deploying through to the broker address, allowed IPs and next steps. The Review step shows a priced estimate before you create: Artie's fee applies to compute only, while disks, tiered storage and traffic pass through at AWS prices, and the estimate now itemises the load balancer and public IP. Setup autosaves to a company-wide draft, so a teammate can pick up where you left off from a Draft card on the Kafka page.

   Once a cluster is running, company admins change its allowed IP ranges, broker storage, broker count and instance type from the cluster page. Storage grows but never shrinks, brokers can be added but not removed, and one change applies at a time; the page shows Applying or Didn't apply with a Try again. Storage autoscaling is on by default for new and existing clusters: when a broker disk reaches 65% full, Artie grows it so disks land around 55% full, emails admins each time it does, and admins can tune the thresholds, set a per-broker ceiling, or turn it off under Settings. Tiered storage is also configurable per cluster and per topic, with a slider for how many days stay on broker disks before older messages move to object storage.

   Spend is guarded on Artie's side rather than yours: a create, restore or cost-increasing edit that would push a cluster past its monthly limit is refused with a message to contact us, and the same applies to a company-wide ceiling and a cap on clusters per company. Edits that do not raise the estimate always go through, and storage autoscaling is not counted against the limits.

   This is for companies in the Managed Kafka preview who want to run clusters without a ticket for every change.

   Why this matters

   • Provision a cluster and watch it come up from one flow, with the price in front of you first
   • Resize capacity and network access yourself, with clear applying and failed states
   • Disks grow before they fill, and runaway spend is stopped before it is billed

6. RELIABILITYNOVEMBER 2, 2026READER V0.1.645

   MySQL pipelines no longer stop on administrative statements, and track more schema changes

   Reader ignores binlog statements that do not change table schemas instead of halting on them, and now follows ALTER TABLE ... ADD with indexes, table renames, and more type spellings.

   Read more: MySQL pipelines no longer stop on administrative statements, and track more schema changes

   Artie's MySQL reader parses every query event in the binlog to keep its picture of each table's schema current. A statement it did not recognise stopped the pipeline with unsupported context type, even when the statement had nothing to do with table schemas. And a few statements it thought it recognised were handled wrong: an ALTER TABLE ... ADD (...) that declared a column alongside an index was ignored, so later rows were read with the old column list, and ALTER TABLE t1 RENAME TO t2 was dropped, so every row written to the renamed table was silently skipped.

   Reader now ignores statements that cannot change a table's columns: SAVEPOINT and LOCK TABLES, XA transactions, ALTER VIEW and ALTER PROCEDURE, CREATE and DROP ROLE, tablespace, server and NDB logfile group DDL, ALTER INSTANCE, and replication-control statements such as PURGE BINARY LOGS. XA transactions are also treated as transaction boundaries, so an offset is never committed partway through one. Mixed ADD (...) statements now add their columns, and a table-level PRIMARY KEY (...) in the same statement is picked up too; indexes and other constraints are skipped, as they are for CREATE TABLE. Renames are tracked, including RENAME TABLE and a rename combined with ADD COLUMN. Standard-SQL spellings such as NVARCHAR, NCHAR and CHARACTER VARYING no longer stop the stream, a size suffix like AUTOEXTEND_SIZE=4M no longer causes a whole CREATE TABLE to be dropped, and FLOAT(25) through FLOAT(53) is now read as a double rather than overflowing a 32-bit float.

   Two notes. Statements outside this list that Reader does not recognise still stop the pipeline, by design, so a schema change is never silently missed. And if you have a FLOAT(p>24) column, rows streamed before this fix may hold float32-rounded values and the field type changes from float to double on the next schema event; a resync of that table is the clean fix.

   This is for MySQL and MariaDB CDC pipelines whose databases see DBA activity, migration tools, or XA transactions alongside normal writes.

   Why this matters

   • A SAVEPOINT, LOCK TABLES or key rotation in the binlog no longer takes your pipeline down
   • Columns added alongside an index, and tables that get renamed, keep replicating
   • Unrecognised schema statements still fail loudly rather than being skipped

7. RELIABILITYNOVEMBER 2, 2026READER V0.1.637

   Oracle CDC no longer leans on your database's memory for large transactions

   Reader now tracks open Oracle transactions itself and publishes each one in commit order, instead of asking LogMiner to hold every uncommitted change in the instance's PGA.

   Read more: Oracle CDC no longer leans on your database's memory for large transactions

   Artie mined Oracle redo with LogMiner's COMMITTED_DATA_ONLY option, which is convenient because the database only hands back committed changes. The cost is hidden: Oracle keeps every open transaction in the mined range in its own process memory until it commits or rolls back, whatever table it touches, and that memory cannot be capped. One large batch job was enough to push an instance past PGA_AGGREGATE_LIMIT and fail with ORA-04036, taking down more than the pipeline. In a reproduction under a 2 GB limit, a million-row transaction cost the session about 1.5 GB on the old path and 26 MB on the new one.

   Reader now mines without COMMITTED_DATA_ONLY and does the bookkeeping itself. It holds each open transaction's changes, spilling the largest to disk on the pipeline's volume once the in-memory budget passes 64 MB, and publishes a transaction whole and in commit order the moment it commits. Rolled-back transactions are dropped, and undo records from a rollback to savepoint or a failed statement are matched to the changes they undo, so none of that work reaches your destination. The streaming offset now carries both a restart SCN and a commit SCN, so a restart resumes from the first change of the oldest open transaction without re-sending commits it already published. Because LogMiner reads only redo that has reached disk, the mining window trails the database by about ten seconds.

   Several Oracle failures were fixed alongside. Pipelines connected to a pluggable database now mine from CDB$ROOT, which clears ORA-65040 on multitenant databases. Mirrored redo log groups no longer fail with ORA-01289. A transaction larger than the fetch batch no longer crash-loops the reader. Backfills keyed on a unique index that includes a nullable column page correctly, and NUMBER(*,s) columns no longer fail setup with a missing-precision error.

   This is for Oracle teams with large or long-running transactions, multitenant databases, or mirrored redo logs.

   Why this matters

   • A big transaction no longer threatens the Oracle instance's memory limit
   • Every change arrives once, in commit order, and rolled-back work never arrives at all
   • Multitenant and mirrored-redo setups replicate without manual workarounds

8. PRODUCTNOVEMBER 2, 2026TRANSFER V1.29.308READER V0.1.636

   Rebuild and swap backfills come to Databricks

   Reload a live Databricks table without an empty or half-loaded window: Artie backfills into a copy, then replaces the table's rows in a single Delta commit.

   Read more: Rebuild and swap backfills come to Databricks

   Rebuild and swap, the backfill mode that keeps a live table queryable while it is reloaded, was Snowflake-only. Databricks teams reloading a table that notebooks, jobs or dashboards read from still had to choose between an empty table and a mix of old and new rows during the load.

   Rebuild and swap is now offered for Databricks destinations in both backfill dialogs. Databricks has no SWAP WITH, so the mechanics differ from Snowflake: Artie creates the rebuild table with CREATE TABLE ... LIKE, loads the backfill into it, adds any columns that appeared during the load, then replaces the live table's rows in one Delta commit with INSERT OVERWRITE. The destination stays the same Delta table throughout, which is why grants, owner, tags, comments, constraints, clustering, dependent views and table history all stay in place. The previous rows remain reachable through Delta time travel (VERSION AS OF or RESTORE TABLE) until the next VACUUM, and the Keep the old table for rollback option deep-clones the current rows to a holding table first, so a rollback never depends on retention.

   Tables with an identity column cannot be rebuilt this way, since the reload would renumber them; Artie names those tables and rejects the backfill before it starts. As on Snowflake, the mode is enabled per account; ask us to turn it on.

   This is for teams that need to refresh a Databricks table while the people and jobs reading it keep working.

   Why this matters

   • Readers see either the old rows or the new rows, never a partial reload
   • Nothing attached to the table needs re-applying, because the table itself is never replaced
   • Old rows stay a time-travel query away, or in a kept copy, for rollback

9. PRODUCTNOVEMBER 2, 2026TRANSFER V1.29.306

   Rebuild and swap keeps automatic clustering on in Snowflake

   A Rebuild and swap backfill now resumes automatic clustering on the rebuilt table before the swap, so you no longer need to run RESUME RECLUSTER yourself afterwards.

   Read more: Rebuild and swap keeps automatic clustering on in Snowflake

   When we introduced Rebuild and swap backfills for Snowflake, we noted one chore: Snowflake suspends automatic clustering on a clone, and Artie left it that way, so a table that had been auto-clustering came out of the swap suspended until you ran ALTER TABLE ... RESUME RECLUSTER yourself.

   That caveat is gone. Before swapping, Artie checks whether the live table has a clustering key with automatic clustering on, and if so resumes clustering on the rebuilt table first; the setting then travels with the table through the swap. A table with no clustering key, or one where you suspended clustering on purpose, is left exactly as it was. If the lookup or the resume fails, the swap does not happen and the live table is untouched, so the backfill can simply be retried.

   Streams defined on the table still do not carry over to the rebuilt table and need recreating after the swap.

   This is for Snowflake teams using Rebuild and swap on tables with automatic clustering.

   Why this matters

   • No post-swap step to remember; clustering stays on
   • Tables you deliberately left unclustered are not touched
   • A failed resume never leaves the live table half swapped

   Rebuild and swap docs

10. CONNECTORSNOVEMBER 2, 2026

    Snowflake as a source is available on every plan

    The Snowflake source connector is out of its per-company rollout: any workspace, including self-serve and free plans, can now pick Snowflake when creating a pipeline.

    Read more: Snowflake as a source is available on every plan

    Snowflake as a source shipped in October behind a per-company flag, so using it meant asking Artie to turn it on first. That kept it out of reach for self-serve and free workspaces entirely.

    The flag is gone. Snowflake now appears in the source list for every plan, and setup is the same as it was during the rollout: a read-only service user that signs in with key-pair authentication, change tracking turned on for each table you replicate, and at least one day of Time Travel retention. Artie snapshots each table once, then reads its changes every five minutes with a per-table cursor, so an outage or restart resumes exactly where it left off.

    One thing to plan for if you use dbt: a table model that runs CREATE OR REPLACE TABLE on every run drops the change history and leaves the new table without change tracking, and Artie stops that table with an error rather than silently skipping changes. Use incremental materializations for tables Artie replicates.

    This is for teams whose system of record, or a slice of it, lives in Snowflake and needs to land somewhere else with ongoing changes.

    Why this matters

    • No request to Artie needed; Snowflake is a source on self-serve and free plans too
    • The same snapshot-then-stream model Artie uses for operational databases, with a cursor per table
    • Missing change history stops the pipeline loudly instead of producing a quietly incomplete destination

    Snowflake source docs