Amazon Athena Reviews

I have experience using Amazon Athena, and this service I have more experience with, actually.

I use Amazon Athena for my daily activity; I was using it just now for getting data, and we use Amazon Athena in Lake Formation, mainly using Data Mesh resources. Every table storage is in an S3 and Amazon Glue Catalog that stores the schemas, and we use Amazon Athena to read that data, and it runs with clustered performance. It is very fast to retrieve data, and I used to query SQL and get information and do all the data analyst jobs that are necessary. I use Amazon Athena a lot. I also use Amazon Athena from step functions, calling Athena saved queries or specific queries. I use Amazon Athena also with Python and Boto3, calling Amazon Athena as a client. I use Amazon Athena also inside a Glue job Python script when automating jobs and using Boto3 and AWS Wrangler libraries for Python to query data in Amazon Athena and use the service at AWS.

Using Amazon Athena is easy, very easy.

With Amazon Athena, we don't save when we are doing analytics. We don't think a lot about the billing and the costs. Only when we are creating automations do we think about it. When we're doing our daily job, they don't push us to think about it. But I know Amazon Athena is billed by data read. They bill by the data read, and I don't know how many cents of a dollar for each gigabyte, something like that. I think it's not cheap, but the price that appears here in our Cost Explorer is not the price that the company pays because they have discounts. We don't have the last price that was billed.

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.

I have been using Amazon Athena for two years.

I have never faced any issues with the stability of Amazon Athena. In two years, maybe one day or two, but it is very uncommon. It's a very stable application.

Amazon Athena works for scalability; I query data using tagged data that uses user usage of applications that contain very big data, millions and billions of lines, and it works very well. This is mainly because Amazon Athena can clusterize computation. It creates clusters and computes separately; it's very good. There are no problems with scalability.

It is okay by me to have my name, my job, and my company when you post the review. I rate Amazon Athena a 10 out of 10.

We use Amazon Athena to query data stored in Amazon S3, forming a data lake architecture. For metadata management and schema discovery, we rely on AWS Glue Catalog and Glue Crawlers. For governance—especially row-level and column-level security—we employ AWS Lake Formation.

When query performance suffers—especially with many concurrent queries or unexpectedly slow responses—I engage AWS Support to raise tickets and help with performance tuning.

• Athena is serverless, so we don’t have to provision or manage compute clusters. We can simply point Athena at our data in S3 and run SQL queries immediately.


• It supports a broad set of formats: structured, semi-structured, and unstructured (CSV, JSON, Avro, Parquet, ORC, etc.). Because it follows a schema-on-read model, there's no need for heavy upfront transformation.


• The Glue Data Catalog, together with Glue Crawlers, helps to infer schemas and partition structure. This saves time, since for many raw-data sets we don’t have to build schema definitions by hand. Athena uses the catalog to understand data layout, which speeds up query planning and execution.


• Partitioning and format optimizations (e.g. leveraging columnar storage, compression) drastically reduce the amount of data scanned. That yields cost savings and faster execution.


• It gives visibility into data quality issues: when raw data is malformed or inconsistent, crawling + Athena queries help identify schema drift, missing fields, or unexpected patterns.

• 
  Complex queries & large joins: Performance degrades compared to analytics-optimized warehouses like Redshift when doing heavy joins, aggregations over very large datasets, or extensive transformations. In those cases, we still need ETL / Spark / Glue jobs.


• 
  Transaction / ACID support is limited unless using table formats like Apache Iceberg. If you require updates, merges, deletes at scale, Athena alone may not suffice.


• 
  Cost risk: Because Athena charges per terabyte scanned ($5 per TB by default). Poor query design (e.g. selecting many columns, not using partitions, scanning raw text) can drive up costs.


• 
  Concurrency limits: By default, you can run about 20 concurrent queries per account per region. If workload spikes, you may hit throttling or queued queries. Increasing limits requires an AWS request.


• 
  Transformation limitations: Athena is built for querying, not for heavy data transformation or streaming data ingestion. For complex transformations, glue or Spark remain necessary.

Athena has been reliable in our environment. With Lake Formation, access control and security have performed well. We have rarely had long outages, and error conditions are mostly due to misconfigurations or limits (e.g. exceeding concurrency), rather than service instability.

• Because it’s serverless, we automatically scale according to demand: when queries increase in volume or size, Athena manages compute behind the scenes.


• With proper partitioning, efficient formats (Parquet/ORC), and good metadata (Glue Catalog), it scales to petabyte-scale datasets without manual infrastructure scaling.


• Some limits are in place (e.g. concurrency, API quotas, query string length), but these are generally adjustable or manageable with planning.

Previously, our pipeline involved cleaning, transforming, and loading data from S3 into relational or NoSQL databases (e.g. DynamoDB) before analysis. That incurred overhead in time, compute, storage, and in managing ETL pipelines. Switching to Athena allowed us to query raw data in place, shortening turnaround time and reducing resource usage.

• Created one or more S3 buckets: one for raw data, one for query results.


• Organized raw data in partitioned folder structures (e.g. year=YYYY/month=MM/day=DD/) to support efficient querying.


• Defined schema metadata in the Glue Data Catalog, either by manually creating tables or by running Glue Crawlers to infer schema and detect partitions.


• Assigned the appropriate IAM permissions and Lake Formation access policies so that users have necessary rights to run queries, read data, etc.


• Configured the result/output location for Athena queries in S3 (so that query results are stored correctly, and so queries don’t fail due to missing output path).

• We significantly reduced time spent on pre-processing and transformations, because many reports/analyses can now pull data directly from raw files.


• Cost savings came from reducing compute and storage overhead, avoiding maintaining separate databases just for analytics staging.


• Query costs dropped when we applied best practices (partitioning, using columnar formats, compression).

• 
  DuckDB: evaluated for querying files locally or via cloud storage. While it was useful for lightweight or embedded analytics, it did not scale as smoothly for large, concurrent cloud workloads, or integrate with S3 and AWS governance/tools in the way Athena does.


• Possibly evaluated some data-warehouse services (Redshift, Snowflake) for comparison, but found Athena struck the best balance for ad-hoc querying, minimal management, proper cost/performance tradeoff.

• Always use columnar formats (Parquet / ORC) + compression (Snappy or similar) to reduce scanned data volumes.


• Partition your data on logical fields (e.g. date, region) to limit scope of queries.


• Avoid SELECT * unless necessary; query only the columns you need.


• Monitor Athena usage via CloudWatch: watch for data scanned, query runtime, concurrency, etc. Use alerts when you're nearing service quotas.


• For high throughput or many users, consider using capacity reservations or separating workloads (workgroups) so that one heavy workload doesn’t degrade performance of others.


• Use Athena’s built-in EXPLAIN or query plan features to profile and optimize queries.

The typical use case for Amazon Athena is that we have data in a data lake, and if we need to query the data from the data lake, we use Amazon Athena before it gets to the data warehouse where we were using Snowflake, so the proper warehouse. That's the main use case. It's just to verify some data on the data lake, and it also allows us to query data on S3 directly, which is what we use it for.

The best feature of Amazon Athena is that we can use Glue to build the schema from the data and then we can query the data directly on S3. This is the main feature which is most important for us, to be able to create schema from data on S3 and then query the data on S3.

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 have worked with this solution for about two years.

It is a stable solution.

Amazon Athena is a scalable solution.

I would rate technical support from Amazon an eight. We mainly use documentation and the documentation is quite good.

Positive

After having Glue set up correctly, the initial setup of Amazon Athena is quite straightforward to use.

We didn't really calculate an ROI on Amazon Athena because it would be hard to determine.

I have experience of integration of Amazon Athena with AWS Glue.

I think the pricing of Amazon Athena is quite reasonable as we use it in pay-as-you-go mode.

On a scale from one to ten, I rate Amazon Athena a seven.

Amazon Athena is mostly used for querying data. In teams with analysts and project managers, there are many AWS services helping to understand data, such as Redshift and Amazon Athena. The main use case is to understand, visualize, analyze, and query the data on the lake.

A significant use case for Amazon Athena is its ability to query unstructured data. For example, any data kept in S3 can be read directly and queried.

We have used Amazon Athena integration with AWS Glue. We have integrated AWS Glue with Amazon Athena with some Iceberg tables. Iceberg is currently the de-facto standard that Amazon Athena supports. We have Glue Catalog on top of that, and we query those Iceberg tables with Amazon Athena.

Amazon Athena's ability to query structured and unstructured data has been beneficial. For a startup, procuring a database such as Redshift is challenging to maintain. You have to run jobs and hire engineers to maintain the database. To remove these hassles, a startup can easily put the data on cloud and query it with Amazon Athena. It reduces operational overhead significantly. If your data scale is not extensive, you can query very cost-effectively because Amazon Athena's pricing is approximately $5 per TB of scan.

Amazon Athena is very compatible with data lake concepts. You can put all your data in S3, and there are different data formats. In the last few years, many open data formats have emerged. Amazon Athena supports formats such as Parquet, CSV, and Iceberg natively. It also supports Hoodie, created by Uber, and Avro. It has extensive support for different types of data structures.

Amazon Athena is cost-effective and performs efficiently. Being serverless means you don't need any compute resources. You don't have to manage how long the data will take, making it quite scalable.

Amazon Athena is based on Trino, an open database. When a company wants to run ETL on Amazon Athena, they cannot do it easily. For instance, if you want to delete something on a primary key or perform CRUD operations with Step Functions to automate processes, these operations are not straightforward in Amazon Athena.

Transaction support is one of the biggest missing features. If you are running multiple statements, such as a delete followed by an insert, and something goes wrong during insertion, the deletion should be reverted, but that doesn't happen. We have to implement workarounds, whereas these capabilities are available in Redshift.

While Amazon Athena has notebook support where analysts can write their work, scheduling these notebooks is not user-friendly. If an analyst wants to schedule a notebook to trigger at a specific time, they need a developer's assistance.

There should be unanimous access management in Amazon Athena, which is not readily available. Though they have Lake Formation and other features, there isn't one place to manage access. For example, restricting access to specific columns for particular users requires alternative approaches.

The service is only available on-demand from AWS, not through the Marketplace.

I have been working with Amazon Athena for approximately five years, including usage in my previous organization.

I contacted Amazon support regarding Amazon Athena long ago. After using it for so long, I have discovered that I know more than some support staff. I had an issue with transactions about a year ago, and I found that their support staff sometimes lacks extensive experience. While they have knowledge, I have had the opportunity to work with the infrastructure hands-on. The support people AWS provides often don't have much context, though senior staff members might have more expertise.

Neutral

I have evaluated various solutions including Databricks, Snowflake, and Google BigQuery. For any startup operating in one cloud, it is better to remain in that ecosystem rather than managing multiple clouds as it complicates the infrastructure. Since we were in AWS, we chose to use their available services instead of moving outside, following the industry trend of consolidation.

We tried Amazon QuickSight with Amazon Athena for visualization, but we are using Superset on top of that.

The ecosystem is straightforward and excellent to get started with. If organizations don't want to spend time managing databases and prefer focusing on their business terms to move quickly, Amazon Athena is a good solution.

Amazon Athena can become costly if analysts lack knowledge of partition keys and querying tables efficiently. Since the pricing is $5 per TB, large queries on big datasets can result in substantial bills. There aren't many resources available to help optimize queries in Amazon Athena, with only a few blogs available. They should provide more information about query optimization.

I rate Amazon Athena an eight out of ten.

I used the solution to load relational databases.

We used Athena to get off Hadoop, and Athena is very much like Hadoop in its capabilities. Athena has a really good UI and is very compatible with on-prem products.

You have to build out the metadata yourself because of the nature of the cloud.

I’ve used Amazon Athena for two and a half years, but I stopped using it seven months ago. I used the version on the cloud.

The solution is scalable.

The solution was straightforward to deploy, but I’ve been doing this for a long time. I don't know if someone new to the solution would struggle or not.

Athena is very inexpensive for being a cloud tool.

Athena only has a relational database, so using it depends on your use case. I rate Amazon Athena a seven out of ten.

In the case of both Athena and Glue, if you have some data and want to query upon that, then you can basically use Glue to get the schema and Athena to query the data. You need both of them to work.

It's a great AWS application. Amazon Athena is just one of the features in a bigger cloud infrastructure, in the AWS platform. We have Athena and Glue as some of the features we really like working with. We also use EMR, EC2, and S3. There's a lot out there to take advantage of. 

The storage is simple. 

It's easy to set up the product.

The solution is stable.

We can scale it easily.

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.

I've been using the solution for four months. 

It's a stable solution. It's reliable. There are no bugs or glitches. It doesn't crash or freeze.

As a cloud solution, it's quite simple to scale. 

Almost our entire team uses the product. That's about 30 to 40 people right now. They are mainly data engineers and data analysts.

I've never needed to contact technical support.

I've also used Palantir.

The initial setup process is easy. I'd rate it an eight out of ten in terms of ease of implementation. It does take some time to deploy.

We were able to set up the solution ourselves.

The costs related to the solution depend on the data and how much of it there is. They may lay out costs on their website. 

We're an Amazon partner.

Before getting started, I'd advise new users that you must upload some data into an S3 bucket. You have to learn the basics of Amazon Cloud first. Then you have to know about some services like Amazon S3, Amazon Glue, and Athena. You also have to have some idea about the IAM role. It's important to get a handle on the solution beforehand.

I'd rate the solution seven out of ten.

We use Amazon Athena as a dashboarding and reporting tool.

Amazon Athena is very stable. I never had any issues with it. The dashboarding tool is okay. 

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.

I have been using Amazon Athena for about six to eight months.

Amazon Athena is very stable.

On a scale from one to ten, I would give its stability a ten.

Amazon Athena is a scalable product.

On a scale from one to ten, I would give scalability an eight.

The initial setup was straightforward but with some challenges. Like all other Amazon products, the permission setup is a granular and trial-and-error process. For example, you might think you have set up Athena and tried and connect to something, and it might say you don't have this permission to complete the process. It's not an intuitive process to set up the permissions.

On a scale from one to ten, I would give the initial setup a 6.

It doesn't cost much if you are already part of the AWS ecosystem.

On a scale from one to ten, I would give their pricing a seven.

On a scale from one to ten, I would give Amazon Athena a five.

I have been using Amazon Athena to query across the AWS platform, from my Redshift warehouse and S3 storage.

I have found that Amazon Athena is very fast, especially when it comes to making queries. It also helps that you can connect it to other services, such as with the ability to create a federated query to query other databases.

One of the most valuable features is the ability to partition your databases. I also like the federated query functionality, for cases when you have to query outside your S3 storage, or even completely outside of the AWS platform.

There is also a useful feature called a metastore, which lets you access all the data you have shared across all your AWS accounts.

Another perk is that Athena allows you to optimize your queries.

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.

I have been using Amazon Athena for about two years.

I have not encountered any stability issues.

In terms of scalability, Athena doesn't store your results, but the objects that you are querying get stored in S3, so for me, this makes things easier and I would recommend it over any other platform.

I have not had contact with AWS technical support yet.

I have only been using AWS for the current project that I'm working on. I am willing to integrate other tools as I go along, but it all depends on whether there is a suitable tool that already exists in AWS.

The setup is easy and I would rate it a nine out of ten. It only took me a couple of minutes because I was following through with a manual.

I deployed it by myself and didn't need to hire anyone to help, mainly because what I'm working on right now is a startup solution.

Currently, I can see that my projects using Athena are working well, but because they are personal projects I am not receiving any money from them nor have I approached any clients about them yet. They are just for me at the moment, as I simply saw a solution that I needed to solve.

I am happy with what they are charging and how they charge it, especially because they charge you per query, and not per series.

I would rate their pricing a nine out of ten.

I think AWS Athena is a good service if you are using S3 as your file storage. And if you're not using S3, then maybe you should think about pairing Athena with S3 instead of what you are currently using.

I would rate AWS Athena a nine out of ten.

Our company uses the solution for a client-specific requirement to conduct data integration and analysis. 

The solution is very easy to use and integrations are very smooth. 

The serverless model only charges you for data that is consumed. 

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. 

I have been using the solution for ten months. 

The solution is scalable based on data consumption. 

Our technical team handled setup so I don't have specific details. 

We implemented the solution in-house. 

The solution operates on a serverless model so you only pay for data that you consume. 

Our client required that we use the solution for their project. 

I rate the solution an eight out of ten.