Introduction
With the introduction of Record.Truncate() in Business Central 16.0 (Business Central 2025 release wave 2), developers gained a new, high-speed way to clear entire tables, but how much faster is it really than DeleteAll()?
I decided to put it to the test across three real-world scenarios, small, medium, and enterprise-scale datasets, to measure not only speed but also behavioral differences, such as trigger execution and limitations.
GitHub Link: https://github.com/oussabuh/Truncate-vs-DeleteAll
The Methods in Comparison
Before diving into numbers, here’s a quick recap of what each method does:
| Method | Triggers Executed | Description |
|---|---|---|
DeleteAll(true) | ✅ Yes | Deletes all records while running OnDelete and validation triggers |
DeleteAll(false) | ❌ No | Deletes records without triggering business logic |
Record.Truncate() | ❌ No | Performs a SQL TRUNCATE directly on the table, fastest, but restricted |
Scenario 1: Small Dataset (1,000 Records)
This test aimed to show the baseline performance difference with a small dataset, just enough to measure time while still allowing Business Central to execute triggers normally.
- DeleteAll(true) executed all triggers and completed last. 1280 ms
- DeleteAll(false) finished noticeably faster since it skipped logic. 121 ms
- Record.Truncate() cleared the table almost instantly. 9 ms
📸 As shown in the screenshots, the performance gap is clear even at a small scale, Truncate shows a sharp advantage right from the start.
Scenario 2: Medium Dataset (50,000 Records)
When scaling to 50,000 records, the gap widened dramatically.
DeleteAll(true)took several seconds due to trigger execution. Approximately 1 minuteDeleteAll(false)improved speed by several factors. 2343 msRecord.Truncate()completed in a fraction of the time, maintaining stability with no triggers executed. 10 ms
📸 As shown in the screenshots, DeleteAll(false) performed roughly 5–10x faster than DeleteAll(true), while Truncate() was almost instantaneous.
This test also confirmed that Truncate does not raise trigger-based confirmation messages, proving that it fully bypasses AL-level business logic.
Scenario 3: Large Dataset (1,000,000 Records)
This was the enterprise-scale performance test, designed to push each method to its limits.
DeleteAll(true)took the longest, reflecting heavy trigger overhead. Approximately 27 minutesDeleteAll(false)remained stable and efficient, but still required noticeable time. Approximately 0.5 minuteRecord.Truncate()cleared all 1 million records nearly instantly, a massive performance gain. 80 ms
📸 As shown in the screenshots, Truncate dominated this test, completing in milliseconds compared to seconds or even minutes for DeleteAll methods.
Understanding Truncate Limitations
While Record.Truncate() is extremely fast, it’s not universally safe. Microsoft officially lists six limitations that should guide your decision on when to use it.
| Limitation | Description | Recommendation |
|---|---|---|
| Table Type | Only works on Normal tables | Use DeleteAll for temporary/system tables |
| Try Function | Not supported within TryFunction blocks | Use DeleteAll |
| Security Filters | Fails when user filters are applied | Use DeleteAll to respect filters |
| FlowFields / Marked Records | Not supported | Use DeleteAll |
| Event Subscribers | Skips events completely | Avoid on tables with dependencies |
| Media Fields | Not supported | Use DeleteAll for cleanup |
These were all confirmed during my limitation testing phase.
📊 Performance Highlights
Here’s how performance scaled across the three datasets (see screenshots for full details):
| Dataset | DeleteAll(true) | DeleteAll(false) | Record.Truncate() |
|---|---|---|---|
| 1K Records | Slowest | Fast | Fastest |
| 50K Records | Significantly slower | ~5–10x faster | Almost instant |
| 1M Records | Extremely slow | Stable but slower | Instantaneous |
In all three cases, Record.Truncate() consistently outperformed the others, sometimes by over 100x, proving how impactful it can be when used in the right scenario.
Best Practices
- ✅ Use
Record.Truncate()only for bulk cleanup or test data reset scenarios - ⚠️ Avoid using it where triggers, events, or security filters are essential
- ⚙️ Use
DeleteAll(false)for routine cleanup without triggers - 🧩 Use
DeleteAll(true)only when business logic or validation must be enforced
Conclusion
In my tests, Record.Truncate() delivered remarkable performance improvements, especially at scale. For large data volumes, it’s by far the fastest way to clear tables in Business Central.
That said, its limitations and skipped logic mean it should be used carefully, especially in production environments.
