ScalarDB 3.9 has been released!

We are pleased to announce that we have released a new minor version of ScalarDB, ScalarDB 3.9. In this minor release, we:

• Introduced ScalarDB Analytics with PostgreSQL, which supports analytical queries in ScalarDB.
• Integrated ScalarDB GraphQL Server and ScalarDB SQL Server components into ScalarDB Cluster.
• Added support for two-phase commit (2PC) interfaces in ScalarDB GraphQL and ScalarDB SQL.
• Added SQLite as a supported database in ScalarDB.

In this blog post, we will share these new features in detail.

Support for analytical queries by using ScalarDB Analytics with PostgreSQL

ScalarDB is a general-purpose distributed transaction manager that enables ACID transactions spanning multiple different databases. It primarily targets workloads involving a large number of simple transactions. On the other hand, for complex analytical processing that requires joining and aggregating data, implementing these operations on the application itself was necessary. Thus, it was unsuitable for ad-hoc analytics.

In ScalarDB 3.9, we introduced ScalarDB Analytics with PostgreSQL, which lets users execute integrated and cross-database analytical queries across multiple different databases that ScalarDB manages. This is achieved by using PostgreSQL’s foreign data wrapper (FDW).

As a result, users can perform cross-database analytical processing across the multiple databases that ScalarDB manages, just as if they were using regular PostgreSQL.

For more details about ScalarDB Analytics with PostgreSQL, please refer to this documentation for getting started with ScalarDB Analytics with PostgreSQL and the related blog post .

Integration of ScalarDB GraphQL Server and ScalarDB SQL Server into ScalarDB Cluster

With ScalarDB Cluster, application developers don’t need to be concerned about the complex and intricate management of transaction states when operating multiple ScalarDB containers. However, when using GraphQL or SQL interfaces, it was necessary to deploy ScalarDB GraphQL and ScalarDB SQL containers separately from ScalarDB Cluster. When using these interfaces, users encountered the challenge of complicating system construction and deployment.

In ScalarDB 3.9, we integrated ScalarDB GraphQL and ScalarDB SQL into the ScalarDB Cluster nodes. As a result, you can deploy the number of ScalarDB Cluster nodes necessary for your application, making deployment simpler and container management more convenient.

For more details regarding ScalarDB Cluster, please refer to this documentation about ScalarDB Cluster.

Support for 2PC interfaces in GraphQL and Spring Data JDBC for ScalarDB

ScalarDB provides the Two-phase commit (2PC)¹ interface to achieve 2PC transactions. However, the ScalarDB GraphQL interface and the Spring Data JDBC support mechanism, known as Spring Data JDBC for ScalarDB, did not support the 2PC interface.

Therefore, when building micro-services applications by using ScalarDB GraphQL or Spring Data JDBC for ScalarDB and attempting to achieve ACID transactions that spanned services, it was necessary to implement 2PC transactions or some other distributed transaction mechanisms within the application. Doing this would require implementation resources, including for debugging and testing, which would incur high costs.

As of ScalarDB 3.9, ScalarDB GraphQL and Spring Data JDBC for ScalarDB now provide the 2PC interface. Using this interface makes it easier to achieve ACID transactions that span services within micro-services that were built by using ScalarDB GraphQL or Spring Data JDBC for ScalarDB.

To execute 2PC transactions by using ScalarDB GraphQL, the @twoPhaseCommit directive should be added to a Query or Mutation.

For more details on 2PC transactions with ScalarDB GraphQL, please refer to this documentation for how to run two-phase commit transactions.

In addition, in Spring Data JDBC for ScalarDB, there are two types of APIs for the 2PC interface:

• Primitive 2PC API
• High-level 2PC API

The primitive 2PC API is a more granular and flexible API that allows invoking the 2PC interface in ScalarDB, enabling detailed control over 2PC transaction processing. However, users need to consider when to call which API. On the other hand, the high-level 2PC API offers a more user-friendly and abstracted API that targets common use cases. Developers do not need to explicitly manage when to commit or roll back.

For more details about the 2PC interface in Spring Data JDBC for ScalarDB, please refer to this documentation about 2PC transactions in Spring Data JDBC for ScalarDB and the related blog post that introduces Spring Data JDBC for ScalarDB.

Support for SQLite

In ScalarDB 3.9, we also added SQLite as a supported database. SQLite is commonly used as an embedded database or for smaller projects. With this addition, ScalarDB has expanded its capability to cater to an even broader range of use cases.

The databases supported in ScalarDB 3.9 are as follows:

• Apache Cassandra
• Azure Cosmos DB for NoSQL
• Amazon DynamoDB
• MySQL
• PostgreSQL
• Oracle Database
• Microsoft SQL Server
• Amazon Aurora (MySQL/PostgreSQL)
• SQLite (New)

Wrap-up

We released ScalarDB 3.9, which contains great enhancements and improvements to help our customers get the most out of ScalarDB. To learn more about ScalarDB, please take a look at other posts on the Scalar Engineering Blog and at the ScalarDB documentation.

If you are considering using ScalarDB, please contact us.

[1]: A commit protocol ensuring the atomicity and durability of transactions involving multiple databases.