{"id":111503,"date":"2026-06-26T12:00:00","date_gmt":"2026-06-26T12:00:00","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=111503"},"modified":"2026-06-22T13:24:23","modified_gmt":"2026-06-22T13:24:23","slug":"5-t-sql-features-that-should-already-exist-2026-sql-server-wish-list","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/databases\/sql-server\/5-t-sql-features-that-should-already-exist-2026-sql-server-wish-list\/","title":{"rendered":"5 T-SQL features that should already exist (2026 SQL Server wish list)"},"content":{"rendered":"\n

SQL Server is one of the most mature database platforms in the world, but that doesn’t mean it’s finished. With T-SQL now spanning Fabric, Azure SQL Database, Synapse, and SQL Managed Instance, the gap between what the language can<\/em> do and what developers wish<\/em> it could do is more visible than ever. <\/strong><\/p>\n\n\n\n

From clunky flat-file imports to licensing models that require a legal degree to navigate, there are real pain points that slow down data engineers and DBAs daily. This is Ed Pollack’s frank, opinionated look at five meaningful improvements that would make SQL Server and T-SQL genuinely better – not just for power users, but for anyone building on Microsoft’s data platform in 2026.<\/strong><\/p>\n\n\n\n

It’s mid-2026, and Microsoft SQL Server<\/a> is an exceptionally mature database product. Even more important today is that T-SQL is becoming a multi-platform language – used in Fabric<\/a>, Azure SQL Database, Synapse, SQL Managed Instance<\/a>, and a variety of other applications.<\/p>\n\n\n\n

While each variant of T-SQL and each database platform is different in its implementation and details, there remain features that I continue to wish for – and request – on a regular basis.<\/p>\n\n\n\n

This article contains my thoughts on what is missing, what can be improved, and why. These are ultimately my opinions and will differ from others who have pondered this<\/a> before me, and those who may do so in the future. As a T-SQL junkie, these hopes and dreams skew towards the T-SQL surface area. <\/p>\n\n\n\n

Hopefully, when we look back on this in a few years, checkmarks can be placed next to some of these requests!<\/p>\n\n\n\n

Before we begin: a quick note on compatibility<\/h3>\n\n\n\n

SQL Server and T-SQL are large and ever-evolving platforms. Microsoft is thorough in documenting compatibility with different products, as well as with ANSI<\/a> standards. If you’re interested in learning more about these details, grab a (large) cup of coffee and check out their docs here<\/a>.<\/p>\n\n\n\n

Because of this, T-SQL supports a whole lot of different syntaxes, providing many different ways to solve most problems. There are also many features that are deprecated or maintained solely for backwards-compatibility. When choosing a solution, there’s value in picking one that’s currently supported (and will be so for the foreseeable future.)<\/p>\n\n\n\n

Now, onto the list!<\/p>\n\n\n\n

Wish #1: Import from compressed file formats<\/h2>\n\n\n\n

Moving data around for analytics<\/a>, reporting, or machine learning\/AI<\/a> can be a hassle. This sort of analytic data can get quite large and the file formats I want to store it in are the ones that are as small and efficient as possible. Compression is key here, so CSV<\/a> and Excel are not the formats I really want to deal with. <\/p>\n\n\n\n

There’s no need for bells and whistles: data will be written to files once, moved around, and then imported into SQL Server. Any downstream operations will benefit from smaller file sizes. Additionally, less computing resources will be needed overall to manage these files. This is especially true if files are to be copied, moved, archived, or ingested by multiple systems.<\/p>\n\n\n\n

Compatibility with other systems<\/h3>\n\n\n\n

For maximum compatibility with other systems – such as Synapse, Fabric<\/a>, or other data warehouses\/data lakes – the Apache Parquet<\/a> file format is ideal. There are other highly compressed file formats out there that provide different optimizations and more features – the likes of Iceberg<\/a>, ORC<\/a>, Delta Lake<\/a>, or Avro<\/a> – but these are designed to support transactional write operations<\/a>. Also, parquet files can be converted easily into Delta Lake or other formats if needed.<\/p>\n\n\n\n

\n
\n\n

You may also be interested in:<\/strong><\/p>\n\n\n\n

Reading and writing parquet files in SQL Server<\/a><\/p>\n\n<\/div>\n<\/div> \n\n\n

While this article I wrote last year<\/a> was a fun experiment, it was a workaround, and I\u2019d love a native integration into OPENROWSET<\/code> or bcp<\/code> to be available natively in SQL Server. Azure has supported parquet files for quite a while now, so why not SQL Server?<\/p>\n\n\n\n

I’d love to be able to execute code like this:<\/p>\n\n\n\n

SELECT\n\u00a0 *\nFROM OPENROWSET(BULK N'D:\\MyDataFiles\\CritcalSalesData_06_03_2026.parquet',\nFORMAT = 'PARQUET') AS PARQUETDATA;<\/pre><\/div>\n\n\n\n
As a big bonus, parquet files already contain metadata about column<\/a> and row structure. There is no need for format files, field terminators, code pages, and other minutia that occupy us when dealing with CSV or other plain text formats. Parquet includes details on data types, values<\/a>, NULLability, row counts, and more! <\/p>\n\n\n\n
What does this mean when importing parquet files? The benefits explained<\/h3>\n\n\n\n
This means that, when importing parquet files, many of the nightmares we’ve experienced in the past are avoided. This includes:<\/p>\n\n\n
\n