Starburst Galaxy Reviews

My team uses Starburst Galaxy for cross-database querying, iceberg table management, and workload separation across multiple data sources. We implemented Starburst Galaxy to replace our self-hosted Trino setup, bridging gaps in our data warehousing situation where we need flexibility to read from various warehouses and write to different formats while maintaining clean compute separation.

Starburst Galaxy has significantly improved our data architecture flexibility and performance management. We have successfully solved cross-database query challenges by utilizing Starburst Galaxy's ability to read and write in iceberg format on Trino, making our iceberg tables usable externally across our entire data ecosystem.

The compute separation capabilities have been transformative. We can easily split workloads and prevent sporadic usage spikes from slowing down critical processes. This has resulted in much more predictable performance and better resource utilization across our data operations.

The clean entry point provided by the built-in query engine has streamlined our SQL development workflow, while the data products functionality gives us an excellent way to present our end-state warehouse-level tables to stakeholders.

The flexibility to connect to numerous different warehouses and write to various formats is Starburst Galaxy's standout feature. This adaptability allows it to mold itself perfectly to our specific needs rather than forcing us to conform to rigid constraints.

The compute-focused architecture makes workload management incredibly straightforward. Since Trino focuses primarily on compute, it is really easy to work with and optimize. The user interface for navigating, managing permissions, and viewing queries and clusters is excellent and makes administration tasks much more manageable.

Cross-database functionality combined with iceberg format support has been game-changing for our data integration workflows.

For teams heavily invested in cutting-edge dbt features, it is worth noting that Starburst Galaxy is not a tier 1 dbt partner, so it is typically slower to adopt the newest dbt capabilities such as the Fusion Engine and Semantic Layer. While these features would be nice to have, it was not significant enough to deter us from choosing Starburst Galaxy. The core functionality works well and the benefits far outweigh this limitation.

Cluster startup time is another pain point, typically 3 to 5 minutes, which is not the worst with proper planning but can be annoying for ad-hoc work. The lack of a Terraform provider is also a notable gap for infrastructure-as-code workflows. Additionally, integration between data products and the dbt Semantic Layer would significantly enhance the platform's value proposition.

We have used Starburst Galaxy for a few months.

We migrated our self-hosted Trino instance to Starburst Galaxy.

Pricing is competitive and the value proposition depends on your specific use case and requirements. When evaluating against alternatives such as Snowflake, it is worth considering the unique flexibility and cross-database capabilities that Starburst Galaxy provides rather than focusing solely on compute costs.

We briefly explored other options, but given the one-to-one nature of Trino and Starburst Galaxy, it made for a more seamless transition.

Starburst Galaxy excels as a flexible, adaptable solution for teams dealing with complex, multi-source data architectures. It may not be the absolute best at any single function, but its strength lies in being very good at many things while remaining highly malleable.

I would particularly recommend it for teams that need cross-database functionality and iceberg format support, though dbt-focused teams should be prepared to work around the slower adoption of cutting-edge dbt features. It is important to plan for cluster startup times in your workflows, and if infrastructure-as-code is important, factor in the current lack of Terraform support.

Overall, if you are looking for a solution that can bridge gaps in your data architecture rather than replace everything, Starburst Galaxy is an excellent choice that provides the flexibility to adapt to your specific needs.

Starburst Galaxy serves as our primary SQL-based data processing engine, a strategic decision driven by its seamless integration with our AWS cloud infrastructure and its ability to deliver high performance with low-latency responses.

The platform provides a comprehensive suite of functionalities that significantly enhance the daily operations of our data engineers and data analysts.

Starburst Galaxy has been instrumental in reducing the maintenance effort and management overhead of our Trino cluster, which is particularly valuable given our lean platform team responsible for Kovi's data infrastructure.

The platform has enabled us to deploy multiple clusters for different purposes while providing clear cost tracking and utilization monitoring capabilities.

The most relevant functionalities today are cluster autoscaling for intensive load periods and automated metadata management through cleaning, compression, and orphaned file deletion in Iceberg.

These capabilities significantly reduce reading costs, storage expenses, and query processing overhead.

I maintain weekly conversations with Starburst's development and support teams, which provides me with visibility into the product roadmap and evolution.

Currently, my primary need is the impersonation functionality for BI solutions within Starburst clusters, which would enable enhanced access control and data governance capabilities.

I have used the solution for almost 2 years.

Previously, I utilized the AWS stack with Redshift and Athena.

I chose to migrate to Starburst Galaxy due to their expertise with Trino, superior aggregate cost structure compared to my previous solutions, and the rapid product evolution with new functionalities, problem corrections, and performance improvements.

Since Starburst Galaxy's pricing model is simple to understand and easy to predict, there are no major secrets.

Everything is transparent and accessible through the product console.

The only point of attention is the S3 and transfer costs that should also be included when calculating the total cost.

I use Starburst as a cost-efficient hosted option for Trino for data integration and ad-hoc analysis across a broad range of data sources. It is surprisingly useful to query SQL Server, a Google Sheet, data in a blob store, and persist it in Postgres for downstream consumption.

In addition, the Galaxy platform features such as scheduling jobs, offering a data catalog, easy permission and access control management, and the strong technical support from Starburst make it a breeze to use compared to something like Athena.

I have removed data silos, sped up my pipelines (three to five times the speed of Redshift on a per-cost basis), and now have a single point of entry with consistent SQL semantics to all of my data systems.

Query federation coupled with excellent performance is the best feature by far. A consistent interface to all my data systems and a friendly UI that supports data personas from Analyst to Architect and everyone in between is extremely valuable.

As a hosted option, I wish I had more control over the cluster configuration, specifically regarding some of the more advanced options. Trino is extremely flexible and powerful, but some of this functionality is gated on the Galaxy platform.

Most users and admins will never need these features, but on occasion I have encountered issues that could have been resolved by a configuration change in five minutes rather than redesigning a data product. That said, I have a high degree of expertise with the tool, and this is more of a quibble than a major issue.

I have used the solution for four years.

If I have the choice of tooling for managing and interacting with data systems, I always choose Trino first and Starburst Galaxy if I am responsible for managing the deployment. My current team deployed on Redshift before I joined, and the first and best architectural choice I made was to migrate to Galaxy.

You pay for cluster uptime. It is important to be aggressive about autoscaling, as a single worker will get you a long way. I recommend never connecting a BI tool to your Galaxy cluster. Instead, write the data to Postgres or a hot database and serve it from there so you don't pay for expensive uptime to serve dashboards.

Having a good amount of expertise in the domain, I knew that Galaxy was the right choice for quick deployment. Having managed data at scale (hundreds of terabytes) in the past, I know Trino will get the job done without a lot of hassle.

Athena specifically has two major issues. First, connectors are restricted on write functionality and are more difficult to configure. Not being able to write through connectors is a deal breaker. Second, if you scale out enough, you will encounter issues due to Athena's shared tenancy model and then need to migrate to Trino eventually. It is better to save yourself the hassle.

If you are unsure about the service, try the free trial. You can be up to speed with your existing systems in half an hour.