As a Salesforce consultant, I get asked quite a few questions; some pretty standard and some not so standard. One of the most common “not so standard” questions I get from new Salesforce customers, when I explain how the Salesforce Record ID format works is, “How long until Salesforce runs out of ID values?”, so I thought I would take a look.

I ran some calculations in a spreadsheet and what follows are the results. Feel free to stop reading now if you are not interested in this topic; there are no tips hidden in here, just a bunch of related numbers. I wrote this for salesforce administrators that may find it slightly amusing.

First off, let’s take a look at the Salesforce Record ID. It is 15 digits long, unique across all Salesforce customers and instances, and uses both numbers and letters. It is also case sensitive, so “A” and “a” are different values. This means that a single digit can have 62 possible values per the list below. There is also a “Case Safe” (case insensitive) version of a Salesforce Record ID that is 18 digits, but the possible values are the same as the 15 digit case sensitive version so we will stay with 15 digits for simplicity.

- “A” through “Z” = 26 characters
- “a” through “z” = 26 characters
- “0” through “9” = 10 characters

If one digit can have 62 possible values, then two digits can have 3,844 possible values (62 multiplied by 62) and three digits can have 238,328 possible values (3,844 multiplied by 62). As you can see, the number of possible ID values increases dramatically with each digit. Below is the full table of the number of possible values based on the number of digits:

I’m not sure what a number with 27 digits translates to in hundreds of trillions of billions but I did find a reference for names of large numbers that says it is named “octillion.” I will have to trust them on that since this is not a number I normally deal with…

Now that we know how many possible Salesforce record ID values we can have, let’s see how long it would take to use them all. Salesforce has the power to create many records per second across all servers and customers so I figured a table of records per second would give us a good indication of how long it would take to use all the ID values.

We all (hopefully) know that there are 60 seconds in a minute, 60 minutes in an hour, 24 hours in a day, and close to 365 days in a year (no leap years were harmed in these calculations) so with a few simple calculations like below, we can display how many seconds there are in a year. If the USA ever switches to a Metric clock and calendar, all of the calculations below are void.

- One hour = 60 seconds multiplied by 60 minutes, or 3,600 seconds
- One day = one hour’s worth of seconds (3,600) multiplied by 24 hours, or 86,400 seconds
- One year = one day’s worth of seconds (86,400) multiplied by 365 days, or 31,536,000 seconds

Now that we know how many seconds there are in a year, we can figure out how many years it would take to use up all of the possible Salesforce record ID values based on the number of records created per second. Below is a table showing possible outcomes from one record created per second to one hundred billion records created per second, and their respective number of years it would take to use up all 768 “octillion” possible values:

I do not know how many records Salesforce can create per second across all servers and customers but I doubt it is more than one billion, so I figured that one hundred billion records per second would be a good limit until Quantum Computing becomes generally available. Going by these calculations, it is safe to assume that Salesforce will not run out of available record ID values in the near future. And, in the next 243+ million years, I am sure someone will come up with a more advanced database technology… Thanks for reading.

*Would you agree that we’re nerdy enough to do amazing things for your Salesforce?*

**StarrData helps you get the most out of Salesforce. If you would like information on the services we offer, call us at (888) 391-4493 x103.**

## Reader Interactions