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.

Amazon Web Services (AWS)

My main use case for Amazon Athena is querying data that sits in S3 buckets.

Currently, I am working for an aviation client for which we receive data on a daily basis. We take this data from a source and perform transformations. After the transformation is complete, we have dimension and fact tables. That data is stored into S3 tables in the S3 buckets. Once the data sits in the S3 bucket, we have integrated S3 buckets with Amazon Athena. The data sits in Parquet format with Zstandard compression at level three. We have Lake Formation permissions with Amazon Athena to query the data. We have a catalog for S3 bucket data, and we create our workgroups in Amazon Athena. That is how we use data from S3 buckets for querying via Amazon Athena.

The best features Amazon Athena offers are its straightforward framework to perform ad hoc analysis on the data that we have. We use it primarily as our main query engine, so we are not using anything such as Snowflake or similar solutions. We essentially ingest the data into S3 buckets, and then we use Amazon Athena for querying the data. It is our main query platform on AWS. All of our queries, for transformations, are Athena-based queries that are orchestrated via Step Functions. We only pay for the amount of data that we scan. Since we operate on a relatively lower amount of data on a daily basis, we incur a very low cost on our querying.

The pay-per-query pricing of Amazon Athena impacts my daily operations significantly. For other query engines, we pay for the query execution time, but in Amazon Athena, you only pay for the amount of data that you have scanned. Our queries primarily filter out the data. Since we operate on a daily basis, we are only concerned with today's data. When querying the data, we automatically put the filter to have the data in today's timestamp only. This way, we incur very low costs compared to other query engines. Our query scans are about 10 to 20 MBs, and despite performing 100 to 150 queries per day, this keeps our costs very manageable.

Amazon Athena has positively impacted my organization by providing a completely serverless infrastructure. We have Step Functions, Lambda, and S3 buckets where we store our data. Our main infrastructure is serverless. We wanted a query engine that is less demanding in terms of setup efforts and cost-efficient, so we decided to go with Amazon Athena. It fulfills all our use cases, plus the ACID compliance that it brings, because we use Iceberg on top of Amazon Athena. This ensures our queries and data are consistent, durable, and that the queries are isolated in terms of execution.

Athena's ACID compliance, especially with Iceberg, impacts our data consistency and reliability. We apply Iceberg with Parquet, which helps us compress the data to a very good volume. With the applied compression algorithms, we preserve our data consistency during parallel transformations. ACID compliance helps us achieve this, ensuring we do not compromise on our data and that our GDPR for the data is preserved.

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 have been using Amazon Athena for the last six months.

Amazon Athena's scalability is quite good.

I have not required customer support because it is a good service, and I did not face any issues.

We started with Amazon Athena only and did not use a different solution beforehand.

My experience with pricing, setup costs, and licensing has been positive. The setup was much easier, and we did not face any issues with licensing or other matters. We did not encounter any specific challenges with licensing; our experience was smooth.

I have not seen a defined return on investment. However, we save time since we do not require any extra platform to deploy outside AWS, and it sets up relatively quickly.

Before choosing Amazon Athena, we evaluated Snowflake. Some users hosted on Snowflake required data access, but we could not provide the complete dataset to them, necessitating an abstraction layer. Thus, we chose Amazon Athena separately instead of relying completely on Snowflake.

Regarding Amazon Athena's AI capabilities, we do not utilize them. However, data governance is ensured, and security is adequate since we operate within the VPC. ACID compliance helps preserve GDPR.

Even though we do not use AI capabilities directly, the accuracy and reliability of Amazon Athena's output are notable. I find it to be quite accurate and reliable for us. We have been using it for the last six months, and with the production environment and the type of clients we have, as well as the accuracy needed since we work with financial data, it has provided instant results without many complications. It has been effective.

I would advise others looking into using Amazon Athena to use it only for ad hoc purposes. While we utilize it, we plan to integrate with Snowflake or other query engines later, as Amazon Athena has very limited functionalities compared to some other query engines. It is suitable for exploring and interacting with data, but not for serious applications.

I found this interview valuable and do not think any changes are needed for the future. I would rate this review an 8 out of 10.

My main use case for Amazon Athena is serving a healthcare organization in the US that needed an interactive SQL editor to write complex queries and retrieve details instead of checking manually in the S3 bucket. I proposed and implemented the solution end-to-end from scratch using Amazon Athena and other AWS services such as AWS Glue services, including crawlers and modifiers, and CloudWatch for logging purposes. I implemented and provided a production-ready solution to the client, and they are very satisfied with it.

Ideally, there are no external or third-party applications installed, so the end user only needs access to AWS accounts with the Amazon Athena query editor. Through the query editor, they can write their query and receive results, and they can store the results if desired.

Regarding my main use case from the end user perspective, if they encounter issues with the data, it is not practical to check manually through each data file in the S3 bucket. Instead, I implemented Amazon Athena on top of the data using the AWS Glue service stack, and based on that implementation, whatever tables and databases are created allow users to write complex queries and retrieve the details they need. If they obtain the results they are looking for, their work speed increases significantly, and they are satisfied with writing SQL queries. I have also provided prerequisite queries based on known problem statements.

In my experience with Amazon Athena, the best feature is the cost model, which I appreciate greatly because it operates on a pay-per-use basis. Whatever queries I run on Amazon Athena, I am only charged for that usage on a monthly basis, which is very beneficial. Additionally, anyone with access to Amazon Athena on the AWS console can write queries and get results easily without requiring any prerequisite knowledge, so even new software engineering professionals can adapt quickly.

After implementing Amazon Athena in our project, we have observed significant savings in cost structure and effort. The end user is very happy and is conducting analytical work using Amazon Athena.

Regarding the features I mentioned, the one with the biggest impact for my team is the speed of results. When a user has more than eight terabytes of data in the S3 bucket, it is not practical to check each file manually. Instead, they write the specific database and complex SQL query to get results within three to four minutes maximum. This saves considerable time for end users.

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.

I have been using Amazon Athena for more than four years across different clients.

Amazon Athena is stable and has been in production for more than a year now, functioning well with periodic cleanup activities to remove unnecessary data.

Amazon Athena has great scalability. When the analytical team wants to onboard new data stacks, I implement Amazon Athena on top of that infrastructure. There are high chances for scalability, and the existing Amazon Athena data, which is live or dynamic, continues to grow gradually.

Customer support for Amazon Athena from the support engineers is very good. Whenever we require general guidance from Amazon Athena, they join calls quickly, and we achieve solutions efficiently. It has been a positive experience with Amazon Athena engineers.

We did not implement any other solution before Amazon Athena. We directly started using Amazon Athena because we gained knowledge about it from the Amazon team.

In terms of specific outcomes, let's consider a monthly scenario. Each end user has around two hundred plus hours per month, and by using Amazon Athena, they can save up to forty percent of their time needed for work. In terms of costs associated with analytical work, they save about sixty percent in billing costs, excluding AWS expenses.

I have not done a formal return on investment assessment; however, I have learned from the analytical team manager that they have saved sixty percent of effort compared to the manual methods previously used to find errors on the S3 bucket. Now, by directly writing queries, they save about sixty percent of effort and more than forty percent in cost after implementing Amazon Athena.

My experience with Amazon Athena regarding pricing, setup costs, and licensing is quite clear after more than three years of usage. I am part of my client's FinOps cloud team, assisting in reducing costs associated with Amazon Athena. The costing model from Amazon Athena is quite transparent, so by deleting unnecessary S3 bucket details and results that are no longer required, overall it is a good approach.

We did not consider other options before choosing Amazon Athena because the client already had it installed, and we could not go beyond the client's limitations.

My advice for others considering Amazon Athena is that if they are working in IT and have data stored on Amazon S3 and want quick analytical work done, they should think about implementing Amazon Athena in their projects.

I recommend Amazon Athena without hesitation if you want to conduct analytical work using existing S3 bucket data. I have provided a review rating of seven out of ten for Amazon Athena.

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

Amazon Web Services (AWS)

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.

Public Cloud

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.

Public Cloud

Amazon Web Services (AWS)