While implementing Amazon Athena, I observed an issue where, even after writing an exclusion pattern on the AWS Glue side, whenever the end user queries, it skips the exclusion pattern, overriding it and directly fetching data from the S3 bucket. For instance, if we have an input file in CSV format along with another Python file or a Parquet file within the same folder, Amazon Athena reads that file during the query and could create a problem known as the bad hive data error. This is a struggle, and the Amazon Athena team is currently working on resolving this issue. I have checked with them, and their technical team is working on it.My main concern is that whenever we have written an exclusion pattern during the ETL process on AWS Glue, Amazon Athena should use that pattern while querying and accessing data on S3. This is a crucial improvement area. One aspect that could be improved in Amazon Athena is that many changes are happening in the background as the AWS team alters their algorithms and code. It would be better if there is proper communication from the Amazon Athena team to end developers about these changes so they could align their thought processes or solutions accordingly.
Senior Software Engineer at a tech services company with 10,001+ employees
Real User
Top 5
Jul 8, 2026
Amazon Athena can be improved, especially when working with S3 tables, which is a caveat for us. It does not work very well with Amazon Athena, as we have to do multiple settings in terms of providing Lake Formation permissions and creating a separate federated catalog for S3 tables. This results in a messy experience when trying to work with S3 tables. We mainly wanted to work with S3 tables on top of Amazon Athena to reduce costs on data maintenance associated with Athena Iceberg. I want Amazon Athena to improve in this area.
I don't have any specific answer on how Amazon Athena can be improved. This integration is more on the Glue side rather than on Amazon Athena, I would guess. Nothing comes to my mind here. In terms of its integration capabilities, I would say it's not straightforward. It works, but it's a little bit tricky.
I think there is room for improvement in Amazon Athena, and the first thing I will put is the data output. I use Python to query in Amazon Athena, and it's very complex and difficult just to save Amazon Athena results as an Excel file. The only option is copying the data, but sometimes if it exceeds 100 lines, if you copy and paste in Excel, it's very bad. You can't copy above 100 lines. The other option is downloading a CSV file, but the CSV file is not UTF-8 Unicode. Here in Brazil, we speak Portuguese, and there are a lot of special characters in the words and even names, and everything gets garbled when you put it in a CSV. You have to decode, encode, and there are a lot of problems. It could easily save as an Excel file since there are a lot of engines to help with it, so an XLSX file extension could be this way. Another point I would mention is the word completion. When I'm coding and making statements and queries, Amazon Athena tries to help me write the code, and that's very problematic. Sometimes I'm using some tables that I use every day, and Amazon Athena doesn't get the tables I'm using and suggests very improbable data. I have access to more than 30 databases and hundreds of tables. So, I turn it off, I disable the word completion because when I'm coding, the word completion makes the coding slower. It's very difficult, and every time I have to press escape to skip the completion. It's very ineffective, so I disable it because in other applications it functions very well, such as VS Code.
Head of Data Practice at a tech consulting company with 201-500 employees
Real User
Top 5
Jan 23, 2023
I think it would be better if the product were more mature. It's still a young product compared to Power BI or Qlik. I find that development is a bit difficult, but it might be because I'm used to other tools. The dashboarding capabilities could be better. The reporting and statement generation could be better. I couldn't technically initiate picture-perfect reporting, for example, to send out statements every month for banking customers.
Software Developer at a tech services company with 51-200 employees
Real User
Jan 20, 2023
One improvement I can suggest is that Athena needs to work better with third-parties. For example, the process of querying a Microsoft SQL warehouse could be improved. When querying outside of AWS, you can use federated queries, but it's not always easy to do so.
Director & Lead Solutions Architect at Abylle Solutions
Real User
Dec 19, 2022
The solution should include a better API for query services so that data can be dumped and queried directly in customer's products. The API should include some sort of data visualization that can be plugged into applications. We had to use QuickSight to help us with the visualization.
If you compare it with Palantir, if you have some data and you want to quickly have a look at it, then that feature is not available in Amazon Cloud. We'd like it better if, for example, when you have some data, you can easily query it and you can easily read it at a glance. We'd like it to just be almost like a drag-and-drop situation. In Amazon Cloud, you actually have first to upload the data into S3. For that, you have to create a bucket. Now you have to create a Glue service, which will get you the schema. Then that schema would create basically a database and a table. After that, you have to go to Athena to query the data. It's a three-step process in Amazon Cloud. In Palantir, you just have to drag and drop.
Amazon Athena is a serverless, interactive query service for analyzing data in Amazon S3 using SQL. It efficiently supports data lake architectures and offers features for diverse data formats without needing extensive infrastructure. Athena's integration with AWS Glue enhances schema management. Amazon Athena leverages a serverless architecture to provide scalable, cost-effective query capabilities for large datasets stored in Amazon S3. With native support for Parquet and Avro, it...
While implementing Amazon Athena, I observed an issue where, even after writing an exclusion pattern on the AWS Glue side, whenever the end user queries, it skips the exclusion pattern, overriding it and directly fetching data from the S3 bucket. For instance, if we have an input file in CSV format along with another Python file or a Parquet file within the same folder, Amazon Athena reads that file during the query and could create a problem known as the bad hive data error. This is a struggle, and the Amazon Athena team is currently working on resolving this issue. I have checked with them, and their technical team is working on it.My main concern is that whenever we have written an exclusion pattern during the ETL process on AWS Glue, Amazon Athena should use that pattern while querying and accessing data on S3. This is a crucial improvement area. One aspect that could be improved in Amazon Athena is that many changes are happening in the background as the AWS team alters their algorithms and code. It would be better if there is proper communication from the Amazon Athena team to end developers about these changes so they could align their thought processes or solutions accordingly.
Amazon Athena can be improved, especially when working with S3 tables, which is a caveat for us. It does not work very well with Amazon Athena, as we have to do multiple settings in terms of providing Lake Formation permissions and creating a separate federated catalog for S3 tables. This results in a messy experience when trying to work with S3 tables. We mainly wanted to work with S3 tables on top of Amazon Athena to reduce costs on data maintenance associated with Athena Iceberg. I want Amazon Athena to improve in this area.
I don't have any specific answer on how Amazon Athena can be improved. This integration is more on the Glue side rather than on Amazon Athena, I would guess. Nothing comes to my mind here. In terms of its integration capabilities, I would say it's not straightforward. It works, but it's a little bit tricky.
I think there is room for improvement in Amazon Athena, and the first thing I will put is the data output. I use Python to query in Amazon Athena, and it's very complex and difficult just to save Amazon Athena results as an Excel file. The only option is copying the data, but sometimes if it exceeds 100 lines, if you copy and paste in Excel, it's very bad. You can't copy above 100 lines. The other option is downloading a CSV file, but the CSV file is not UTF-8 Unicode. Here in Brazil, we speak Portuguese, and there are a lot of special characters in the words and even names, and everything gets garbled when you put it in a CSV. You have to decode, encode, and there are a lot of problems. It could easily save as an Excel file since there are a lot of engines to help with it, so an XLSX file extension could be this way. Another point I would mention is the word completion. When I'm coding and making statements and queries, Amazon Athena tries to help me write the code, and that's very problematic. Sometimes I'm using some tables that I use every day, and Amazon Athena doesn't get the tables I'm using and suggests very improbable data. I have access to more than 30 databases and hundreds of tables. So, I turn it off, I disable the word completion because when I'm coding, the word completion makes the coding slower. It's very difficult, and every time I have to press escape to skip the completion. It's very ineffective, so I disable it because in other applications it functions very well, such as VS Code.
You have to build out the metadata yourself because of the nature of the cloud.
I think it would be better if the product were more mature. It's still a young product compared to Power BI or Qlik. I find that development is a bit difficult, but it might be because I'm used to other tools. The dashboarding capabilities could be better. The reporting and statement generation could be better. I couldn't technically initiate picture-perfect reporting, for example, to send out statements every month for banking customers.
One improvement I can suggest is that Athena needs to work better with third-parties. For example, the process of querying a Microsoft SQL warehouse could be improved. When querying outside of AWS, you can use federated queries, but it's not always easy to do so.
The solution should include a better API for query services so that data can be dumped and queried directly in customer's products. The API should include some sort of data visualization that can be plugged into applications. We had to use QuickSight to help us with the visualization.
If you compare it with Palantir, if you have some data and you want to quickly have a look at it, then that feature is not available in Amazon Cloud. We'd like it better if, for example, when you have some data, you can easily query it and you can easily read it at a glance. We'd like it to just be almost like a drag-and-drop situation. In Amazon Cloud, you actually have first to upload the data into S3. For that, you have to create a bucket. Now you have to create a Glue service, which will get you the schema. Then that schema would create basically a database and a table. After that, you have to go to Athena to query the data. It's a three-step process in Amazon Cloud. In Palantir, you just have to drag and drop.