BigQuery vs IBM Db2 Warehouse on Cloud comparison

"The most valuable features of BigQuery is that it supports standard SQL and provides good performance."

"The setup is simple."

"When integrating their system into the cloud-based solutions, we were able to increase their efficiency and overall productivity twice compared with their on-premises option."

"I like that we can synch and run a large query. I also like that we can work with a large amount of data. You don't need to work separately, as it's a ready-made solution. It also comes with a built-in machine-learning feature. Once we start inputting the data, it will suggest some things related to the data, and we can come up with nice dashboards and statistics from a vast amount of data."

"We like the machine learning features and the high-performance database engine."

"We basically used it to store server data and generate reports for enterprise architects. It was a valuable tool for our enterprise design architect."

"BigQuery allows for very fast access, and it is efficient in handling large datasets compared to other SQL databases."

"The main thing I like about BigQuery is storage. We did an on-premise BigQuery migration with trillions of records. Usually, we have to deal with insufficient storage on-premises, but in BigQuery, we don't get that because it's like cloud storage, and we can have any number of records. That is one advantage. The next major advantage is the column length. We have some limits on column length on-premises, like 10,000, and we have to design it based on that. However, with BigQuery, we don't need to design the column length at all. It will expand or shrink based on the records it's getting. I can give you a real-life example based on our migration from on-premises to GCP. There was a dimension table with a general number of records, and when we queried that on-premises, like in Apache Spark or Teradata, it took around half an hour to get those records. In BigQuery, it was instant. As it's very fast, you can get it in two or three minutes. That was very helpful for our engineers. Usually, we have to run a query on-premises and go for a break while waiting for that query to give us the results. It's not the case with BigQuery because it instantly provides results when we run it. So, that makes the work fast, it helps a lot, and it helps save a lot of time. It also has a reasonable performance rate and smart tuning. Suppose we need to perform some joins, BigQuery has a smart tuning option, and it'll tune itself and tell us the best way a query can be done in the backend. To be frank, the performance, reliability, and everything else have improved, even the downtime. Usually, on-premise servers have some downtime, but as BigQuery is multiregional, we have storage in three different locations. So, downtime is also not getting impacted. For example, if the Atlantic ocean location has some downtime, or the server is down, we can use data that is stored in Africa or somewhere else. We have three or four storage locations, and that's the main advantage."

"The performance is okay as long as the volume of queries is not too high."

"It will be MPP, so performance should improve."

"It is stable when there is support from IBM."

"The way that it scales will help a lot of customers that are stuck with Netezza boxes that can't grow any larger.​"

"The product’s performance could be much faster."

"I noticed recently it's more expensive now."

"The process of migrating from Datastore to BigQuery should be improved."

"It would be better if BigQuery didn't have huge restrictions. For example, when we migrate from on-premises to on-premise, the data which handles all ebook characters can be handled on-premise. But in BigQuery, we have huge restrictions. If we have some symbols, like a hash or other special characters, it won't accept them. Not in all cases, but it won't accept a few special characters, and when we migrate, we get errors. We need to use Regexp or something similar to replace that with another character. This isn't expected from a high-range technology like BigQuery. It has to adapt all products. For instance, if we have a TV Showroom, the TV symbol will be there in the shop name. Teradata and Apache Spark accept this, but BigQuery won't. This is the primary concern that we had. In the next release, it would be better if the query on the external table also had cache. Right now, we are using a GCS bucket, and in the native table, we have cache. For example, if we query the same table, it won't cost because it will try to fetch the records from the cached result. But when we run queries on the external table a number of times, it won't be cached. That's a major drawback of BigQuery. Only the native table has the cache option, and the external table doesn't. If there is an option to have an external table for cache purposes, it'll be a significant advantage for our organization."

"For greater flexibility and ease of use, it would be beneficial if BigQuery offered more third-party add-ons and connectors, particularly for databases that don't have built-in integration options."

"There is a good amount of documentation out there, but they're consistently making changes to the platform, and, like, their literature hasn't been updated on some plans."

"It can be slower and more problematic compared to other platforms such as Snowflake."

"An area for improvement in BigQuery is its UI because it's not working very well. Pricing for the solution is also very high."

"Right now, we are implementing on ESX VMware 6.0. Support for this platform is poor. Also, one of the backup/recovery options is broken and IBM is not addressing the issue."

"There are some limitations in adding data files to table spaces, and improvements are needed for regional support."

"Tech support for dashDB is awful. We usually have tickets open for three to four weeks."

"Ultimately, the product itself has challenges and we are not currently satisfied with the support, either."

"Containers get corrupted very easily. Restoring them using GPFS can result in a lot of issues."

"The price is a bit high but the technology is worth it."

"The pricing is good and there are no additional costs involved."

"We are above the free threshold, so we are paying around 40 euros per month for BigQuery."

"The product’s pricing could be more flexible for end users."

"The pricing appears to be competitive for the intended usage scenarios we have in mind."

"BigQuery is inexpensive."

"1 TB is free of cost monthly. If you use more than 1 TB a month, then you need to pay 5 dollars extra for each TB."

"BigQuery pricing can increase quickly. It's a high-priced solution."

"If your going to go with warehouse DB/dashDB, use the cloud or Sailfish version."