Google's BigQuery is part of the Google Cloud Platform, a database-as-a-service (DBaaS) supporting the querying and rapid analysis of enterprise data.
$6.25
per TiB (after the 1st 1 TiB per month, which is free)
Amazon Redshift
Score 8.9 out of 10
N/A
Amazon Redshift is a hosted data warehouse solution, from Amazon Web Services.
$0.24
per GB per month
TIBCO Data Virtualization
Score 8.6 out of 10
N/A
TIBCO Data Virtualization is an enterprise data virtualization solution that orchestrates access to multiple and varied data sources and delivers the datasets and IT-curated data services foundation for nearly any solution.
N/A
Pricing
Google BigQuery
Amazon Redshift
TIBCO Data Virtualization
Editions & Modules
Standard edition
$0.04 / slot hour
Enterprise edition
$0.06 / slot hour
Enterprise Plus edition
$0.10 / slot hour
Redshift Managed Storage
$0.24
per GB per month
Current Generation
$0.25 - $13.04
per hour
Previous Generation
$0.25 - $4.08
per hour
Redshift Spectrum
$5.00
per terabyte of data scanned
No answers on this topic
Offerings
Pricing Offerings
Google BigQuery
Amazon Redshift
TIBCO Data Virtualization
Free Trial
Yes
No
No
Free/Freemium Version
Yes
No
No
Premium Consulting/Integration Services
No
No
Yes
Entry-level Setup Fee
No setup fee
No setup fee
No setup fee
Additional Details
—
—
—
More Pricing Information
Community Pulse
Google BigQuery
Amazon Redshift
TIBCO Data Virtualization
Considered Multiple Products
Google BigQuery
Verified User
Analyst
Chose Google BigQuery
Google BigQuery needs minimal setup to get it up and running while Amazon Redshift and Oracle Analytics Cloud need moderate expertise and time to load a data set and run a query. Hadoop (open source) and its commercial version Cloudera do not provide a full out of the box …
I personally find it by far simpler than Amazon Redshift due it's onboarding seamlessness. For a quick start and simplify tye access to read the data big query provide better user experience and a smoother user interface. More importantly, the fact that Big Query can be easily …
Amazon Redshift was a likely alternative we were considering , but it needs to be provisioned on cluster and nodes, which increases infrastructure management, whereas Google BigQuery is serverless, so no infra management :) Also, I remember when comparing them we did found out …
Google BigQuery's main advantage over its direct competitors (Amazon Redshift and Azure Synapse) is that it is widely supported by non-Google software, while the others rely heavily on their own cloud ecosystems.
Compared to every other analytics DB solution I've used, Google BigQuery was by far the easiest to set up and maintain, and scale. The price was also much lower for our use case (internal data analysis).
We actually use Snowflake and BigQuery in tandem because they both currently meet various needs. Redshift, however, has barely been used since our migration away from it. In the case of both Snowflake and BigQuery, they beat Redshift by a long shot. The main reasons are their …
Google BigQuery is cheaper and much faster as compared to both. While as compared to Snowflake , we tested it was faster and cheaper by 30%, that is after Snowflake tweaked their environment, if not for that it would have been 90% cheaper than Snowflake. Redshift is not easy …
Google BigQuery i would say is better to use than AWS Redshift but not SQL products but this could be due to being more experience in Microsoft and AWS products. It would be really nice if it could use standard SQL server coding rather than having to learn another dialect of …
There are some areas in which this product is better while there are some in which others do better. It's not like Google BigQuery surpasses them in every metric. For a holistic view, I will say we use this because of - scalability, performance, ease of use, and seamless …
BigQuery can automatically scale to accommodate the data and query load, providing potentially unlimited scalability. At the same time, Redshift requires manual scaling efforts to increase or decrease capacity, which might affect performance during scaling operations.
Google BigQuery is the best among the ones we evaluated. It works really well with the Google Cloud workloads and comes with exceptional security controls. It can be combined easily with lots of products that Google Cloud has. It is a real game-changer.
Cost is the important factor for us compared with all of the other tools Google BigQuery stands top among all of them which charges very minimal charges for storage against all the apps that we have liked the most additionally, we can do query on our data, and can build …
I was already familiar with the Google Cloud Platform environment, and I was better equipped with the standard SQL language. Some of the syntax does not translate well to Redshift. It also seemed like many data source integrations relevant to our business were easier and more …
Both BigQuery and Redshift are two comparable fully managed petabyte-scale cloud data warehouses. They’re similar in many ways, but you should consider their unique features and how they can contribute to an organization’s data analytics infrastructure. When considering which …
Google BigQuery integrates seamlessly with Web Analytics data compared to the Azure cloud. Google BigQuery integrates natively with different digital media platforms compared to Azure and AWs.
We liked BQ because the cost of it is only dependent on the amount of data you store (and there are tiers of data access) and how much you search. For us, it is significantly less expensive to run BQ than an equivalent hosted RDBMS. Because most of our data pipelines are …
BigQuery by far the best solution in all angles compared to other ones: Especially scalability, ease of use, performance and there is no need to manage any cluster of servers. Also it's ABSOLUTELY pay as you go! No one in market currently provide such service that can compete …
Amazon Redshift, BigQuery, and Snowflake are all fully managed data warehouse services that are designed to handle large volumes of structured data and support business intelligence and analytics efforts. However, Amazon Redshift has the upper hand with its cost-effective …
Biggest advantage of Amazon Redshift is it's part of the aws ecosystem. When tuned well it is also very cheap compared to something like Snowflake. And compared to spark or databricks, Amazon Redshift is a solid warehouse that's well suited for tabular data. We use it for user …
We evaluated [Amazon] Redshift vs BigQuery vs Amazon EMR, back in 2014. Back then BigQuery cost was slightly higher than that of [Amazon] Redshift price structure. Amazon EMR, needs lots more management (Admin tasks) and EMR is designed to be ephemeral and not designed to be a …
Amazon Redshift supports multiple data formats including multiple structured data formats. And it is easy to implement a cluster if you do not have knowledge of data lake solution. Also when you do not need a lot of resources, you can just scale down so you do not have to spend …
As our applications are hosted on AWS service, Redshift is the best option for us. Also, it provide a near to real-time performance on limited datasets and less complex queries. High availability is the major concern for any growing business and AWS is the best option for this. …
Most of our stack is on AWS, so while Snowflake and BigQuery was a viable option from a performance perspective, it was easier to integrate with RedShift. We considered hosting SQL Server on AWS or using Amazon RDS (Postgres or MySQL), however, the self-service aspect of …
We have evaluated a number of data warehousing systems but chose [TIBCO Data Virtualization] due to the ease of integration with spotfire, as well as the initial cost. Over time we have also introduced an Oracle Data Warehouse to manage additional data and use other analytical …
Event-based data can be captured seamlessly from our data layers (and exported to Google BigQuery). When events like page-views, clicks, add-to-cart are tracked, Google BigQuery can help efficiently with running queries to observe patterns in user behaviour. That intermediate step of trying to "untangle" event data is resolved by Google BigQuery. A scenario where it could possibly be less appropriate is when analysing "granular" details (like small changes to a database happening very frequently).
If the number of connections is expected to be low, but the amounts of data are large or projected to grow it is a good solutions especially if there is previous exposure to PostgreSQL. Speaking of Postgres, Redshift is based on several versions old releases of PostgreSQL so the developers would not be able to take advantage of some of the newer SQL language features. The queries need some fine-tuning still, indexing is not provided, but playing with sorting keys becomes necessary. Lastly, there is no notion of the Primary Key in Redshift so the business must be prepared to explain why duplication occurred (must be vigilant for)
TIBCO Data Virtualization is well suited for customers who are challenged to deal with extracting data from dozens of different sources and systems, and do not have the time and liberty to hire data engineers and/or ETL developers to write dozens or hundreds of complex ETLs. However, there are situations where TIBCO Data Virtualization severely underperforms, and those are where we are dealing with large volumes of data, in tera bytes or peta byte scale system. For example, a messaging queue which sends 200 million messages every hour will choke TIBCO Data Virtualization if the technology is chosen to route the data.
GSheet data can be linked to a BigQuery table and the data in that sheet is ingested in realtime into BigQuery. It's a live 'sync' which means it supports insertions, deletions, and alterations. The only limitation here is the schema'; this remains static once the table is created.
Seamless integration with other GCP products.
A simple pipeline might look like this:-
GForms -> GSheets -> BigQuery -> Looker
It all links up really well and with ease.
One instance holds many projects.
Separating data into datamarts or datameshes is really easy in BigQuery, since one BigQuery instance can hold multiple projects; which are isolated collections of datasets.
[Amazon] Redshift has Distribution Keys. If you correctly define them on your tables, it improves Query performance. For instance, we can define Mapping/Meta-data tables with Distribution-All Key, so that it gets replicated across all the nodes, for fast joins and fast query results.
[Amazon] Redshift has Sort Keys. If you correctly define them on your tables along with above Distribution Keys, it further improves your Query performance. It also has Composite Sort Keys and Interleaved Sort Keys, to support various use cases
[Amazon] Redshift is forked out of PostgreSQL DB, and then AWS added "MPP" (Massively Parallel Processing) and "Column Oriented" concepts to it, to make it a powerful data store.
[Amazon] Redshift has "Analyze" operation that could be performed on tables, which will update the stats of the table in leader node. This is sort of a ledger about which data is stored in which node and which partition with in a node. Up to date stats improves Query performance.
Please expand the availability of documentation, tutorials, and community forums to provide developers with comprehensive support and guidance on using Google BigQuery effectively for their projects.
If possible, simplify the pricing model and provide clearer cost breakdowns to help users understand and plan for expenses when using Google BigQuery. Also, some cost reduction is welcome.
It still misses the process of importing data into Google BigQuery. Probably, by improving compatibility with different data formats and sources and reducing the complexity of data ingestion workflows, it can be made to work.
We've experienced some problems with hanging queries on Redshift Spectrum/external tables. We've had to roll back to and old version of Redshift while we wait for AWS to provide a patch.
Redshift's dialect is most similar to that of PostgreSQL 8. It lacks many modern features and data types.
Constraints are not enforced. We must rely on other means to verify the integrity of transformed tables.
Performance of TDV repository database is rather poor for larger numbers of objects .(Note: We have approx. 9tsd objects introspected in TDV and approx. 20tsd objects generated in upper DV layers.)
Propagation of privileges to parent/child dependencies does not work when applying recursively on a folder. (It's a huge setback when working with large number of objects organized semantically into subfolders.)
Lack of command line client interface for scripting at the time of version 8.4 (I had to write my own CLI.)
TDV Studio does an absolutely horrible job with its own code editors when indentation is in place. Also, the editor is brutally slow and feature-poor.
Tracking privileges on the level of table/view columns causes occasional problems when regranting.
TDV's stored programs ("SQL scripts" in their own terminology) compiler leaves out many syntactic and semantic checks, making them hugely prone to run-time errors.
TDV Server's REST API is a very poor (in terms of features) and flawed cousin to its SOAP API (at the time of version 8.4).
We have to use this product as its a 3rd party supplier choice to utilise this product for their data side backend so will not be likely we will move away from this product in the future unless the 3rd party supplier decides to change data vendors.
I think overall it is easy to use. I haven't done anything from the development side but an more of an end user of reporting tables built in Google BigQuery. I connect data visualization tools like Tableau or Power BI to the BigQuery reporting tables to analyze trends and create complex dashboards.
Just very happy with the product, it fits our needs perfectly. Amazon pioneered the cloud and we have had a positive experience using RedShift. Really cool to be able to see your data housed and to be able to query and perform administrative tasks with ease.
TDV's interface is a bit dated and not entirely intuitive. Would recommend some UX design review as the interface leaves a bit to be better understood to be used by users without inherent knowledge of Tibco. Overall I'd suggest more improvement here to ensure usability by a lesser tech audience.
I have never had any significant issues with Google Big Query. It always seems to be up and running properly when I need it. I cannot recall any times where I received any kind of application errors or unplanned outages. If there were any they were resolved quickly by my IT team so I didn't notice them.
I think Google Big Query's performance is in the acceptable range. Sometimes larger datasets are somewhat sluggish to load but for most of our applications it performs at a reasonable speed. We do have some reports that include a lot of complex calculations and others that run on granular store level data that so sometimes take a bit longer to load which can be frustrating.
This product's performance is very consistent. It is extremely rare for templates to fail. I've been using this software for 5 years and find it to be both simple and powerful. The impact within the company has been very positive as different processes in different areas, such as data analysis, development, and integrations, have been improved, and, best of all, it has not affected the users. Various systems with which it is connected in order to obtain information.
BigQuery can be difficult to support because it is so solid as a product. Many of the issues you will see are related to your own data sets, however you may see issues importing data and managing jobs. If this occurs, it can be a challenge to get to speak to the correct person who can help you.
The support was great and helped us in a timely fashion. We did use a lot of online forums as well, but the official documentation was an ongoing one, and it did take more time for us to look through it. We would have probably chosen a competitor product had it not been for the great support
On a few occasions I have asked TIBCO technical support for help because I have adapted perfectly to their tools, but in those few that I have communicated with their technical team I have received personalized, attentive, responsible attention and I am always assisted by an expert staff the topic. A TIBCO technical support technician spent more than an hour helping me to solve a problem in the initial stage of implementation in my department and this is something that I always appreciate.
The training was helpful. I was able to understand how to use TIBCO for the data load process that we implemented and how to perform various troubleshooting steps based on the training I received. The technician was thorough and took the time to answer any questions. Once we were shown how to use TIBCO in the test environment, we were able to configure the production environment ourselves.
Other vendors have clearer, more visual implementation documentation. We also did not have our data architect and and server administrator available full-time for implementation. In the future, we will secure the necessary internal resources.
PowerBI can connect to GA4 for example but the data processing is more complicated and it takes longer to create dashboards. Azure is great once the data import has been configured but it's not an easy task for small businesses as it is with BigQuery.
Than Vertica: Redshift is cheaper and AWS integrated (which was a plus because the whole company was on AWS). Than BigQuery: Redshift has a standard SQL interface, though recently I heard good things about BigQuery and would try it out again. Than Hive: Hive is great if you are in the PB+ range, but latencies tend to be much slower than Redshift and it is not suited for ad-hoc applications.
We did not need to evaluate another technology in the same category for data virtualization, since we are 100% sure of the capabilities and benefits that we would have with TIBCO Data Virtualization, both for market positioning as well as success stories from other companies. great renown worldwide. From the first day of use, it meets our needs to provide the expected solutions.
Redshift is relatively cheaper tool but since the pricing is dynamic, there is always a risk of exceeding the cost. Since most of our team is using it as self serve and there is no continuous tracking by a dedicated team, it really needs time & effort on analyst's side to know how much it is going to cost.
We have continued to expand out use of Google Big Query over the years. I'd say its flexibility and scalability is actually quite good. It also integrates well with other tools like Tableau and Power BI. It has served the needs of multiple data sources across multiple departments within my company.
Google Support has kindly provide individual support and consultants to assist with the integration work. In the circumstance where the consultants are not present to support with the work, Google Support Helpline will always be available to answer to the queries without having to wait for more than 3 days.
Previously, running complex queries on our on-premise data warehouse could take hours. Google BigQuery processes the same queries in minutes. We estimate it saves our team at least 25% of their time.
We can target our marketing campaigns very easily and understand our customer behaviour. It lets us personalize marketing campaigns and product recommendations and experience at least a 20% improvement in overall campaign performance.
Now, we only pay for the resources we use. Saved $1 million annually on data infrastructure and data storage costs compared to our previous solution.
Our company is moving to the AWS infrastructure, and in this context moving the warehouse environments to Redshift sounds logical regardless of the cost.
Development organizations have to operate in the Dev/Ops mode where they build and support their apps at the same time.
Hard to estimate the overall ROI of moving to Redshift from my position. However, running Redshift seems to be inexpensive compared to all the licensing and hardware costs we had on our RDBMS platform before Redshift.
