According to the documentation datetime2 (Transact-SQL):

Storage size
6 bytes for precisions less than 3.
7 bytes for precisions 3 and 4.
All other precisions require 8 bytes.

The size of datetime2(0), datetime2(1), datetime2(2) use the same amount of storage (6 bytes).

Would I be correct in saying that I might as well go with datetime2(2) and gain the benefit of the precision without any additional size costs?

Please note:

  • This column is indexed with the PK to form a compound clustered index (used for table partitioning)
  • I do not care about milliseconds

Would datetime2(0) be more cpu efficient when used in a where clause, or when seeking through an index?

This is a massive table, so the smallest optimization will make a big difference.


1 Answer 1


The size of dateTime2(0), dateTime2(1), dateTime2(2), dateTime2(3) use the same amount of storage. (6 Bytes)

Would I be correct in saying that I might as well go with dateTime2(3) and gain the benefit of the precision without any additional size costs.

No, you misinterpreted the documentation. Note the doc states storage size 6 bytes for precisions less than 3 (emphasis mine). So a precision equal to 3 will require 7 bytes.

If you don't care about milliseconds, datetime2(0) would be the proper data type and precision. The best practice is to specify the proper data type and precision based on the data stored as this will inherently provide optimal storage and efficiency. That being said, I would not expect a significant performance impact based on the specified datetime2 precision as long as the storage size is the same but I have not specifically tested that myself.

Application requirements will dictate what must be stored in the database when a greater precision is available in the source. For example, for an order entry time sourced from SYSDATETIME(), users may not want 100 nanosecond precision. Again, choose the data type and precision for new development according to requirements and you will generally get optimal performance without additional thought:

Although datetime2 is most appropriate for new development as listed above, one may sometimes need to use datetime (fixed precision 3 with 1/300 fractional seconds accuracy) instead for compatibility with legacy datetime applications, thus avoiding implicit conversions and unexpected comparison behavior, but at the expense of fractional second accuracy and increased storage.

Consider that storing a greater precision than required may also have a development cost. If one stores a time component with fractional seconds when only whole second precision is required, queries will still need to consider the fractional seconds to return the correct results. For example, with an app where the user selects a time range via a UI that only allows for whole seconds, the app code would need to account for the fractional seconds in the end time range value and adjust the user-supplied value accordingly (e.g. WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99' or WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). This will add code complexity.

  • Sorry to bump in this old thread for just this tiny note, but smalldatetime does have whole seconds (i.e. hh:mm:ss).
    – pgfiore
    Commented Sep 23, 2019 at 8:12
  • 1
    @pgfiore Are you sure about that? Commented Sep 23, 2019 at 8:47
  • @pgfiore, the smalldatetime documentation states one-minute accuracy and you'll find it is correct with SELECT CAST(GETDATE() AS smalldatetime);.
    – Dan Guzman
    Commented Sep 23, 2019 at 10:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.