SQL Server 2024 or 2025?

Question

Post reply

SQL Server 2024 or 2025?

Steve Jones - SSC Editor

SSC Guru

Points: 736172
More actions
July 19, 2023 at 9:17 pm

#4239504
Take a guess when the next version of SQL Server will release. Give me a date, and I'll send a prize to whoever is closest (or maybe 2 people that are equidistant), and posted earliest here.
To make it more interesting, if you post in 2023, you get leeway of a week. If you post in H1 2024, you get 3 days.
Enter here: https://docs.google.com/forms/d/e/1FAIpQLSeQqiGMdl7pKXGZE4zCtF3-YXIH4eKbdtYWRD16ZKNH67eO5w/viewform?usp=pp_url
I'll close the contest where there is a public announcement of a preview. MVPs are not allowed to enter, nor anyone with an NDA with Microsoft.
You can guess no more than 3 times.
- This topic was modified 1 year, 4 months ago by Steve Jones - SSC Editor.

Viewing 14 posts - 1 through 13 (of 13 total)

You must be logged in to reply to this topic. Login to reply

Site Owners SSC Guru Points: 80330 More actions · Answer 1

Thanks for posting your issue and hopefully someone will answer soon.

This is an automated bump to increase visibility of your question.

Tom Uellner SSCrazy Points: 2995 More actions · Answer 2

Tom Uellner

SSCrazy

Points: 2995

July 31, 2023 at 5:20 pm

#4249359

November 13, 2025

Steve Jones - SSC Editor SSC Guru Points: 736172 More actions · Answer 3

Great guess, aligns with where the Data Community Summit is likely to be. Or Ignite.

Jeff Moden SSC Guru Points: 1004321 More actions · Answer 4

Tom Uellner wrote:

November 13, 2025

That was going to be my guess and for the same reason.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Tom Uellner SSCrazy Points: 2995 More actions · Answer 5

Jeff Moden wrote:

Tom Uellner wrote:
November 13, 2025
That was going to be my guess and for the same reason.

We can share the prize if this turns out to be the date. Hoping it's something sharable.

Johan Bijnens SSC Guru Points: 135369 More actions · Answer 6

I would rather like to know the current version of my Azure Managed Instance, which has been on 12.0.2000.8 for the last 5 years.

I can see the date change e.g to "

Microsoft SQL Azure (RTM) - 12.0.2000.8

Jan 26 2022 22:23:07

If I'm correct your poll is to the successor of SQL2022, right?

My guess "Sep 17, 2025" called SQLWorm

Major new feature: Everything system versioned up to the beginning ( or whatever you can afford )

Johan

Learn to play, play to learn !

Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:

- How to post Performance Problems
- How to post data/code to get the best help[/url]

- How to prevent a sore throat after hours of presenting ppt

press F1 for solution, press shift+F1 for urgent solution 😀

Need a bit of Powershell? How about this

Who am I ? Sometimes this is me but most of the time this is me

Steve Jones - SSC Editor SSC Guru Points: 736172 More actions · Answer 7

Ha, maybe you'll even get a subsidized license for that version from Dell, NetApp, or whoever your SAN vendor is if you system version everything. Add in Ledger tables and they'll give you a few free drives.

Robin Wilson SSCertifiable Points: 5007 More actions · Answer 8

I'm going to go for 14/11/2025 with it being a Friday

Eric M Russell SSC Guru Points: 125561 More actions · Answer 9

2025-11-30

Also, we deserve extra points, if we post our answer in ANSI standard YYYY-MM-DD format.

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Ronzo Hall of Fame Points: 3917 More actions · Answer 10

Thumbs up for YYYY-MM-DD, removes needless confusion caused by regional formats of MMDD... or DDMM....

2025-09-06

Have Fun!
Ronzo

Jeffrey Williams SSC Guru Points: 90303 More actions · Answer 11

Ronzo wrote:

Thumbs up for YYYY-MM-DD, removes needless confusion caused by regional formats of MMDD... or DDMM....
2025-09-06

Better be careful here - if that is a datetime and not datetime2 or date then it *could* be interpreted as June 9th instead of September 6th. To be absolutely sure: 20250906

Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”

― Charles R. Swindoll

How to post questions to get better answers faster
Managing Transaction Logs

Jeff Moden SSC Guru Points: 1004321 More actions · Answer 12

Just to emphasize what Jeffrey Williams is talking about...

    SET LANGUAGE ENGLISH;
 SELECT English = CAST('2025-09-06' AS DATETIME);

    SET LANGUAGE FRENCH;
 SELECT French = CAST('2025-09-06' AS DATETIME);

Results:

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Robin Wilson SSCertifiable Points: 5007 More actions · Answer 13

This has caught me out a few times where the same code in YYYY-MM-DD format ends up being interpreted as either DD/MM/YYYY or MM/DD/YYYY depending on the server so it would be good if they fixed that as entering dates without the - just doesn't look nice.

I always add SET DATEFORMAT ymd at the top of scripts just to make sure it works as expected. Often in the UK servers end up being installed in USA language where IT teams just press Next, Next Next... on the installers.

I suppose that would not happen in Spain or France for example as they would always be picking the native language when installing otherwise would have no idea what their database was talking about!

I realise it is historical so may never be "fixed" and we have DATETIME2 but mistakes should not need to remain for eternity and isn't that why we have compatibility levels which often people forget to change and still have it set to 2008.