We profile, then fix
Performance problems in Business Central are almost never where you think they are. We start by profiling the actual SQL — execution plans, wait statistics, index usage — to identify the real bottleneck before writing a single line of code.
We've turned multi-minute timeouts into sub-second responses on tables with 200 million+ rows. The key is understanding how BC translates AL into SQL, and designing your data access patterns to work with the engine rather than against it.
What we optimise
Our performance work covers query objects for SQL-pushed aggregation, SIFT key design and FlowField optimisation, covering indexes for high-volume ledger queries, set-based posting patterns, and eliminating N+1 patterns in AL code.
We also review extension code for common performance anti-patterns: unnecessary record locks, excessive FindSet/FindFirst calls, unfiltered temporary tables, and event subscribers that fire on every insert.
High-volume environments
If you're running BC with millions of G/L entries, hundreds of thousands of posted documents, or high-frequency posting operations, you need someone who understands both the AL layer and the SQL layer. We've built query-object APIs that aggregate across 200M+ row tables in under a second, using SQL-pushed aggregation and covering indexes designed specifically for the query pattern.