One Database Table Instead of Two: BC29’s Quiet Performance Fix

Not every feature in a release wave shows up in a headline. This one doesn’t even share a category with the AL platform notes everyone skims — it’s the sole entry under “Service and platform” in the Update 29.0 preview overview, easy to scroll past if you’re not looking for it. It shouldn’t be — it changes something that affects practically every Business Central environment running third-party apps or custom extensions, whether anyone touches AL code there or not.

What Actually Changes

Until Update 29.0, table extension fields didn’t live in the base table’s own SQL table. Business Central 2023 release wave 2 (version 23) had already consolidated things once: instead of one separate SQL table per table extension, all table extensions on a given table were combined into a single shared “companion table”. According to Microsoft’s own developer performance guidance, that still meant at most one SQL join to combine the companion table with the base table whenever extension fields were needed alongside the base table’s own fields — down from potentially several joins in versions before 2023 release wave 2, when each table extension still lived in its own separate table.

With Update 29.0, that changes: all fields of an AL table — base table and its extensions alike — land in the same underlying database table. According to Microsoft’s official preview overview, the result is noticeably faster database operations on anything involving table extensions.

Why the Old Model Cost You Something

The separate-table approach made sense architecturally — it kept extension data cleanly isolated from base table schema, which mattered for upgrade safety and multi-tenant isolation. But it also meant every read or write touching both base and extension fields required at least that one companion-table join behind the scenes, on every operation, for the entire lifetime of the extension. In an environment with a handful of PTEs and a couple of AppSource apps, each adding their own fields to commonly-used tables like Customer or Sales Line, that join overhead accumulates — not dramatically on any single query, but consistently, across everything.

By implication, collapsing base and companion-table fields into one physical table removes that remaining join: reads and writes touching extended fields become native operations on a single table instead of a join across two.

Who This Actually Affects

If you’re an AL developer, this is interesting on its own. If you’re not, it’s still relevant, because the population it touches is enormous: practically every BC environment running any third-party app or any custom PTE has table extensions somewhere, usually on high-traffic tables. In my experience, that’s not a niche configuration — stock BC with zero extensions is the exception, not the rule, among the environments partners actually run.

For partners running BC with clients on larger extension footprints — multiple AppSource apps stacked on top of core tables, or a substantial custom PTE — this is a legitimate, if quiet, performance story. It won’t show up as a feature a client asks about by name. It will show up as “the system got faster” without anyone changing their own code, which is a good thing to be able to explain when a client notices and asks why.

What to Check Before GA

This is a Preview feature under Microsoft’s Supplemental Terms of Use, with GA scheduled for the first week of October 2026 alongside the rest of Update 29.0 — no separate timeline for this specific change. Before recommending anything to a client based on it, worth verifying in the sandbox: whether existing table extensions migrate to the new model automatically or need a data upgrade step, and whether the performance gain is measurable on your specific extension footprint rather than assuming it applies uniformly. A table extension with two extra fields on a low-traffic table won’t feel the difference the way a heavily extended Sales Line table will.

If you manage upgrades for clients with substantial AppSource or PTE footprints, this is worth a spot check in the v29 sandbox now — not because it’s urgent, but because “why did this get faster” is a much better conversation to have prepared for than reactive.

Source

Source: Update 29.0 public preview for Business Central 2026 release wave 2, Microsoft Learn (live-checked 2026-09-07). Feature: “Faster data loading with improved data model for table extensions”, category “Service and platform”. On the previous “companion table” model and its join history: Performance articles for developers – AL performance patterns, Microsoft Learn (live-checked 2026-09-07).