Senior Advisor at a government with 10,001+ employees
Real User
Top 20
Dec 4, 2025
SAP is not putting money into modernizing SAP Adaptive Server Enterprise. One of the things I discovered on the last project I was on was that they did not incorporate the Intel new instruction set in SAP Adaptive Server Enterprise. Intel has augmented its instruction set referred to as new instructions. They did that to make conversion easier. When you migrate SAP Adaptive Server Enterprise cross-platform, you go through a process where it converts the character set. If you are going from AIX to Linux or from Solaris to Linux, Linux is referred to as Little Endian, while AIX or Solaris are considered Big Endian. This is determined by how the product stores data. The word size of these processors is 32 bits long. If you start numbering from the little end, it is referred to as Little Endian. If you start numbering from the big end, it is called Big Endian. To migrate a SAP Adaptive Server Enterprise database from a Big Endian setup like AIX or Solaris to migrate to a Big Endian setup on an Intel, the operating system determines whether it is Little Endian or Big Endian. When you migrate from Big Endian to Little Endian, the database has to go through a character set conversion, and some of these databases are quite large with gigabytes and gigabytes of data. They have to do a character set conversion to the existing database before they do anything else. The worst part is that you have to rebuild all the indexes when you do that. When you switch endianness of the database, you have to rebuild all the indexes. It will automatically do that for system tables, but for actual user databases, you have to rebuild all your indexes, and it takes a long time. SAP Adaptive Server Enterprise is a relational database and is the predecessor of Microsoft SQL Server. All that functionality that Microsoft SQL Server had came from essentially SAP Adaptive Server Enterprise. The problem with SAP Adaptive Server Enterprise these days is it is not expanding its place in the marketplace or expanding its position in the marketplace. A lot of companies have migrated away from SAP Adaptive Server Enterprise. It works fairly well, but the problem is SAP Adaptive Server Enterprise was architected to be an OLTP engine and is now doing things for larger databases that were not in its original intended purpose. The endianness of the RDBMS is a major impediment to continuing to use SAP Adaptive Server Enterprise. You have a multi-gigabyte database, and it will go through a conversion process in a single-threaded fashion, and then you have to rebuild the indexes. Rebuilding the indexes is lengthy and time-consuming. The part of the conversion process that is concerned with conversion of the character set is single-threaded. You may have eight cores on your machine or virtual machine and only one can be used in the conversion process. There is another problem with the whole thing in that it will sometimes not operate properly. Under certain workloads, SAP Adaptive Server Enterprise will become overwhelmed. When you convert it, it does not operate properly in all circumstances. The root cause of that is that SAP in its desire to save money and desire to orphan the product has not recompiled or redeveloped the product to take advantage of the Intel new instruction set. Other relational databases such as Oracle and Microsoft SQL Server have the same issue to deal with, but with those platforms, they are taking advantage of the new instruction set. There are some additional Intel instruction sets or instructions in their Intel instruction set. With SAP Adaptive Server Enterprise, they did not bother to incorporate support for the new instruction set instructions. In certain circumstances, the database does not operate properly. It is unable to do what it needs to do. If you do your research and go on the internet and see what happens with Oracle or Microsoft SQL Server, what comes back is that it takes 4% longer to perform a lot of the instructions. When you are using the new instruction set, it adds 4% to the runtime of the database.
Technical Consultant and SME at a tech vendor with 10,001+ employees
Real User
Top 10
Nov 4, 2025
I see drawbacks here, particularly with deadlocks. When we acquire a new project that is sometimes related to data migrations, after getting those data, there are lots of deadlocks happening. The query part that application users are running requires a very fine-tuned query, or else it will take a longer period of time. If you are using the built-in query optimizers, those are very fast. If you are introducing your own query, the first time it will take five minutes, but from later on, it will be within seconds or fractions of time to generate the data.
Principal Engineer at a tech services company with 1,001-5,000 employees
Real User
Top 5
May 13, 2024
The main thing is it's not getting upgraded to meet today's needs. It's not upgrading at the level of transaction needs. For example, PostgreSQL or Oracle, these are pretty good databases. They can handle much heavier transactions and produce enterprise-level query plans. But SAP ASE is lagging behind in those things. Secondly, in my opinion, product support is not that great from SAP because they have already declared the end-of-date for SAP ASE. They will be stopping product support. Since they have already declared the end of life for the product, something around 2025 or 2030, SAP ASE plans to decommission this whole product line itself.
Systems Engineer at a tech services company with 1-10 employees
Reseller
Top 5
Sep 25, 2023
The solution should improve view partitioning. The documentation is very confined and available only for users. Distributors also would like access to it.
SAP should refine its debugging method, and the process needs to be a little faster. It should use more Pragmas and fewer pseudocomments. I would like if SAP added more features based on advanced technologies, like artificial intelligence and voice control. The modularization and if-else techniques could also incorporate the latest technology to code and solve complex problems. The SAP Editor should be more elaborative, and it should allow many more types of statements for all uses.
Learn what your peers think about SAP Adaptive Server Enterprise. Get advice and tips from experienced pros sharing their opinions. Updated: January 2026.
I think that the solution needs to be positioned better within the market as it appears as though the Adaptive Server is being left out of the SAP scope.
Executive Director at a non-profit with 1-10 employees
Real User
Jul 7, 2021
I'd like to see a more friendly user interface. The solution is complicated and some of the field engineers, who are less exposed to the solution, are having problems which could be solved by simplification. The concern is that the data they provide might not be accurate and simplification would resolve that issue. I think the management feels that more can be done to get better value. The issue is not the performance of the product but the usability for people who are less skilled in using it. Additional training would be helpful, but because of the nature of operations, those that support staff from the office find it easier because we spend more time using it than those in the field. Most of our engineers are on rigs, so it's a bit difficult getting them to come off the rigs for training, because that would require our operations to shut down.
SAP Adaptive Server Enterprise (ASE) is a high-performance relational database management system designed for mission-critical, data-intensive environments. It provides a centralized environment for storing and managing data, with the ability to handle a wide range of data types and a modularization technique allowing easy customization.
SAP ASE is particularly valuable for financial operations, as it offers integrated financial features. The solution also offers various control agents...
SAP is not putting money into modernizing SAP Adaptive Server Enterprise. One of the things I discovered on the last project I was on was that they did not incorporate the Intel new instruction set in SAP Adaptive Server Enterprise. Intel has augmented its instruction set referred to as new instructions. They did that to make conversion easier. When you migrate SAP Adaptive Server Enterprise cross-platform, you go through a process where it converts the character set. If you are going from AIX to Linux or from Solaris to Linux, Linux is referred to as Little Endian, while AIX or Solaris are considered Big Endian. This is determined by how the product stores data. The word size of these processors is 32 bits long. If you start numbering from the little end, it is referred to as Little Endian. If you start numbering from the big end, it is called Big Endian. To migrate a SAP Adaptive Server Enterprise database from a Big Endian setup like AIX or Solaris to migrate to a Big Endian setup on an Intel, the operating system determines whether it is Little Endian or Big Endian. When you migrate from Big Endian to Little Endian, the database has to go through a character set conversion, and some of these databases are quite large with gigabytes and gigabytes of data. They have to do a character set conversion to the existing database before they do anything else. The worst part is that you have to rebuild all the indexes when you do that. When you switch endianness of the database, you have to rebuild all the indexes. It will automatically do that for system tables, but for actual user databases, you have to rebuild all your indexes, and it takes a long time. SAP Adaptive Server Enterprise is a relational database and is the predecessor of Microsoft SQL Server. All that functionality that Microsoft SQL Server had came from essentially SAP Adaptive Server Enterprise. The problem with SAP Adaptive Server Enterprise these days is it is not expanding its place in the marketplace or expanding its position in the marketplace. A lot of companies have migrated away from SAP Adaptive Server Enterprise. It works fairly well, but the problem is SAP Adaptive Server Enterprise was architected to be an OLTP engine and is now doing things for larger databases that were not in its original intended purpose. The endianness of the RDBMS is a major impediment to continuing to use SAP Adaptive Server Enterprise. You have a multi-gigabyte database, and it will go through a conversion process in a single-threaded fashion, and then you have to rebuild the indexes. Rebuilding the indexes is lengthy and time-consuming. The part of the conversion process that is concerned with conversion of the character set is single-threaded. You may have eight cores on your machine or virtual machine and only one can be used in the conversion process. There is another problem with the whole thing in that it will sometimes not operate properly. Under certain workloads, SAP Adaptive Server Enterprise will become overwhelmed. When you convert it, it does not operate properly in all circumstances. The root cause of that is that SAP in its desire to save money and desire to orphan the product has not recompiled or redeveloped the product to take advantage of the Intel new instruction set. Other relational databases such as Oracle and Microsoft SQL Server have the same issue to deal with, but with those platforms, they are taking advantage of the new instruction set. There are some additional Intel instruction sets or instructions in their Intel instruction set. With SAP Adaptive Server Enterprise, they did not bother to incorporate support for the new instruction set instructions. In certain circumstances, the database does not operate properly. It is unable to do what it needs to do. If you do your research and go on the internet and see what happens with Oracle or Microsoft SQL Server, what comes back is that it takes 4% longer to perform a lot of the instructions. When you are using the new instruction set, it adds 4% to the runtime of the database.
I see drawbacks here, particularly with deadlocks. When we acquire a new project that is sometimes related to data migrations, after getting those data, there are lots of deadlocks happening. The query part that application users are running requires a very fine-tuned query, or else it will take a longer period of time. If you are using the built-in query optimizers, those are very fast. If you are introducing your own query, the first time it will take five minutes, but from later on, it will be within seconds or fractions of time to generate the data.
The main thing is it's not getting upgraded to meet today's needs. It's not upgrading at the level of transaction needs. For example, PostgreSQL or Oracle, these are pretty good databases. They can handle much heavier transactions and produce enterprise-level query plans. But SAP ASE is lagging behind in those things. Secondly, in my opinion, product support is not that great from SAP because they have already declared the end-of-date for SAP ASE. They will be stopping product support. Since they have already declared the end of life for the product, something around 2025 or 2030, SAP ASE plans to decommission this whole product line itself.
The solution should improve view partitioning. The documentation is very confined and available only for users. Distributors also would like access to it.
There is room for improvement. Cost-wise, SAP is still expensive compared to other available products. That would be a major difference.
SAP should refine its debugging method, and the process needs to be a little faster. It should use more Pragmas and fewer pseudocomments. I would like if SAP added more features based on advanced technologies, like artificial intelligence and voice control. The modularization and if-else techniques could also incorporate the latest technology to code and solve complex problems. The SAP Editor should be more elaborative, and it should allow many more types of statements for all uses.
I think that the solution needs to be positioned better within the market as it appears as though the Adaptive Server is being left out of the SAP scope.
I'd like to see a more friendly user interface. The solution is complicated and some of the field engineers, who are less exposed to the solution, are having problems which could be solved by simplification. The concern is that the data they provide might not be accurate and simplification would resolve that issue. I think the management feels that more can be done to get better value. The issue is not the performance of the product but the usability for people who are less skilled in using it. Additional training would be helpful, but because of the nature of operations, those that support staff from the office find it easier because we spend more time using it than those in the field. Most of our engineers are on rigs, so it's a bit difficult getting them to come off the rigs for training, because that would require our operations to shut down.
The product in use is already customized. For now, we have no need for major improvements or new features.