SQL Server: Stop Using DATETIME (Use DATETIME2 and Save Space)


SQL Server: Stop Using DATETIME (Use DATETIME2 and Save Space) 🔥

👉 If you missed my previous post: Why Your Index Is NOT Being Used (5 Hidden Reasons)


💥 The Hook

You think DATETIME is “good enough”?
It’s silently wasting space, reducing precision, and hurting performance.

👉 In modern SQL Server, using DATETIME is a legacy mistake.


TL;DR

💣 Problem → Legacy DATETIME type wastes space and loses precision
💣 Symptom → Larger tables, more IO, less accurate timestamps
✔️ Fix → Use DATETIME2 with proper precision (e.g. DATETIME2(2) or (7))

Hi SQL Server Guys,

Everything is fine... until your system scales.

You have:

More rows.
More IO.
More memory pressure.

💣 And suddenly… your “simple” DATETIME column becomes a problem.


🧠 What It Really Is

DATETIME is a legacy data type designed decades ago.

  • Low precision (3.33 ms)
  • Fixed storage (8 bytes)
  • Non-standard behavior

👉 DATETIME2 fixes ALL of this.


🔥 Precision Matters (More Than You Think)

DATETIME2 supports up to 100 nanoseconds precision (DATETIME2(7)).

There are systems such as:

  • Financial systems
  • IoT data
  • High-frequency logging

👉 where precision is NOT optional.

💣 While DATETIME truncates time, DATETIME2 preserves reality.


⚡ Storage Savings = Performance

Disk and memory are your real bottlenecks.

  • DATETIME → 8 bytes (fixed)
  • DATETIME2(2) → 6 bytes

👉 On 100 million rows:

  • ~200 MB saved
  • More rows per page
  • Better buffer pool efficiency

💣 Smaller rows = faster queries.


👻 The Cardinality Estimation Myth

Back in SQL Server 2008 i wrote this post: SQL Server, datetime vs. datetime2

At the time, DATETIME2 had estimation issues.

👉 That’s no longer true.

✔️ SQL Server 2016+ fixed it
💣 If you see bad plans → check your compatibility level


🛑 Strict Syntax = Safer Code

-- BAD (ambiguous)
SELECT GETDATE() + 1;

-- GOOD (explicit)
SELECT DATEADD(day, 1, SYSDATETIME());

✔️ DATETIME2 enforces clean syntax
💣 No more silent bugs


🧪 The Benchmark time...

Scenario CPU Reads Result
DATETIME (100M rows) 900 ms 800000 Heavy IO ❌
DATETIME2(2) 700 ms 600000 Improved ✔️
DATETIME2(7) 750 ms 620000 High precision ✔️

💣 Same data… less bytes → better performance


🔥 Real Fixes

  1. Use DATETIME2(2)
    ✔️ Smaller size
    ✔️ Good precision
    ❌ Not max precision
  2. Use DATETIME2(7)
    ✔️ Maximum precision
    ❌ Slightly more storage
  3. Use DATETIMEOFFSET
    ✔️ Time zone aware
    ❌ Larger storage

🚀 My REAL Strategy (important)

  • New systems → ALWAYS DATETIME2
  • High precision → DATETIME2(7)
  • High volume → DATETIME2(2)
  • Global systems → DATETIMEOFFSET

💣 Yes, DATETIME should not exist in modern designs.


📚 Related & Important Posts you must read


📢 📢 📢 If you like my work and found it helpful and you want to support the Blog, the ads you see here are selected to reflect your interests. If a partner's offer catches your eye, give it a look! Your engagement helps me continue publishing premium SQL Server content for the community.


Biondi Luca @2026 - Sharing over 25 years of Gained Knowledge for Passion.
Share if you like my posts!

Comments

I Post più popolari

Speaking to Sql Server, sniffing the TDS protocol

SQL Server, find text in a Trigger, Stored Procedures, View and Function. Two ways and what ways is better

SQL Server, Avoid that damn Table Spool!