Matt Aslett's Analyst Perspectives

I previously explained the arguments in favor of adoption of distributed SQL databases, the new generation of operational data platforms designed to combine the benefits of the relational database model and native support for distributed cloud architecture. It is critical for distributed SQL vendors to engage with developers to ensure they are considering the importance of resilience that spans multiple data centers and/or cloud regions as they choose the databases that will underpin next-generation applications. However, I also noted that compatibility with existing applications, frameworks, drivers and tools is essential in lowering barriers to adoption as well as migration of existing applications from more traditional relational databases. Distributed SQL database provider Yugabyte recently stepped up its ability to support migration of workloads from existing databases with the launch of its YugabyteDB Voyager database migration offering.

Yugabyte was founded in 2016 by former Facebook software engineers to create a database that would deliver the scalability, reliability and developer-friendliness required to support the social media giant yet still be accessible to every company. YugabyteDB is the company’s cloud-native, open-source, distributed SQL database and provides horizontal scalability, resiliency, geo-distributed data replication and availability across multiple clouds as well as on-premises data centers. Although community support is available, the company does not provide commercial support for YugabyteDB. Instead it engages with customers via YugabyteDB Anywhere, a self-managed cloud database, and YugabyteDB Managed, a fully-managed cloud database service. Both provide the core database features of YugabyteDB as well as additional infrastructure and operations management capabilities and commercial support. In addition to supporting the development of new applications, Yugabyte has taken steps to improve capabilities to enable the migration of existing applications to YugabyteDB with the recent launch of YugabyteDB Voyager. YugabyteDB Voyager is designed to assist customers in assessing migration readiness, analyzing schema complexity and planning, optimizing and conducting migration of data and schema as well as capturing best practices as repeatable processes. Migrating existing applications to distributed SQL databases can be complex given that existing, single-node applications have not been developed to take advantage of a distributed architecture, and many distributed SQL databases are not designed to support single-node applications. YugabyteDB Voyager is also designed to suggest schema changes required to make use of a distributed database environment.

In addition to its distributed cloud-native architecture, YugabyteDB is designed to provide compatibility with the PostgreSQL open-source database as well as Apache Cassandra. This compatibility is integral to the company’s engagement with application developers. Building on PostgreSQL not only provides support for core relational-database features, including ACID transactions, functions, stored procedures and triggers, but also ensures that the ecosystem of PostgreSQL-compatible applications, frameworks, drivers and tools can be used with YugabyteDB.

The time is right for engaging with developers on new development projects. I assert that through 2025, two-thirds of organizations will re-examine current operational database suppliers with a view to improving fault tolerance and supporting the development of new intelligent operational applications. Compatibility with popular open-source databases is important in enabling developers to use familiar tools and techniques when developing new applications. This is delivered by the YugabyteDB Query Layer, which includes the Yugabyte SQL application programming interface, providing compatibility with PostgreSQL and the Yugabyte Cloud Query Language API, which is based on the Cassandra Query Language as used by the Apache Cassandra NoSQL database.

The YugabyteDB Query Layer forms one part of YugabyteDB’s two-tier architecture. The other is YugabyteDB’s DocDB distributed document store, which is responsible for transactions, sharding, replication and persistence based on the Raft consensus-based replication protocol to provide geo-distributed scalability. There are typically four key requirements that drive initial interest and adoption of distributed SQL databases: elastic scalability and high throughput, business continuity and high availability, low latency data access for applications available across multiple regions and support for data residency across multiple geographies. These requirements are not mutually exclusive and many distributed SQL database deployments will take advantage of functionality to address more than one. YugabyteDB supports a combination of synchronous and asynchronous replication that can be combined to fit performance and availability requirements. Typically, replication within a single region will be synchronous, with asynchronous replication between regions. But synchronous replication can span multiple regions for use-cases that do not require sub-millisecond latency. YugabyteDB is available on Amazon Web Services, Google Cloud and Microsoft Azure.

Availability as a cloud-agnostic data layer can be used to support multi-cloud strategies. More than two-fifths (42%) of participants in Ventana Research’s Analytics and Data Benchmark Research using cloud systems currently have more than one cloud provider. It is also increasingly important in providing a key component to support enterprise cloud exit strategies, which are increasingly being demanded by financial services regulators. Although these trends are driving interest in distributed SQL and Yugabyte as well as adoption by numerous customers, the company is still relatively unknown and needs to continue to evangelize the advantages of the distributed SQL approach and raise its profile. Nevertheless, I recommend that any organization exploring options for new database development and cloud migration projects should include Yugabyte in evaluations.

Regards,

Matt Aslett