Some Business Central changes get their own keynote demo. Others happen entirely inside the database layer, described in a sentence or two of release notes, and only become visible to a developer when a query runs faster than it used to. The table extension data model change in v29 is the second kind, and I think it deserves more attention than that treatment usually gets it.
The real story isn’t a single feature in a single release. It’s a three-stage redesign that Microsoft has been executing gradually since 2023, and v29 is where it finally reaches its logical endpoint.
Where This Started: One Table Per Extension
For most of Business Central’s extension-based history, every table extension created its own separate table in SQL Server. A base table with five separate extensions installed meant six physical tables underneath it the base table plus one per extension joined together by the service tier at runtime to present a single logical record.
This worked, but it didn’t scale cleanly. Each additional extension on a table added another join to every operation involving that table. Read performance degraded gradually as the number of extensions grew, in a way that was invisible in a demo environment with one or two extensions and increasingly noticeable in a production environment with several.
The First Fix: Companion Tables in BC23
2023 release wave 2 introduced the first real restructuring. Instead of one table per extension, all extensions on a given base table were consolidated into a single companion table. A base table with any number of installed extensions went from N+1 physical tables down to exactly two the base table and one shared extension table regardless of how many extensions were actually installed.
This was a meaningful improvement, and independent testing from several Business Central MVPs at the time confirmed real performance gains, particularly as extension count increased. But it was an intermediate step, not the final architecture. Two tables still meant a join on every operation, even if it was now a fixed cost rather than one that grew with extension count.
The Second Fix: One Table, in v29
Version 29 completes the redesign. Extension fields now live in the same physical SQL table as the base table itself. Not a companion table joined at runtime the same table. The join that BC23 fixed the growth of, v29 removes at the runtime level for any objects living in the same app.
This is not only a performance change, even though Microsoft states it improves performance across database operations generally. It also lets developers define indexes and keys that span both base table fields and extension fields together, something that was never possible when extension fields lived in a physically separate table. A key that combines a standard field and a custom field can now be defined and indexed as a single unit rather than requiring a workaround or accepting the performance cost of filtering across two tables.
What This Doesn’t Change, and Why That Matters More
The architectural redesign is the interesting part of the story, but the guidance that comes with it is the part developers should actually act on. Microsoft’s message alongside this change is explicit: don’t restructure your own AL architecture to depend on SQL directly. Continue building against AL, APIs, and supported Business Central patterns. Continue paying attention to partial record loading and which fields your code actually consumes.
It can eliminate the runtime join, but that doesn’t mean loading full records instead of the fields you actually need becomes free. It can support mixed-field indexes now, but that doesn’t mean every table needs one, or that indexing decisions stop requiring judgment. The database got faster and more flexible underneath the application. The discipline required to write AL that performs well was not replaced by that change it was simply given a better foundation to run on.
v29 also introduces new SQL column-limit compiler warnings alongside this redesign. The documentation describes what the feature is intended to catch, but I think the more useful answer comes from testing it directly against real AL code rather than taking the intended behavior at face value — which is exactly what I plan to do before drawing conclusions about how it actually behaves in practice.
Finally
Three release waves, one architectural direction: from one table per extension, to a shared companion table, to a single unified table with the base. Each step removed a cost the previous step had accepted as a tradeoff. None of them were announced as a headline feature, and most partners will only notice this history if they go looking for it, the way I did while working through the v29 preview.
The lesson here isn’t really about table extensions specifically. It’s that some of the most consequential changes to how Business Central performs happen well below the feature list, accumulate over multiple releases, and reward the partners who take the time to understand the direction rather than just the latest increment.
Leave a Reply