With BC28, we got more control over which indexes are maintained and which ones are not. Check out the video to see how you can control this in an easy way.
With Business Central version 28 (2026 release wave), Microsoft introduced a powerful new capability that lets administrators and super users manage table indexes directly from the UI — no AL code required. In this video, Erik demonstrates how to analyze and disable unused indexes to squeeze more performance out of your Business Central tables.
Understanding Table Size and Index Overhead
The starting point is the Table Information page, which has been available in Business Central for years. This page provides a list of all tables in the system along with information about how much space they use.
Erik walks through a Cronus demo database to illustrate the key metrics. Looking at the GL Entry table as an example:
- Records: 4,628
- Average record size: ~139.84 bytes
- Total size: 1,760 KB (~1.7 MB)
- Data size: 632 KB
- Index size: 1,128 KB
Notice the ratio here — the index data is almost double the actual data size. This is a common pattern in Business Central tables, especially in high-traffic ledger tables with many keys defined.
Why Are Record Sizes Decimal Values?
You might wonder why the average record size shows decimal values when bytes should be whole numbers. This is because string fields are stored as varchar in SQL Server, meaning they only consume the amount of space that the actual data requires. A Text[100] field containing only 10 characters won’t allocate 100 bytes — it only uses space for those 10 characters.
The New Index Management Feature in BC 28
What’s new in Business Central version 28 is the ability to control indexes directly from the Table Information page. When you click into a table, you now get extra information about the table’s keys — and critically, you can enable or disable them.
How Indexes Affect Performance
Every index on a table has a trade-off:
- Write operations: Every time a record is inserted, modified, or deleted, all active indexes must be updated. More indexes means slower writes.
- Read operations: Indexes speed up queries that filter or sort by the indexed fields. More relevant indexes means faster reads.
The key insight is that an index is only valuable if it’s actually being used. If an index exists but no queries leverage it, you’re paying the write performance cost for zero read benefit.
Analyzing Index Usage
The Table Information drill-down now shows usage statistics for each key. You can see how frequently each index is being utilized, and you may discover that some indexes have never been used.
Erik demonstrates using Prism, an analysis tool with powerful “where used” functionality, to determine whether specific keys are referenced anywhere in the codebase. In his example, keys 11 and 12 on the GL Entry table are examined:
- Key 11: General Posting Group, General Product Posting Group, Entry Number
- Key 12: VAT Business Posting Group, VAT Product Posting Group, Entry Number
Using Prism’s “Find Usage” feature on both keys returned “No usage found” — meaning no code in the loaded apps references these keys specifically.
Important note: When performing this analysis, make sure you have all installed apps and extensions loaded in your analysis tool. Otherwise, you might miss legitimate references to a key from a third-party or custom extension.
Disabling an Unused Index
Once you’ve confirmed that an index is unused, disabling it is straightforward. From the Table Information drill-down, you simply select the key and turn it off. The index is immediately no longer maintained, and your system gains a small performance improvement on every write operation to that table.
Per-Company Control
One noteworthy detail is that indexes can be disabled per company. If you have multiple companies in a single database with different usage patterns, you can selectively disable keys in one company while keeping them active in another.
Turning an Index Back On
If you disable an index by mistake, you can turn it back on — but be aware that it won’t be immediate. When you re-enable a disabled index:
- The index is queued for rebuild.
- The rebuild will be attempted during the scheduled maintenance window (overnight, local time).
- Until the rebuild completes, queries that would benefit from that index will still work — they’ll just be slower because SQL Server has to scan the data without the index.
This is an important consideration: disabling an index is fast and immediate, but re-enabling one takes time. Make sure you’ve done your analysis before flipping the switch.
Who Should Use This Feature?
This feature is designed for:
- System administrators managing high-traffic environments
- Super users looking to optimize performance
- Partners helping customers tune their systems
Previously, managing indexes required writing AL code, which was complicated and required a developer. This new UI-based approach provides all the statistics you need and makes the process accessible to non-developers.
Summary
Business Central version 28 brings a welcome addition for performance tuning: the ability to view index statistics and disable unused indexes directly from the Table Information page. For tables with high write traffic and many indexes — like GL Entry — disabling unused keys can provide a meaningful performance boost. The feature offers per-company control, clear usage statistics, and a safe way to re-enable indexes if needed. Best of all, not a single line of AL code is required.
