CDC for Tables Without Primary Keys
Replicate tables that lack a primary key by overriding it with a unique index, including composite indexes, with index column order preserved.
Some tables are weird. No primary key (PK), maybe just a unique index or some composite hack someone added in 2017. Until now, those were off-limits for replication.
You can now override PK requirements by specifying a unique index - including composite indexes. Artie will respect the exact column order to ensure optimal performance.
Why index-based PK overrides matter:
Not every table has a clean PK. Some use unique indexes or composite keys that aren’t formally declared as PKs. Until now, these tables were difficult (or impossible) to replicate. This change addresses one of the most common blockers for CDC at scale.
What’s changed:
- PK override: Define row identity with a unique index
- Use composite keys - even if unofficial or unenforced
- Preserve the exact index column order – it affects how changes are captured and impacts query performance during replication (e.g.,
email,account_id,created_at)
This unlocks flexible replication for legacy systems, denormalized tables, and high-volume sources - without compromising performance.
When to use index-based keys:
- Your table lacks a formal PK, but has a unique constraint or index
- You rely on composite keys to identify rows
- You’re dealing with legacy systems or data models that weren’t built with CDC in mind
How to enable key overrides:
Reach out to enable key overrides - we'll help define your index logic and validate it during setup.