Yugabyte distributed SQL database adds migration service
The YugabyteDB 2.15 distributed SQL database update introduces a table group feature to accelerate and optimize performance for different database workloads.
Open source distributed SQL database vendor Yugabyte released version 2.15 of its YugabyteDB database, bringing new workload optimization and migration capabilities to users.
Yugabyte raised $188 million in a Series C round of funding in October 2021 as the vendor continued to build out its database.
With the YugabyteDB update, released on June 28, the vendor added new dynamic workload optimization capabilities designed to enable faster queries and more efficient use of infrastructure resources.
Alongside the database update, the distributed SQL database vendor introduced its Voyager migration service, which is intended to help users of other databases more easily migrate to Yugabyte.
Yugabyte faces several competitors in the distributed SQL database market, including CockroachDB, which recently updated to version 22.1, as well as Google's AlloyDB cloud database. CockroachDB, AlloyDB and YugabyteDB all aim for compatibility with the open source PostgreSQL database. One area that Yugabyte has yet to address is supporting more than just transaction workloads on its database.
"Yugabyte is not yet targeting analytical workloads, which keeps it in a smaller set of opportunities, but the continuing enhancement of its PostgreSQL capabilities will begin to address that," said Gartner analyst Merv Adrian. "Yugabyte is using its considerable war chest to add maturity to its offering with a substantial enterprise-class feature set."
Yugabyte is not yet targeting analytical workloads, which keeps it in a smaller set of opportunities, but the continuing enhancement of its PostgreSQL capabilities will begin to address that.
Merv AdrianAnalyst, Gartner
Adding optimized workload management and migration utilities will help Yugabyte in the competitive market, as the vendor looks to help organizations support distributed transactional applications, Adrian said.
Dynamic workload optimization
In a distributed SQL database, data is often split up using sharding to enable high availability.
Workloads often have different table compositions that can affect workload and query performance with distributed SQL.
For example, some workloads have more tables than rows, which can often lead to more SQL joins, which is how different tables can be connected for a data query. Other workloads entail more data writes into small tables.
With a distributed SQL database like YugabyteDB, in which data is sharded and shared across many nodes, the different types of tables have generally been treated the same in the past, noted Yugabyte co-founder and CTO Karthik Ranganathan.
With the 2.15 update, Yugabyte has introduced the notion of a table group, which combines similar database tables into a group that Ranganathan called a "tablet." The basic idea is that by grouping the tables, the workloads can be optimized for the tablet.
Optimization with the table group approach is different than just caching a database with a technology like Redis, which operates on rows in a database, Ranganathan said.
In contrast, Yugabyte's approach works at the table level. The dynamic workload optimization capability works inside of the Yugabyte database, automatically figuring how to optimize the data for query performance.
Voyager comes to Yugabyte to ease database migration
Part of the 2.15 release is in the inclusion of the Voyager tool for database migration.
Developers know and use many databases and preexisting applications that organizations are trying to move to distributed SQL for more scale and high availability in the cloud.
The initial release of Voyager provides support for database migration from MySQL, PostgreSQL and Oracle Database. Voyager works by understanding the features available in the source database and inspecting the schema to determine how it can be mapped into a YugabyteDB cluster.
Currently, Voyager does a point-in-time migration for an existing source database, but Yugabyte's plan is to enable a live migration capability.
Some organizations might want to continue to run the existing source database for a period of time, while testing out a Yugabyte deployment, Ranganathan said. With live migration, data and schema on the source database and the new Yugabyte deployment can be kept synchronized.
