Starburst Enterprise Reviews

We use Starburst with one client who is exploring their ecosystem to remove data silos and enable data access across departments. It's a very big ecosystem, like a finance institute. They are currently exploring Starburst, and it's all in the research phase. We haven't used it in production yet.

It's all internal to Starburst's query optimization platform. They check the data volume, how it can be optimized, what pushdown factors to apply, and so on. It's all technical and internal to the system.

I've connected to databases and Salesforce, among other things. I haven't personally tried MongoDB or NoSQL databases, but they are supported in the Starburst ecosystem. I have definitely tried relational databases like Neo4j and others.

Starburst has changed the eco-system where you don't need to move the data, saving storage costs. It provides unified, virtual data access, allowing you to perform operations directly on the source. There's also parallel computing, data optimization, and cost optimization.

Primarily, the idea of not moving data from source to target and avoiding duplication is a major benefit of Starburst. You can connect to any data source from any region and have a unified view of data across your organization. There might be some latency, but it's worth it for the unified access.

Security and data governance are addressed through Immuta or Ranger policies. ABAC (Attribute-Based Access Control), PBAC (Policy-Based Access Control), and RBAC (Role-Based Access Control) are all supported. We primarily use Ranger.

There are no specific projects supported by Starburst regarding AI initiatives or machine learning projects. 

In the future, if we have all the data available, we can definitely capitalize on AI/ML and LLM capabilities to summarize data and gain insights. That's our future goal, but we haven't reached that point yet.

There should be support for REST API data sources to access data from the web. We often have data coming in and communicate with data sources via REST API calls. I don't see that capability in Starburst currently; everything is through JDBC or ODBC. If Starburst could seamlessly access data using REST API capabilities, it would be a game-changer.

The self-service data management features, like self-service materialized views, are great, but they can be a bit complex for basic users to understand.

I have been using it for one year. 

I haven't personally encountered any performance issues unless there's a cluster computing problem. If there are issues with the compute resources, like not enough nodes or memory, then obviously there will be performance problems. Sometimes it happens because of a poorly written query. 

For example, if you have multiple systems and join them with a bad query, the process will keep running without returning any results. That's not a system problem; it's a user problem, and users will  experience long wait times.

Our customer's environment has around 200 to 300 users. 

We are connected with Starburst directly because we are working with them as a partner. We have direct communication through a Slack channel, and they are always there to help if we encounter any challenges or technical problems.

Starburst is a new product. Everyone is very nice and knowledgeable. Obviously, everyone has their own bandwidth, but mostly, we get help on time and get things done.

Positive

There is another product called Dremio. The difference between Dremio and Starburst is that Starburst needs a whole cluster restart when we need to add any new catalog. If we need to add a new database or data source, we have to configure the entire ecosystem, including YAML files, and then deploy it. Once deployed, we have to restart the whole server for the changes to take effect. That's a very bad architecture, in my opinion.

In Dremio, you can configure things on the fly without needing a restart. You can do it from the front end itself. In Starburst, you have to go to the back end and need support from the infrastructure team. There's no front end for configuring the catalog. I feel they should develop a process to configure catalogs from the front end rather than requiring backend deployment and cluster restarts every time. It takes a lot of time and is not a good architecture.

For data analytics, we primarily use Tableau and Power BI, mainly Tableau. We connect Starburst with Tableau for analysis.

It's Kubernetes-based, so it's a little challenging. Doing it externally for learning purposes was fine, but when users have to deploy in Kubernetes requires a learning curve for Kubernetes, Helm, and related technologies. It's a better-managed and performing setup for Starburst, but definitely challenging. You have to make a lot of custom changes if you need to do things that Starburst doesn't support out of the box.

I worked with the cloud version. I think there's also an on-premises option where they spin up the cluster in their own data center. I haven't done that, but I have experience setting it up in the AWS cloud.

The deployment takes a good amount of time because there are a lot of things to do. It's not just building the Helm Chart. You'll encounter networking and access challenges. It takes a day or two if you're not very familiar with the process.

Maintenance, when it's in the cloud, is handled by the system itself through auto-scaling and the Kubernetes cluster. However, maintenance can sometimes be challenging because clients have specific requirements for their ecosystem, like security or governance, that Starburst might not support out of the box. 

Starburst is constantly evolving, but it takes time for older versions to get those features. So, you have to make sure your system works with both the current and future versions of Starburst. It's an ongoing process for any organization.

We were trained on it, so we could handle it ourselves. We had a learning curve, but we received training from Starburst. Now we're training others in the organization.

Starburst requires a heavy investment in infrastructure; it needs heavy computing and storage. If your use case doesn't involve heavy processing or storage, then Starburst might not be the solution. It's more suitable for large ecosystems spread across regions, or companies with a massive employee base. In those cases, Starburst sounds good, but Dremio might be better for smaller organizations. I can't compare them directly, but Starburst definitely needs a good infrastructure investment, good infrastructure management, and skilled personnel.

The product is nice, there's no doubt about that. It's very scalable, fast performing, and supports many catalogs and connectors that Dremio doesn't have. Dremio is limited to ten to fifteen connectors, while Starburst supports forty to fifty, so it has a much bigger ecosystem. In that way, Starburst wins.

Between Dremio and Starburst, considering the connectors, Starburst gets a nine out of ten.

We use Starburst Enterprise for data transformation. We load different file formats, like CSV or Excel, into Starburst Enterprise and transform the data into target tables. These tables are then utilized by our modeling team.

The most valuable feature of Starburst Enterprise is its UI, which provides analytics. It shows how many workers are being used and the data size utilized, helping us understand utilization. Additionally, the UI helps us make informed decisions based on our requirements. The user permissions and roles feature is also very advantageous.

We have noticed improvements in performance using Starburst Enterprise. It handles complex data, including reading and partitioning files. We can add a new catalog to Starburst Enterprise by providing connection details and service account information. This allows us to integrate with existing tools, such as the Snowflake database, which we use for data protection in our project.

It is fairly easy to learn to use Starburst Enterprise, especially if you already have some knowledge of SQL. It's similar to other SQL systems but with some minor changes in syntax. Overall, if you understand the major flows of SQL, you'll find it straightforward.

Starburst Enterprise could improve by offering additional features similar to those provided by other SQL query tools. For example, incorporating functionalities like pivot tables would make it more feasible to use. 

When comparing different SQL tools, we find that other tools have a pivot functionality, allowing data to be pivoted from one column to another. This feature is currently lacking in Starburst Enterprise. If Starburst could provide this functionality, it would be very beneficial.

I have been using the product for one year.

The solution is stable.

The tool is scalable. You can easily add users, assign roles, etc. However, if you want to add new workers and the current environment doesn't have the capacity, you may need to shift to other environments or add new machines from AWS.

My company has 20 users, and my project has ten users. We have different roles. For each project, there are one or two administrators who set up roles and privileges. Administrators can be data engineers, and the roles might overlap a bit. Each team has three to five data engineers and three to five data analysts. Data analysts have read access to schemas and tables, while data engineers have all privileges.

I haven't contacted the tool's support. 

There are a few factors that influenced our company's decision to use Starburst Enterprise. Primarily, it was due to the volume of data we were handling and our data lake architecture, which requires the integration of diverse data sources. Starburst Enterprise makes adding catalogs for connection and service account details easy, facilitating seamless integration with our servers.

The solution's implementation is easy. 

I haven't personally dealt with the pricing aspects first-hand, but from what I understand, it largely depends on the specifics of your setup, especially the machines you use on AWS. The cost of using Starburst Enterprise can vary based on the amount of data you're processing and the type of machines you opt for, whether on AWS or another cloud platform.

Mostly, we've worked with static data files, not on AI-driven or streaming data. The modeling team uses the analytics part, where each modeling user can work with a separate command.

The tool's feasibility depends on the architecture you're currently working with. If you're dealing with data from multiple sources, like we are, then Starburst Enterprise could be very beneficial. As a first-time user, I recommend going through the documentation and setting up some proof of concept to see if it meets the needs of your projects. These steps can help you determine if the solution is the right tool for you.

I rate the overall solution an eight out of ten.