What needs improvement with SQL Server?

There is a limitation in the SQL. There are around 4GB restrictions, which Microsoft needs to work on. If your data volume is higher, your server performance may suffer. Microsoft needs to focus on improving stability in such scenarios.

The pricing and quality of the product could be improved.

Improvement in SQL Server should focus on lowering the high cost, especially for environments requiring extensive CPU and memory usage like data warehousing. While existing features are great, affordability is a significant concern, particularly for enterprise licenses. Additionally, enhancements in managing availability groups and clustering could be beneficial.

The solution's stability can be improved.

The solution should provide users with features to automate some of the daily routines for which there are different tools available. SQL Server should serve as an out-of-the-box tool for database maintenance. Maintenance of the solution is an area of concern, and improvements can be helpful. The solution should offer an out-of-the-box tool with automatic maintenance procedures, which could make it easier for less experienced people to set up the product easily.

The interface of the tool has certain shortcomings, making it an area where improvements are required.

The tool's support needs to be improved.

The tool needs to improve its pricing and technical support.

Over the years additional features, data warehousing, cubing, just better performance and better manageability in terms of the actual Microsoft SQL Server AppLINK console.

The pricing could be better.

There is a lot of room for improvement when it comes to limited compatibility across the platform and restricted performance with massive data sets. Enhancing those two areas would significantly improve the operation. It is important to mention the licensing cost, as well. Optimization of the licensing options to fit different needs and businesses would be of great benefit.

There is room for improvement in terms of pricing for SQL Server.

I have experience working with SQL Server 2016 and older versions, including handling JSON data. Initially, I found the JSON capabilities to be less helpful, but over time, they have greatly improved. SQL Server now offers extensive capabilities for working with various forms of data, particularly when communicating with text, such as in JSON format. I particularly prefer working with these features on Azure, as it provides numerous possibilities, especially in the field of business intelligence (BI). Additionally, the serverless platform offered by Azure is highly beneficial and makes tasks easier to manage. I have not seen significant returns thus far, but I am eager to enhance my experience by transitioning to work in Azure. This shift to Azure is something I am motivated to improve upon.

I think that performance could be improved and SQL presents some challenges for us.

The tool is expensive.

Oh... a chance to say what would be better in SQL Server? This is Data warehouse-related only.

1. Have more than 1 column as the partitioning column. We implement partitioning manually to be able to get 90% of the EE performance on SE because SE is so much cheaper.

2. Have materialised views able to be created on top of views and not on top of the underlying tables. We use meaningless table names and we have virtual tables co-habit physical tables. So materialised views requiring the table name to be used is way too much work and maintenance for how we build models. So we are maintaining our multi-level data using our ETL software. But Materialised views, implemented over views, would remove the need to maintain those levels in code.

3. Proper bit-mapped indexing to be able to perform vector joins on dimensional models on SE. That would be nice. Query plan resolution at detailed level results in slower queries so we do 95%+ of all queries on summary data that we maintain through our ETL software.

Those are the "big 3" that would make our life easier for dimensional modeling on top of SE.

My experience with SQL Server has been doing database testing with UFT. The main challenge we encountered is finding the correct connection string to use when performing database testing. Other than that, we encountered no issues.

They can build more performance-tuning tools in it. They can also make the stuff a little more user-friendly and provide the ability to schedule jobs. They can perhaps also streamline it a little bit so that it is not so resource-intensive, which would be helpful. SQL Server has a tendency to consume all the memory you allow it to. If you are not careful, you can basically break your server. I would like to see it having a smaller footprint in terms of system resource consumption. They might want to consider re-evaluating their pricing. It is expensive.

The way to make cursors and manage raw data in rows can be improved. Currently, the way to construct or build these cursors is very hard, and you can waste memory. You need a highly skilled person to make it more efficient. It can also have support for Cubes, which is the organization of data in different dimensions by using MDX languages.

Performance-wise, SQL cannot handle large amounts of data. In the next release, I would like them to commission SQL Server on Linux, as has been announced in the past but has not yet happened.

The solution could have additional security.

When we are talking about event space architecture, scalability generally comes into play. For example, I might have a hundred thousand transactions a second, and then all of a sudden, I build something that everybody in the world wants. The next thing I know is that I have a million transactions a second. So, to be able to process the throughput, I'd have to scale up, and then when the holidays are over, I'm again down to a hundred thousand transactions, and I want to scale back down. SQL Server is not going to do that. In this way, it is not very scalable. One of the reasons why they want us to use Kafka is so that if we need to, we can do that, but our base program is on SQL Server. So, this is where we would use a Kafka event stack so that if I need more servers, I can just write a command, and I can have more consumers, more brokers, and more producers, and when the holiday season is over, it scales right back down again. SQL Server is not going to do that.

I would like Microsoft to evolve SQL Server because stateful databases dying are in a way. We would like to find out if it can absorb Hadoop and other similar things. They should make it useful for data mining. Data is evolving forever, and how we store it is also changing constantly. So, SQL Server also needs to change.

The pricing could be more affordable. It's like to see less frequent updates. They should be once a month.

SQL Server backups could be better.

There are a lot of things that it doesn't do in terms of business intelligence. However, you can live without a lot of them. A lot of people want AI/ML features, but SQL Server does not really support that space. R is included but it's kind of clunky. That said, you're not going to do AI/ML with SQL Server because you're going to use Synapse, Databricks, or another similar tools. SQL Server doesn't have proper bitmap indexing, a proper columnar database version, or proper implementation of materialized views. For example, if you want to do a materialized view, you can only do one on the base tables. You can't do a materialized view on top of another view. For us that makes materialized views useless.

In my experience, while working with multiple sectors, such as banking, services, et cetera, there are some limitations for some sectors when dealing with the data. It would be great if we were able to run it on multiple operating systems and not only stick with Windows.

They need to improve their support. It should be faster.

Other than Synapse and the other version of SQL Server, they face some problems while processing the data. For example, the one issue we face is that when we need to process the queue, it's costly with Azure and SQL Servers. We also face some memory issues with that.

The way SQL Server pivots data could be improved. For example, I would like built-in comma-separated pivot and unpivot functions.

Something that could be improved is the cost because it's very high. That's the only thing I'm concerned about but the technology is good. We are looking forward to getting some discounts because we have a large amount of data.

SQL Server could improve by having better usability or user guidance.

If I compare the solution with current technology needs, like NoSQL, that have been prevailing now, they could improve it so there could be a single solution, where we could deal with a single database for both transactional as well as for the in-memory needs that we have. For the integration part, additional interfaces would be an improvement. If SQL Server could expose certain APIs or certain interfaces which can be used for integration with the warehouse solution, then it would be great.

If SQL Server could perhaps run on Linux, that would be good. Most of us prefer Linux and I've used a lot of Linux. I understand that SQL Server is quite powerful, but I'm not sure if the functionality is there, but if it could be used in an open-source type of environment, it would be very good.

They could increase the intelligence of SQL Server. That would be good for us. There are some good intelligent features in SQL Server. However, they need to increase the intelligence because people switching to SQL Server from other solutions are not so familiar with it. I've been working with SQL Server for the last six years, but people are coming from MySQL or Oracle, so it will take one or two months to adjust. Still, they could add some intelligent tools to convert Oracle into SQL Server something like that. And sometimes when I'm writing a function, there is already a predefined structure available. So if they defined their structure more precisely, that would be good for us. And the last thing I would like to add is that SQL Server should handle queries more like Oracle does. For example, you submit a query in Oracle, and the whole table comes up. In SQL Server, you go to the table, right-click, and it lets you see the first 200 rows. Then on top of that, you can add 200 more rows. So in place of those 200 rows, if I can update all my table records or search my table record without a new search query, it'll be very beneficial. That functionality exists in Oracle, but this feature is not available everywhere in SQL Server. So if SQL Server had the feature, it'd be great because SQL Server is lacking only on this point. For example, one of my clients is a semi-technical person, so I have to train them to file a query in SQL. And they say that Oracle is much better. Say, for example, that I wanted to query a particular employee from a list of all staff. So the query output comes, and they can directly filter out the data by just applying the filter. They don't have to use the drop-down menu and search for all the employees with a given name.

While this is a reliable product, it has room for improvement. Although Microsoft SQL was accessible in some projects, we did not use it everywhere. It is determined by the project. It's quite beneficial in some circumstances, but it couldn't support SQL databases in others, consequently, we used other suppliers like Oracle, Informix DB, PostgreSQL, MySQL, and others.

SQL Server could integrate better with other platforms.

Its ability to handle certain kinds of large data could be improved. Its high availability, segmentation, and disaster recovery features can be improved upon also. There are not really any significant features that I'd like to see added to it.

SQL Server could improve by enhancing the integration abilities, adding more inbuilt data security features, and simplifying the maintenance.

The Management Studio is a pretty heavy piece of software, and it's sometimes slow. I would recommend making an express version of the Management Studio, which is lighter and has fewer features but is a little faster.

The solution could improve by being more user-friendly.

If it would be more powerful it would be pretty nice. The performance is not always the best. Whenever we were setting up the databases, there were some character problems that did not exist on some of the other solutions. However, the exact issues are hard to recall and list. I prefer Linux solutions. That said, when we began the previous project, Microsoft SQL Server was not available for Linux platforms yet. Nowadays, it's my understanding that there are different versions. I haven't been checking if the current versions are supporting Transact-SQL and stuff like that. I remember that when we had the first Linux-based SQL Servers were introduced, they were, of course, a bit limited from the feature point of view. Whenever it is Unix or Linux or whatever platform, it's easier to manage them and to handle them whenever you are doing remote work. I'm not so big fan of the Microsoft platforms as a server. However, whenever it's needed then it's needed. If you are a consultant, you need to adjust your whole mindset to whatever it's needed.

For small-scale businesses, Microsoft could improve by removing some limits in SQL Express. In the future, it would be a benefit to have web-based management capabilities.

It could be more stable.

The price could be better. It costs a lot, and competing databases like Postgres are free.

SQL Server could improve by increase the performance, it cannot handle large amounts of data. I did not find any additional features compared to others solutions.

We'd like the deployment process to be better in the future. The licensing is pretty expensive.

SQL Server could improve by providing something similar to an interface or dashboard where a developer can do debugging, this would make a developer's work easier. Additionally, the optimization could be better. If there was an interface showing information needed for the optimization it would help because there can be some data loss making it difficult to optimize the SQL Server.

They could improve by adding the SQL format.

It would be better if it had more integration with other systems.

In terms of exceptionally large databases, it doesn't scale as well as Oracle. It scales excellently and it's flexible and it can provide a solution for exceptionally large databases, but it doesn't work as well as Oracle does for this particular use case. The performance starts to drag in the case of exceptionally large databases; especially where there's a lot more feature functionality. With Oracle, there's a lot more tunability.

They have too many licensing options. They may want to simplify its licensing and bring it down to two, three, or four categories from ten to fifteen categories. Having so many different licensing options makes it difficult to decide which one to choose from. They can club things together. This is an area where they can make things easier for customers.

The stored procedure integration with our development could be better. Things are always changing very fast at Microsoft, and it takes a lot of resources to get on top of it. We're struggling with version control. In terms of new features, we don't have any feature requests. We are not focusing on the database.

If you work with more than 50 gigs of data, it will run slower than Oracle. Security is an area that can be improved. It could be more secure; more security is needed. We have some clients who have been exposed to the SQL injection virus. We would like SQL to be able to manage this problem or to come up with an alerting system to alert the user that the server has been exposed. This has become more of an issue because of the Corona Virus and people are working from home. Some have been infected by the SQL injection Virus and will lose their data.

The Standard Edition and Enterprise Edition have certain limitations. While the latter is clearly more expensive than the former, it would be nice to see some of the features in the Enterprise Edition be moved to the Standard Edition. This will encourage many more people to use that solution. If we were discussing the 2000 edition in respect of the SQL Server, I would probably cite security and performance as issues. However, nowadays, when it comes to an application connected to their databases, there is no real difference between MS SQL Server and Oracle. As a consequence, it would be nice to see the application be made more cost-effective. I am aware of much database self-management in respect of Oracle. I know that the last time a colleague of mine used this solution in California, he informed me that the application itself was managing the database. At present, the solution uses the older connection and the schema is designed in such a way that it can actually provide a very low level of virtualization. Since the security is also hierarchical within the system, they've really done a very good job. This said, I would like to see the database become fully automated.

The solution should be more secure and stable and have better performance, particularly as concerns the endpoint operating systems. I would like to have a better operating system that links the CPU and the RAM efficiently. For the majority of our servers we have not used other operating systems, although there are certain features or requirements that necessitated their use, such as Red Hat. This was rare. Mostly, we used Windows OS. As for the performance issue, we have recently encountered situations in which everything would fail in spite of the CPU and memory being 100 percent operable.

The solution needs to be more secure. It's lacking, compared to, for example, Oracle. The product needs to work on its scalability. Oracle can scale a bit more effectively. Sometimes we have some performance issues. It's not like Oracle. Oracle is more powerful in terms of performance.

I think the scalability of the database could be improved if it could handle increased volumes of data. I'd also like to see improvement in performance when you are loading big amounts of data. Integration with other solutions would be a nice additional feature.

Primarily, the data replication and the backup areas can be improved. It should have data replication capabilities and uptime capabilities. The native SQL Server Backups take more time than do the backup processes from LiteSpeed, and the backup compression is a little less.

The installation process should be simplified. The configuration could be easier.

Security is an issue. This is an area that needs to be improved. There is security built-in, but most of the developers don't emphasize the security enough. When they are building the products or databases, they don't focus on the security of the database.

The solution was delivered to us, and we really don't interface with the solution directly. I can't speak to any features that are missing. The only people that can use it directly are developers. It's not for everyday users. The pricing in general could be better.

We're quite satisfied with the solution. There aren't any outstanding features we would like to add. The interface could be updated to make it slightly more user-friendly.

Microsoft doesn't have active-active load balancing scenarios. It's always a failover cluster. There is no active-active cluster, which other tools, other database providers like Oracle, provide. If Microsoft can consider or probably come up with an active-active cluster, then it would be good. It will be more powerful in a scenario like that. The pricing, while not the most expensive, is still quite high. They have something called Parallel Queries, however, I don't know how it works. I've never tested it in a horizontal way. I'd like to understand a bit more about it and be able to use it horizontally.

In my experience, I've found that scalability can be improved.

The solution is very different from Oracle, which is a product we also use. Mainly the data capacity needs to be improved. The data values are limited. They are smaller or medium scale. The MySQL is working fine, however, when it comes to large data sets or large data volumes, Oracle can handle them better. The backup capacity needs to be bigger.

Indexing, as well as integration, are areas of this product that need improvement.

We had some difficulty doing the performance tuning when we migrated from the 2008 version to the 2016 version. We experienced a drop in the performance. We could not understand or figure out what caused the drop in performance. We did not change any settings to cause this effect. We tried to keep the same settings. We feel that when running the 2008 version, it was much quicker in terms of performance. That is an area of SQL Server that can be improved. Moving to a new version, you shouldn't have to change the configuration. We have not been able to utilize it fully because it is not straightforward. I would like to see the performance improved. Migrating should be easier and the scalability needs improvement.

I would like to see more integration with other products and it needs to be more secure.

The Message Broker portion of the solution is not very scalable in comparison to the rest of the solution. The problem is, you can exclude that portion. The Task Scheduler has a lot of shortcomings. This could be improved quite a bit. The enterprise version of the product should be more cost-effective.

It is costly to implement high throughput systems, beyond millions of transactions per second. The hardware to run the systems, especially for high availability deployments is expensive, i.e. more resources to run. Linux-based editions are not yet proven to be on par with Windows deployments. Row-level security is obscure to implement. Running cloud offerings are expensive; for example, the Instance as a Service offering. Third-party tooling is required to manage code version control. Managing BLOB data is not equally simple to implement. The engine that implements query plans was updated in the 2012/2014 refresh that could necessitate a costly rewrite of queries.

We have had problems implementing a data warehouse using SQL Server. It may be because the data is too big, although it claims to be able to handle the amount of data that we have. Perhaps there are some technical issues because there is something weird going on. It cannot find the correct IP address.

Better integration with other platforms would be an improvement.

There should be more tools and documentation for tuning the performance of Microsoft SQL Server. It would be nice to have more tools for tuning because currently, all the tuning that we have to do with our databases is almost manual. We have to read a bunch of knowledge base articles, and this information should be better documented. Its free text search should also be improved. It is quite important for us. Currently, we're developing our own free text search because of the lacking flexibility in Microsoft SQL Server. Therefore, we're kind of using elastic search and making different implementations in order to reach our targets. Using just the native free text search of Microsoft SQL Server is not enough for us. It should have more flexible features as compared to the current version.

The performance could be better. When we pump in millions of records, we start struggling, and that's why we want improvement in those areas.

It's night and day if you compare it to Oracle, and I am an Oracle fan. Their datatypes need improvement. The SQL Server language in itself, its datatypes, seem like they are stuck in the eighties. Even companies that work with an SQL Server, experts on J.D. Edwards that sits on SQL Server that handles all the data transformation, they've actually converted the SQL Server datatypes so that they are more useful and easy to handle on their solutions. That tells you right then and there that their datatypes must improve. When you run your SQL optimizer there, on the datatypes, it's very costly because it's just this level of conversion that needs to happen as opposed to just calling it numeric, or as opposed to calling it something else. Their datatypes technically work. If you know what you're doing, it really can give you all that. However, on the optimization side, on the performance side, it does struggle. The datatype conversion to push my data to an enterprise data warehouse is difficult. I can tell you Oracle data is so much easier to ingest into it and it easier than doing it on a SQL Server. There are many issues that I face when I'm pulling data straight from a SQL Server agent. There are more collections that I need to do or handle before it hits my target table. I noticed that due to the fact that I've been working on different databases and ingesting everything in a data warehouse. It just doesn't flow properly. Even on their SQL Studios, that Master Studio tools, even if you try to do your conversions on their own, even though this is their native tool, you're always going to have some problems and it's always going to give you some type of error. It is just difficult to tell you what the error will be. You have to dig in and figure it out. Most of that is due to datatypes. It's just not easy. It's like pulling teeth. Especially if you have had experience using a tool, like Oracle, that is just not that painful. There seems to be a lot of patching, which leads me to believe there may often be stability issues.

The solution has legacy issues when it comes to compatibility. If you have older technology, you may run into compatibility problems with SQL. The solution is rather expensive.

The licensing costs are very high. I would like the scaling process to be more transparent and obvious. There's a lot of documentation on the web, and it is quite extensive, and yet it isn't very well organized which makes it hard to find items often.

There are a lot of improvements in the cloud space about which we open a case with Microsoft every now and then. These improvements are not in terms of features or functionality. They are more related to their own compatibility or connectivity on which they keep on working to improve the product.

Our customers are willing to pay less. For SQL server they have to buy it, they have to purchase the license. So, if we can get some free open source, like Firebird, InterBase, Firebase, or something like MySQL and also PostgreSQL, whichever one is suitable for us, we'd like to pick one. Additionally, in some cases it is quite difficult, like the lack of ease of the replication and other issues. They have to improve on that. They do not have features like "always on," which is complicated. One feature which we don't like is that they are providing CLR, and CLR can only be written in dot net, C sharp. But actually it should be open for all languages to write CLR so that we can hide our code. The next thing is that the tangent PSQ is encryptable but it is decryptable, as well. From the developer's point of view, all procedures are exposed.

If you have a lot of data and you want to perform computations on it, you will have problems and the performance will be degraded. There are problems when you are dealing with Big Data and it doesn't scale very well. For example, in Hadoop, you can partition your data very well, but in SQL Server, you can't do that. If it could handle horizontal scaling then that would be an improvement. We experience latency at times when there is a lot of data being processed. In Iran, there is a specific time when all of the markets are open, and a lot of people are using the data to make decisions. Performing actions at that specific time gives us a lot of problems because of limitations in SQL Server. The problem seems to be caused by writing a lot of data to the table at the same time. Improving the intelligence for managing the SQL server would be very good.

The solution could use better governance on the management side, especially around data governance. The product could do better at allowing for integrations.

Due to the fact that I'm dealing with the product more as a data analyst, the SQL Server management studio is really relatively primitive compared to other more advanced tools. There are other tools on the market that are much more advanced. It would be better if they managed to give us a bit more of a user-friendly product with just a bit more meat on the bone. It's a bit basic. There are a number of features that are lacking. Just recently I had to do something and it's not available on the SQL Server. However, it's available on another solution that's actually a much cheaper product. Some areas need improvement. For example, how you deal with the manipulation of data is probably not the best.

With any development language, any programming or software language available, there's always room for improvement. With SQL, it requires the more advanced integrated capabilities of Postgres, however, those capabilities do really come with obvious kinds of costs. For example, if SQL were to improve its functionality to incorporate the functionality that is in Postgres. Obviously, some kind of financial licensing will need to be incorporated. It's a bit of a catch-22 with a system similar to an SQL Server. If we want to avoid costs, we have to take a step back from certain integration capabilities. From a development perspective, the solution needs to be a lot easier to understand or it needs to be easier to implement API packages for connection pooling so we don't have connection interruptions when, let's say, a hundred people simultaneously access the network on a given system, utilizing a specific or single database. Any type of connection pool or connection integration that could increase the total number of users to access simultaneously would be beneficial. That said, I also know there are some security risks involved with that type of connection pooling. However, something from SQL-side that can increase its connection access or its connection stability for multiple user access to a single database system would be great.

Scalability is an area that needs improvement, and the deployment is difficult, which why I'm looking for an appliance to deploy it in a much more scalable way. I would like to know how you can scale to be a large enterprise server.

We would like to have a common storage option in the SQL Server. This option is available in Oracle Database. It would be great if Microsoft could create something like a columnstore that has not only indexing but also tables for common storage.

Overall, the solution could be improved in future releases. We hope to improve the way we use it ourselves in our next project. The solution could offer better integration with other solutions - specifically Microsoft.

Price could be cheaper, and access to reporting tools should be better.

The pricing could be improved. I would like to have the option to use fewer processors for certain tasks, thus reducing the licensing fee. That would be great.

I think a web console for the management studio, I think that would be a good thing. I think also on load balancing. I think that's something that we can use.

The time series database could be improved. There needs to be more storage space for large documents. The user interface and the reporting could also be improved. It's not bad, but it could be improved upon.

The performance needs some improvement and it needs more features integrated into it. Technical support could be better. Scalability could be less costly. One of the conflicts with Microsoft is if you have an enterprise relationship, you have to deal with a third-party offering Microsoft solutions. In the 2016 version, they don't have support for Python. It may be included with the 2019 version but if they don't, I would like to see support for Python implemented.

CAL licenses should cost less. Microsoft usually prices high for client access licenses. Server plus user client access license (CAL) licensing requires a separate Server license for each server on which the software is installed, plus a user CAL for each user accessing the server. A SQL Server CAL is required for a user to access or use the services or functionality of either edition of SQL Server and frequent updates to the latest versions will lead to obsolete and discontinuing the security patches has to be improved.

The scalability and the high availability feature can be expanded or improved. Currently, there is a limitation on scalability. A feature similar to the Oracle Diagnostic feature can be included to provide a better user experience.

The server itself doesn't need much improvement. The product overall would benefit from the addition of better tutorials to help master the skills necessary to actually build a project database. Right now, what is available isn't sufficient. Overall, I would suggest a nice tight integration with the toolset now known as Power BI. It might not even be missing, however, I'm planning to concentrate a lot of my time with the tutorials and I have Power BI loaded onto my HP laptop. bA brilliant student did it for me when she demoed it in a class. I'm going to use that copy of it and have many tutorials to get ready.

I'd like to see a simplification of the query optimizer and feel that SQL needs to look into the internal processing of the query because the query optimizer sometimes uses a different query plan, which we don't expect. It is similar to the triggers they have which are used after execution and not before. For example, if I'm running a query, my trigger will be run after the query has executed although I sometimes need the trigger before execution. That's a feature not supported by the product.

The number of concurrent users is too limited and other databases are better than SQL in this regard. There are limitations with load balancing. We would like to see support for in-memory processing.

In terms of what could be improved, everything on-premises is now moving to the cloud. Obviously SQL Server has also moved because Microsoft has its own cloud called Azure SQL and azure synapse. Every solution comes with its own advantages and disadvantages. Each cloud has its own way to maintain resources and that plays a major role. But I would say that Azure Clouds are easy to work as compared to others. To Performance-wise it's still not as good as on-premises, but it is easy to work with. For example, if you are familiar with the SQL server then you don't need to put any effort to work on the Azure SQL or Azure Synapse. Your efficiency will not decrease and you can easily manage any projects. Its advantage is that it is very similar. Apart from that, if you moving to any other Warehouse like Snowflake, redshift with existing SQL server resources is a little difficult and organizations need to spend money on their training. Which increases cost.

Occasionally the performance, as good as it is, is a bit off. We sometimes experience memory spiking. If they could maybe fix that aspect of the solution, that would be quite helpful for our organization.

In terms of improvement, it could use more integration with other products.

I would like to have more replication scenarios.

I would like to see native plugins built for other platforms versus having to buy third-party plugins to tap into S3 buckets and AWS Cloud. Right now, it does not have those built-in plugins. I know that they are building SQL Server for the Unix environment, which is in the beta version, and not out yet. This has been a long time wish for a lot of people. Once that is out, we'll be able to tell how diversified they have become in regards to other platforms. It hasn't 100 percent on scalability and third-party plugins.

Every good tool has its own limitations. * First of all its cost. It is very high. * We need a good amount of RAM to properly use this. * Sometimes, query sticks in between. But our organization provides great RAM, so we don't have any issue with its speed.

Horizontal partitioning. In that case, cold , warm and hot data can be distributed into different database not only table partition located on different FGs .

I would like a mature real-monitoring built in into SSMS, even a trace file analyzer.

* It does not scale up to a truly global environment. We operate in 220+ countries and territories with data services centralized in three data centers. The ability for MS SQL to operate in this environment is a challenge for anything spanning regions or having a global footprint. * It is best suited to supporting a single functional instance by business domain or a single country. * MS needs to work better at the WAN implementations transoceanic. * It also needs to have a less closed or less MS centric tool dependency as integration with other databases and non-MS development environments is always problematic.

It would be nice to search for specific value across multiple tables. This would save a lot of time.

* Third-party services from Redgate should be built-in to it, like SQL Search. * Debugging from the debugger tool functionality should be enhanced.

Improvements to the indexing, columnstore indexing, and high availability groups are good improvements for future versions.