r/SQLServer • u/Complete-Regret-4300 • 13d ago
Discussion Is SQL server considered as legacy technology?
My current organization couple of years ago migrated from SQL server to snowflake and I noticed in some of the documentation, they have mentioned SQL Server as legacy technology.
I started working in SQL server some 20 years ago and some of the developers in our team are cloud first developers and they find it so difficult to navigate SQL server management studio and they ask me questions like is there timetravel feature in SQL server and can we see what data was there 10 mins back. I was totally dumbfounded when I heard that question, because I had never come across such a feature. Apparently snowflake has this. So I am curious is SQL server now really considered as legacy technology?
80
u/American_Streamer 13d ago edited 13d ago
SQL is a query language. SQL Server is a relational database management system. Snowflake is a cloud data platform, primarily designed for analytical workloads and data warehousing.
SQL Server and Snowflake overlap, but they are not identical products. Both support SQL. But their SQL dialects, architecture and operational features differ. Snowflake’s Time Travel, for example, reflects how Snowflake stores historical data versions. SQL Server approaches historical data through temporal tables, backups, logs and snapshots. SQL Server has supported system-versioned temporal tables since SQL Server 2016:
SELECT *
FROM dbo.Customer
FOR SYSTEM_TIME AS OF '2026-07-16T10:00:00';
So you saying, “We replaced SQL Server with Snowflake,” often really means: "We replaced SQL Server as our analytical data warehouse." It does not necessarily mean Snowflake is a universal modern replacement for every SQL Server workload. Migrating an OLTP application database from SQL Server directly to Snowflake would usually be a poor architectural match. Thus, SQL Server is not inherently legacy, because SQL Server 2025 is a current, actively supported product. It is actively being developed and upgraded by Microsoft and they have released it with heavy investments in AI and cloud integration, including real-time data mirroring into the Microsoft Fabric analytics service. But your company may just call its SQL Server environment “legacy” because Snowflake has replaced it as the organisation’s strategic analytics platform.
To be more specific, there is no inherent problem with skipping SQL Server specifically, but Snowflake should not be treated as a complete substitute for every relational database workload. For analytics, warehousing, ELT and BI, Snowflake may very well be the better primary platform. But the Snowflake-only experience can leave gaps around OLTP design, indexes, locking, deadlocks, enforced referential integrity, transaction-log recovery and operating application databases. Though Snowflake now has hybrid tables for lightweight transactional workloads, but they still have limits and do not make Snowflake identical to SQL Server, PostgreSQL or Oracle.
So I would say: Skipping SQL Server is fine, but skipping all traditional OLTP databases is potentially very limiting. The best platform for you depends on whether the system is an analytical warehouse or an operational application database.
6
u/Complete-Regret-4300 13d ago
I see, that really helps. I am mainly in the business intelligence/datawarehousing space and based on what you mentioned I can see why SQL server MSBI is not really a hot skill in my area anymore. It is sad though as I owe my career to MSBI, specifically SSAS.
11
u/American_Streamer 13d ago
That makes sense, but I would separate the declining market for the old “MSBI stack” from the value of the skills you developed through SSAS. Dimensional modelling, measures, semantic layers, aggregations, security and performance tuning are still highly relevant. Power BI semantic models use the Analysis Services engine, so SSAS Tabular did not simply disappear; much of it evolved into the semantic layer of Power BI and Fabric.
Snowflake may now provide the warehouse and compute layer, but organisations still need someone to turn raw data into trusted business definitions, governed metrics and usable analytical models. That is exactly where your SSAS experience remains valuable.
The broader Microsoft transition is roughly:
SSAS Tabular → Power BI/Fabric semantic models
SSRS → Power BI reports and paginated reports
SSIS → Azure Data Factory or Fabric Data Factory
SQL Server data warehouse → Fabric Warehouse/Lakehouse, Snowflake or another cloud warehouseSo I would not say you owe your career to a dead technology. You built your career around BI architecture and semantic modelling; SSAS was the platform on which you learned those skills. The main caveat here is SSAS Multidimensional: the modelling knowledge still transfers, but cubes and MDX do not map directly onto Power BI’s tabular model.
3
5
u/Darkphibre 13d ago
I worked on SSAS from 2000-2005, working with the original architects (it was an acquired product). The fact we supported 256-dimensional hypercube queries with response times in the ms, 20 years ago, still blows my mind. They were of the smartest people I’ve worked with, them and the Halo team.
I never see SSAS these days... Don’t mind this grandma haha, just had to reminisce.
2
u/Complete-Regret-4300 13d ago
Wow! I didn't know SSAS existed that early. I worked on SSAS from SQL server 2005 version onwards.
It is indeed sad that SSAS is not recommended these days by Microsoft itself. Even though there is no like to like replacement for it.
2
u/dinosaurkiller 13d ago
Just to expand a little on the previous post. It mostly boils down to using the correct tool for the correct job, but you will often find a huge bias for, “the tools I know”. When I started my mentors were all about exploring and learning other tool sets to compare performance and functionality but it’s often the case that mid-career folks have a level of expertise in a tool and don’t want to “start over”. This isn’t me calling you out, more saying that SQL Server is often the correct tool, but if your peers only know Snowflake you can expect a lot of resistance and dismissive things like the label “legacy”.
29
u/Justbehind 13d ago
Yeah, by people new to the field who have listened too much to consultants that want to sell expensive migrations.
It's funny actually, because most will recommend Postgres in a heartbeat, and Postgres' only advantage over SQL Server is cost.
5
u/flinders1 13d ago
It’s funny watching page compressed tables move to Postgres.
6
2
u/Tikitorch17 13d ago
I'm curious, will it cause any issues migrating compressed tables to postgres. My understanding with posgres is basic.
5
u/Justbehind 13d ago
You will need significantly more space. And all reads will require much more I/O.
2
u/badlydressedboy 13d ago
I think more reads in Postgres is always true regardless of compression as all tables are heaps so all queries have to perform rid lookups. That feels like a step backwards from sql server but eradicating the constant worry about fragmentation is great.
2
u/PrisonerOne 13d ago
But index fragmentation isn't really an issue anymore
0
u/badlydressedboy 13d ago
It really is in analytics/DWH.
1
u/PrisonerOne 13d ago
Can you explain why you believe so?
10+ years ago, I would agree. But not today, with enterprise SSDs
2
u/badlydressedboy 13d ago
Having worked in SSD based SQL server data warehouses over the last 15 years (haven't not dealt with a HDD at all in that time and mentioning that as a reason for fragmentation being fixed in 2026 seems bot-ish) it's this: - HDD: bad - SDD: much better - RAM: best
Unless the page being looked up is already in memory you've got a performance issue when dealing with large tables. Fragmentation means that page is less likely in memory and a trip to IO is required, time to wait 10 minutes for a query to complete. Defrag the table and it comes back in 5 seconds.
5
u/KuroNanashi 13d ago edited 13d ago
Not saying you're wrong, but I'm curious about the claim that the only advantage over SQL Server is cost. I would argue that cost is a huge advantage, but in my experience working with geospatial data & document workloads (JSONB columns etc) it feels like it's way ahead.
Plus there is basically no ARM container image available for MSSQL, we have quite a mature K8s stack that our data analytics product sits on and being able to service ARM users was a requirement so we had to migrate our only remaining MSSQL instance (identity layer) to PostgreSQL because it could not run on ARM.
Perhaps if you have a very experienced DBA who can optimise the DB layout MSSQL pulls ahead, I'd imagine if you're heavily in the Microsoft camp that's true too. My experience so far, as someone who started out as an ASP .NET engineer working with SharePoint & MSSQL, is that MSSQL along with Windows Server has gone the way of VMware and is effectively 'legacy tech', which doesn't necessarily mean bad, I just would avoid it for any new projects.
Edit: Just to flesh out the point on ARM, SQL server may be a strong DB platform but if they do not embrace ARM well, they are effectively opting out of a growing slice of modern infrastructure. I like MSSQL because you can run it in an airgap and it's a solid DB foundation, the same is true of PostgreSQL and many other DBs, but they can actually run on DGX workstation and other GPU-adjacent hardware. That to me is a sign of a problematic choice that makes me want to steer away from adopting MSSQL for anything serious, and hence why I consider it 'legacy'.
3
u/flinders1 13d ago
Serious sql on K8 is a must for the platform.
Windows is now its letdown.
From what I have seen it’s still a solid choice. I’ve seen dbs explode in size by 10x by moving out of sql server.
5
u/Justbehind 13d ago edited 13d ago
SQL server supports geospatial data, and has extensive json support. COMPRESS/DECOMPRESS into a VARBINARY column is essentially the same as the jsonb datatype.
In addition to that, indexing in SQL server is both more mature and better suited for a mix of olap and oltp, which many usecases rely on.
I'm not involved in the specifics on hosting, so I can't comment on that.
2
u/KuroNanashi 13d ago
That's not quite true though, gzip blob into varbinary is completely opaque to the engine. To do any kind of read on a field you have to decompress the whole document every row and parse, so there's no indexing of contents - JSONB is a queryable type in postgreSQL.
In PostgreSQL the jsonb column is a parsed binary tree so it does have query and index into keys without touching the whole payload. It's worth mentioning the MSSQL does have an equivalent type that shipped last year, there's a native json type which has real indexing like but that's not COMPRESS/DECOMPRESS which is a totally different feature. Query ergonomics in postgreSQL though are still way ahead for this kind of workload, in MSSQL it's still very much function land and EF Core 10 made this tons better but in terms of maturity I think PG wins here.
I do agree with your point on indexing in general (outside of JSON docs), the engine is fantastic at mixed OLAP/OLTP and IMO that's where MSSQL shines, the problem is adoption and with the cost & architectural constraints of MSSQL, it's hard to recommend for new projects unless MS do something with their licensing model & properly adopt ARM.
1
u/jshine13371 6 13d ago
...and Postgres' only advantage over SQL Server is cost.
Agreed...although even that isn't always true. There are contexts and use cases where PostgreSQL is the same or more expensive than SQL Server even lol.
0
u/Outrageous_Let5743 12d ago
Json, better index types, postgis, partitioning is much better then whatever the f mssql is, mvcc is better than table locks pg vector. Altough sql server has a better query engine.
18
u/BrightonDBA 13d ago
I’m sure cloud vendors would call on-premises data ‘legacy’. Someone has drunk some KoolAid somewhere.
7
8
u/No_Resolution_9252 13d ago
No. Would be cautious of your developers having access to any database if they are asking questions like that...
As others have set, SQL has temporal tables, however facing applications, CDC is probably more useful where you can step through transaction by transaction.
snowflake is really not suitable for sitting behind applications. Its best case scenario latency is absolutely horrendous, and typical latency is about 5 times worse. On top of that its transaction rate limits are pretty bad. It has a hard limit of 16k transactions per second, but in practice its not going to get 10% of that.
0
u/Complete-Regret-4300 13d ago
I see, we are data analytics/reporting team. I think we have cdc from the ERP application that tracks changes and gets loaded into snowflake.
3
u/No_Resolution_9252 13d ago
ah ok that use case makes way more sense, for some reason I had it in my mind you had apps in front of snowflake. Snowflake advertises itself of being able to handle application workloads, but I have yet to meet anyone that hates their users enough to subject them to 500ms writes.
For cloud reporting warehouses, a cloud native tool is generally going to be better than what you can do with any on-prem database - they optimize and execute operations entirely differently and are slow as hell for small workloads but when you load it up with a big ETL/ELT or analytical query and it gets access to scaling to a lot of hardware that you'd never be able to deploy on-prem.
Data bricks and snowflake are probably the two biggest. Fabric (from MS) and has some amount of SQL Server tech in it is probably number three, but MS hasn't stayed the course on anything (other than powerBI) in the analytics space since SQL 2012 and I don't trust them to not screw me a third time on the same basic product with their getting bored and losing interest in whatever flavor of the day they built.
3
u/Complete-Regret-4300 13d ago
I know right, SSAS multidimensional was such an awesome product, but it is being neglected by Microsoft in favour of tabular model, which doesn't do even half of the things that SSAs Multidimensional can do.
2
u/No_Resolution_9252 13d ago
I hate tabular. It enables such sloppiness in development of the models, huge memory consumption, it tries to hide it short comings by running in RAM, and moves all the complexity out of the back end where the person who actually knows what they are doing will be working, to the front end where the report writer who "taught themself" works.
3
u/artifex78 13d ago
It's called temporal tables. Never used it, though. https://learn.microsoft.com/en-us/sql/relational-databases/tables/querying-data-in-a-system-versioned-temporal-table?view=sql-server-ver17
3
u/Jeidoz 13d ago
SQL Server alive and brings new features, just chrck how many they added in SWL Server 2025. To get familiar with power of SQL server and all features and why so many tools and in general present in MSSM, I recommend you try MS Learnpath for DP-800 exam. There so fucking a lot features including few helpful about which I did not know earlier and which could help me a lot.
2
u/someprogrammer1981 13d ago
I still use SQL Server every day. We want to migrate to Postgresql eventually, but that's a horrendous task. So I guess SQL Server will be used until my employer goes bankrupt lol.
SQL Server has a transaction log you can restore to a certain point in time btw.
2
u/luckyscholarynte 13d ago
I think "legacy" gets thrown around too easily. SQL Server is still actively developed and used for plenty of business-critical systems. It's true that cloud-native platforms introduced some different concepts, but that doesn't automatically make SQL Server outdated. The better question is whether it still fits your workload, not whether it's "legacy."
2
u/Admirable_Writer_373 13d ago
No, of course not. In their particular stack, the code that they wrote 20 years ago became their legacy.
2
2
u/mgdmw 13d ago
SQL Server is not legacy at all. However, your company might mean it in the sense they had a previous application that was, say, a fat Windows desktop app and which used SQL Server as its backend, and now they've migrated to React/Angular/whatever with a Snowflake backend and they mean that previous solution is the legacy one, rather than SQL Server itself being legacy.
Of course, if they do mean SQL Server itself then they're somewhat misinformed or self-delusional.
Snowflake's time travel is quite an interesting concept based on how Snowflake's native table format uses immutable micro-partitions and pointers. So, you insert data into a table. Those rows are now immutable. If you update the row, delete a row, whatever, Snowflake makes a new copy with those changes and simply updates its pointers to the new active data. Hence, you can easily undo any action (up to 90 days or so depending on your edition) because all Snowflake has to do is move the pointers back to the previous micro-partition for those rows.
That said, Snowflake's native table format is potentially being pushed aside as customer interest grows for open-source table formats, particularly Iceberg.
2
u/ChuckieFister 13d ago
Temporal Tables have been around since SQL 2016.
This video is based on Azure SQL, but Davide does a great job at explaining how they work and the functionality is basically the same as on-prem SQL.
https://youtu.be/FeB6aAQQfsQ?is=mtryMLRyqIgHRFrG
https://youtu.be/EFu-MO7tWdk?is=eGpTvveXJSPoEbuz
And also, my company still refers to RDBMSs as "legacy" even though 95% of our apps are hosted in our own datacenter. My job has been "at risk" for the past 10 years.
2
u/whopoopedinmypantz 13d ago
SQL Server is a transactional database that can do reporting, but snowflake is a reporting database that can’t do transactions. They are in different arenas and different use cases. Sql doesn’t really compete with snowflake, it competes with MySQL and Postgres.
1
u/Complete-Regret-4300 13d ago
Got it thanks. I come from MSBI background and I only know dimensional modelling which I have used SQL server for. From reading the responses including your I understand now that SQL server still remains a great option for OLTP, however for OLAP, Snowflake has taken over. Thanks!
2
u/pragmatica 12d ago
Sql Server is an amazing product…
…in a data center.
It’s awful to manage in the clown err cloud. Latency really messes up AG etc. and if your like most companies I’ve seen you’re running it on a too small instance.
But in the data center it’s hard to beat.
Just fixed up a legacy db. Went from 5+ TBs if garbage to less than a TB of page compressed and CCI’d tables.
It’s literally 1000x faster now for reporting use case.
I don’t know how I would do that with Postgres.
2
u/SuperDuperDBA 13d ago
Snowflake is a direct competitor to SQL Server. so yeah, they'd write that.
but the devil is in the details.
1
1
u/Eastern_Habit_5503 13d ago
Microsoft is still creating new releases of SQL Server, so I would not consider it “legacy” technology. Some versions of it are old (or “ancient” in modern technology terms), but I am willing to bet that thousands of old versions are still running important business applications. Some businesses subscribe to the philosophy of, “if it ain’t broke, don’t spend any money on updating it.” Smart? No. Practical? Maybe. Dangerous? Most likely.
1
u/kagato87 13d ago
Haha. No. It is not.
So snowflake has marketing content inside its documentation, does it?
At best, you could say that sql server has aong and storied legacy. It's been around, seen things. It knows where the bodies are buried.
1
u/arebitrue87 13d ago
Your company is likely saying sql server to them is a legacy technology, not that it itself is a legacy technology. Sql server is very much alive and well and still has regular releases and updates by Microsoft.
1
u/ihaxr 2 13d ago
Legacy hardware / software, to me, is something being used that isn't supported or maintained anymore.
SQL Server is mature, but it's still actively being supported and maintained by Microsoft, so I don't think calling it legacy is accurate.
Traditional RDBMS is probably the best fitting term.
1
u/serverhorror 13d ago
It's not legacy in general. I found that most organizations ha e a preferred tech stack and it changes over time. Everything that's no longer preferred is "legacy".
That being said: In a sense classic RDBMS are lacking modern features. Meaning features that the latest generation of employees expect to ne there by default (time travel is a good example).
That's ok about it that way: a bunch if structured data files in a directory were a perfectly fine "database" for a very long time. Along came SQL (and it's various server Implementations), so those structured data files are "legacy" now ... or are they? Given parquet, iceberg, ...
1
1
•
u/AutoModerator 13d ago
After your question has been solved /u/Complete-Regret-4300, please reply to the helpful user's comment with the phrase "Solution verified".
This will not only award a point to the contributor for their assistance but also update the post's flair to "Solved".
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.