Some of the most stubborn ServiceNow performance problems don't come from a slow script or an unindexed query. They come from something small that every insert has to do first: generate the next record number. On most instances that step is invisible. On an instance ingesting large volumes concurrently — Vulnerability Response (VR) feeds, several data sources landing on the same table, overlapping scheduled imports — it can quietly become the thing everything else waits on.
This article covers a system property aimed at exactly that situation: glide.db.atomic_counter_all. In the Australia release, if the property isn't already present on your instance, it has to be created manually, and ServiceNow is expected to enable it by default in future releases. Below: what problem it addresses, what it changes, whether it's safe to turn on, and how to confirm it actually helped.
| Question | Short answer |
|---|---|
| What does it do? | Changes how new record numbers (INC, VUL, and so on) are generated — an atomic database operation instead of a lock, read, increment, write cycle |
| Who benefits most? | Instances with heavy, concurrent inserts on the same table from multiple nodes |
| Does it touch existing records? | No |
| Does the number format change? | No |
| Can it be rolled back? | Yes — set it to false or remove it; no data changes needed |
| Should it be tested first? | Yes — validate in sub-production under your normal change process |
1. How ServiceNow Generates Record Numbers
Every table with auto-numbering — Incident, Change, or a VR table such as Vulnerable Item — has a counter kept in the database. Creating a record means the platform has to:
- Lock the counter row for that table
- Read the current value
- Increment it
- Write the new value back
- Release the lock
At normal volumes this cycle is fast enough that nobody notices it. The cost only shows up when many inserts want the same counter at the same moment.
2. The Hot-Row Contention Problem
The detail that matters is that the counter is per table. Every insert on a given table, from every node, needs the same single row. On a multi-node instance, those inserts queue for that row and are served one at a time.
Example — an illustrative VR ingestion scenario (not a benchmark):
Several scheduled jobs pull data into the same underlying table from different nodes at the same time. They use multiple data sources and import templates, and their iterations overlap with one another. Each insert needs the next number, so they all converge on one counter row:
Node A (Data Source 1 -> Import Template X) --+
Node B (Data Source 2 -> Import Template Y) --+
Node C (Scheduled job, same target table) --+--> ONE counter row
Node D (Overlapping import iteration) --+ lock -> read -> +1 -> write -> unlock
Result: inserts wait in line for the counter, one at a time,
no matter how many nodes are available to do the work.
To put a rough number on it: 25 million records in a day works out to about 290 inserts per second on average, and considerably more during ingestion peaks. The 25 million figure is only an illustration — the pattern matters more than the number.
The symptoms tend to look like this:
- Import and VR processing jobs take longer than expected
- Iterations run past their window and start overlapping the next run, so delays cascade from one job to the next
- Insert throughput doesn't scale even when more nodes are available
- Nothing looks obviously wrong in the scripts or queries themselves
What to actually learn: when ingestion jobs slow down and start overlapping without any single script or query standing out, insert serialization on the target table is worth ruling in or out — not just the job logic.
3. What glide.db.atomic_counter_all Does
With the property set to true, number generation moves from the application-level lock, read, increment, write, unlock pattern to a database-native atomic increment. In simplified terms, the database performs the increment as a single operation, instead of the platform holding a lock across several steps.
| Aspect | Traditional | Atomic counter |
|---|---|---|
| Mechanism | Application-level lock, read, increment, write, unlock | Single atomic database operation |
| Lock duration | Held for the whole read-increment-write cycle | Very short, handled inside the database |
| Contention under load | High — nodes queue up | Much lower — the database engine manages concurrency |
| Number uniqueness | Guaranteed | Guaranteed |
| Number format | Prefix and padding as configured | Unchanged |
Nothing about the numbers themselves changes. What changes is how the platform obtains the next one.
4. Why the Australia Release and RaptorDB Bring This Into Focus
ServiceNow's knowledge article on this behavior (KB2462993) notes that the contention is observed more often on RaptorDB. RaptorDB is PostgreSQL-based, and its row-level locking and MVCC behavior means concurrent updates to the same row are serialized: each transaction waits for the previous one to commit. A hot counter row therefore becomes visible at lower volumes than many teams saw before.
The pattern itself isn't new. Under RaptorDB's concurrency behavior it simply surfaces sooner — which is why the property is now something Australia-release instances need to look at deliberately. It also fits the broader shift in database infrastructure that platform teams are already tracking.
5. Is It Safe? Impact Analysis
This is the first concern most administrators raise, so it's worth taking in three parts: existing data, new data, and scope.
Existing data
| Concern | Answer |
|---|---|
| Existing records | No impact. Existing numbers stay exactly as they are |
| Number continuity | The counter continues from its current value. If the last number was VUL0025000000, the next is VUL0025000001 — no gap, no reset |
| Historical integrity | Untouched. This changes how numbers are generated, not stored data |
New data
| Concern | Answer |
|---|---|
| Uniqueness | Atomic operations exist specifically to prevent duplicates |
| Format | Same prefix, same padding |
| Reporting and queries | Number fields behave the same in filters, reports and lookups |
| Ordering | Effectively sequential. Records created at nearly the same instant may not receive numbers in exact commit order, but they will not receive the same number |
Scope
| Concern | Answer |
|---|---|
| Where does it apply? | Instance-wide, to tables using number maintenance |
| Low-volume tables | No noticeable difference |
| High-volume tables | This is where the benefit shows up |
| Reversibility | Set the property back to false and the traditional mechanism returns |
A note on sequencing: ServiceNow numbering has never been strictly gap-free — numbers can be consumed by records that are opened and never saved. If a business process genuinely depends on gap-free, commit-ordered numbers, treat that as a requirement to confirm with stakeholders before changing anything.
6. Is ServiceNow Hiding a Glitch?
A fair question, and the honest answer is no. This is an architectural scaling limitation that appears at high concurrency, not a defect in the usual sense. Publishing a knowledge article and providing a property to address it is the transparent way to handle a known limit.
The rollout has also been gradual: atomic behavior has been available as an opt-in, and ServiceNow is expected to make it the default in future releases as RaptorDB adoption grows. Enabling it now simply brings your instance in line with where the platform is heading.
What to actually learn: a property that ServiceNow intends to make the default is a low-regret change — but low-regret still isn't zero-testing. Treat it like any other instance-wide change.
7. How to Set It Up
- In the navigation filter, enter sys_properties.list to open the System Properties table.
- Search for glide.db.atomic_counter_all.
- If it exists, check its current value. If it doesn't, click New.
- Enter the values shown below and save.
- Capture the change in an update set or your change record, as your process requires.
Name: glide.db.atomic_counter_all Type: true | false Value: true Description: Use atomic DB operation for number generation. See KB2462993.
Rollback: set the value to false, or delete the property. No data changes are needed either way.
8. How to Validate the Improvement
Enabling the property is only half the job. Confirm it did what you expected by comparing before and after, using the same data volumes wherever possible:
- Job duration: run time of your VR ingestion or import jobs over comparable volumes
- Insert throughput: records created per minute on the affected table
- Transaction logs: average response time of insert-heavy transactions
- Overlap: how often scheduled jobs collide or run past the start of their next iteration
- Database wait behavior: lock waits on the number counter, if your monitoring exposes them
Record baselines before the change. Without them, an improvement — or the absence of one — is only an impression.
9. Best-Practice Checklist
- Enable it in a sub-production instance first and run a realistic load
- Get the change approved through your normal process
- Capture baselines before and after
- Confirm nothing downstream depends on gap-free, commit-ordered numbers
- Review overlapping job schedules regardless — removing one bottleneck doesn't excuse poorly staggered jobs
- Recheck after upgrades, since future releases may set the property by default
10. Frequently Asked Questions
What is glide.db.atomic_counter_all?
A ServiceNow system property that makes record-number generation use an atomic database operation, reducing lock contention on high-volume tables.
Does it change existing record numbers?
No. It only affects numbers generated after it is enabled.
Can it create duplicate numbers?
No. Uniqueness is the purpose of the atomic operation.
Do I need it on a low-volume instance?
Probably not for performance. It is harmless to enable, but the benefit appears under heavy, concurrent inserts.
Can I undo it?
Yes. Set it to false or remove the property.
Wrap-Up
Record numbering is easy to overlook until it becomes the bottleneck. If your instance ingests large volumes concurrently, glide.db.atomic_counter_all removes a serialization point at very low risk — but the discipline that makes it low-risk is the same one that applies to any instance-wide property: test it, measure it, and roll it out deliberately.
If there's one habit worth taking from this, it's the question underneath the whole article: when jobs get slow and nothing in the code explains it, what are they all waiting on? Ask that before adding nodes, not after.
Reference:
- ServiceNow Knowledge Article KB2462993 — number generation contention and the glide.db.atomic_counter_all property