I'm not too smart about how SQL server works so I had to try it both ways. It looks like using a default is about 5% faster. (I guess the qualitative result isn't much surprise.) Here's the script I used for my little empirical test. I've noticed there are plenty of SQL Server gurus on this board so I'd love to hear a critique of my testing methods... And if anyone wants to get crazy I wouldn't mind seeing an analysis of how advantage changes vs. different loop sizes (I've only tested 10000 records here).DROP TABLE DateTableDefaultGOCREATE TABLE DateTableDefault ( --Tbl with default value. Id INT IDENTITY(1, 1) PRIMARY KEY, DateValue DATETIME DEFAULT GETDATE(), FakeData VARCHAR(50) NULL)GODECLARE @ctr INT, @start DATETIMESET @start = GETDATE()SET @ctr = 10000WHILE @ctr > 0BEGIN IF @ctr % 10 = 0 --Use the modulo to get simulate "90%" INSERT INTO DateTableDefault (DateValue, FakeData) VALUES ('12-01-2009', CAST(RAND() AS VARCHAR(50))) ELSE INSERT INTO DateTableDefault (FakeData) VALUES (CAST(RAND() AS VARCHAR(50))) SET @ctr = @ctr - 1ENDPRINT DATEDIFF(ms, @start, GETDATE()) --8703 milliseconds is the result.DROP TABLE DateTableNoDefaultGOCREATE TABLE DateTableNoDefault ( --Tbl with no default date value. Id INT IDENTITY(1, 1) PRIMARY KEY, DateValue DATETIME NULL, FakeData VARCHAR(50) NULL)GODECLARE @ctr INT, @start DATETIMESET @start = GETDATE()SET @ctr = 10000WHILE @ctr > 0BEGIN IF @ctr % 10 = 0 INSERT INTO DateTableNoDefault (DateValue, FakeData) VALUES ('12-01-2009', CAST(RAND() AS VARCHAR(50))) ELSE INSERT INTO DateTableNoDefault (DateValue,FakeData) VALUES (GETDATE(), CAST(RAND() AS VARCHAR(50))) SET @ctr = @ctr - 1ENDPRINT DATEDIFF(ms, @start, GETDATE()) --9273 ms is the result--Baldeep