From fragmented to federated: How a Fortune 100 org simplified data access

From rising startups to Fortune 10 technology leaders, businesses of all sizes and industries have adopted Hasura as their API platform, for use cases ranging from federated data access to monolith decomposition.

In this new Hasura Chronicles blog series, we share anonymized narratives of these use cases – highlighting their challenges and goals, and how Hasura fits their use case.

Backstory

A Fortune 100 technology company recently reached out to evaluate Hasura to federate its siloed data sources. This company’s security team was tasked with scanning data to detect policy violations and then alerting the appropriate teams. However, this mission-critical data was scattered across disparate NoSQL and relational databases, APIs, data warehouses, and more.

As a result, their current architecture aggregated everything in one data store. While functional, their existing architecture came with challenges, and the team was looking for ways to more easily achieve their end goal of detecting policy violations.

Challenges

Their existing architecture suffered from the following problems:

Scaling issues: The NoSQL store had scaling and performance issues as more data was aggregated into it.
Lengthy integration cycles: Integrating new sources took weeks because of custom data collector development.
High cost and complexity: Data movement was expensive and required upkeep.

A senior solutions architect at the company said, “Historically, it's taken us days or weeks to build a new data collector when a fresh data source arrives.”

To bypass these limitations, the team explored implementing a federated data access layer. The leadership liked the idea of a single interface to run complex queries that combined data from different source systems.

Their requirements included the following:

A unified query interface
A standard syntax
Integration with NoSQL and relational DBs (MongoDB, MySQL, PostgreSQL, etc.), and other GraphQL APIs
Ability to join data between NoSQL instances and REST APIs

Why Hasura

In a POC, the company’s engineers successfully connected Hasura to their NoSQL datastore and various REST services – instantly creating a federated GraphQL API layer above their siloed data sources. Hasura’s supergraph architecture addressed many challenges while meeting their need for a unified query engine on all data.

With Hasura, the solutions architects were able to:

Quickly onboard any data source
Hasura data connectors allowed them to rapidly connect new data sources into their unified data layer (supergraph). The breadth of connector support meant Hasura would work with its diverse data sources (NoSQL and relational databases, GraphQL and REST APIs, etc.).
Unified, composable syntax
The Hasura supergraph supports complex composition across one or many sources through a single standardized API. This meant the security team could write security violation queries that worked with data from multiple places without physically moving the data to a central store.
High performance
Since the Hasura query planner leverages the strength of the underlying data source where possible, even the federated queries were quite fast. Additionally, the team didn’t have to worry about the scaling, data freshness, and performance challenges of compiling data to a central store. With Hasura, they were able to fetch data directly from the source in JIT compilations.

Hasura’s data federation capabilities are proving to be a compelling solution for many Fortune 100 organizations looking to connect their fragmented data. By federating disparate data sources into a unified GraphQL layer, companies can unlock access to distributed data while enforcing centralized governance.

We’re excited to work with this customer and help more teams bring this use case into production.