You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/overview.mdx
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,6 +58,12 @@ Modern architectures, like the microservice architecture, encourage a system to
58
58
59
59
ScalarDB simplifies managing such diverse databases with a correctness guarantee (or, in other words, ACID with strict serializability), enabling you to focus on application development without worrying about guaranteeing consistency between databases.
60
60
61
+
### Simplifying data management in a data mesh
62
+
63
+
Enterprises have been investing their time in building [data meshes](https://martinfowler.com/articles/data-mesh-principles.html) to streamline and scale data utilization. However, constructing a data mesh is not necessarily easy. For example, there are many technical issues in how to manage decentralized data.
64
+
65
+
ScalarDB simplifies the management of decentralized databases in a data mesh, for example, by providing a unified API for all the databases in a data mesh to align with the data-as-a-product principle easily.
66
+
61
67
### Reducing database migration hurdles
62
68
63
69
Applications tend to be locked into using a certain database because of the specific capabilities that the database provides. Such database lock-in discourages upgrading or changing the database because doing so often requires rewriting the application.
Copy file name to clipboardExpand all lines: docs/roadmap.mdx
+20-29Lines changed: 20 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,25 +17,23 @@ If you have a feature request or want to prioritize feature development, please
17
17
18
18
:::
19
19
20
-
### CY2024 Q3
20
+
### CY2024 Q4
21
21
22
22
#### New capabilities
23
23
24
-
-**Data virtualization for non-transactional storage operations**
25
-
- Users will be able to run non-transactional storage operations on diverse data sources through ScalarDB. This enhancement will virtually unify various data stores, like relational databases and NoSQL databases, without regard to whether the data sources are managed by ScalarDB transactions.
26
24
-**Data virtualization for analytics**
27
25
- Users will be able to run read-only OLAP SQL queries on diverse data sources through ScalarDB Analytics. ScalarDB Analytics currently supports only ScalarDB-managed data stores, so this enhancement will virtually unify various data stores, like relational databases and NoSQL databases, and files in cloud object stores, like Amazon S3, without regard to whether the data sources are managed by ScalarDB transactions.
26
+
-**Vector store abstraction**
27
+
- Users will be able to store and search embeddings (vectors) in and from vector stores through a new vector store interface in ScalarDB. With this feature, users can simplify the process of realizing retrieval-augmented generation (RAG) with large language models (LLMs) by reading data from databases through the existing ScalarDB interface, creating embeddings from the data, and storing and searching the embeddings to and from a vector store through the new interface.
28
28
29
29
#### Security
30
-
31
-
-**Transparent data encryption**
32
-
- Users will be able to specify what columns to be encrypted. ScalarDB will encrypt records in a transparent manner where records will be encrypted before writing them to disk and the records will be decrypted before sending them back to users.
30
+
-**Fine-grained access control**
31
+
- Users will be able to authorize accesses to the underlying databases in a finer-grained way. In addition to the current simple authorization where ScalarDB checks if users are authorized to issue particular operations, ScalarDB will check if users can access particular records.
33
32
34
33
#### Usability
35
34
36
35
-**Addition of time-related data types**
37
36
- Users will be able to use time-related data types, which will make their existing applications easier to migrate.
38
-
39
37
-**Removal of extra-write strategy**
40
38
- Users will no longer be able to use the extra-write strategy to make transactions serializable. Although ScalarDB currently provides two strategies, extra-read and extra-write strategies, to make transactions serializable, the extra-write strategy has several limitations. For example, users can't issue write and scan operations in the same transaction. Therefore, the strategy will be removed so that users don't need to worry about such limitations when creating applications.
41
39
@@ -45,6 +43,8 @@ If you have a feature request or want to prioritize feature development, please
45
43
- Users will experience faster execution for simple transactions that write to a single partition. ScalarDB will omit the prepare-record and commit-state phases without sacrificing correctness if a transaction updates only one partition by exploiting the single-partition linearizable operations of the underlying databases.
46
44
-**Reduction of storage space needed for managing ScalarDB metadata**
47
45
- Users will likely use less storage space to run ScalarDB. ScalarDB will remove the before image of committed transactions after they are committed. However, whether or not those committed transactions will impact actual storage space depends on the underlying databases.
46
+
-**Removal of coordinator writes for read-only transactions**
47
+
- Users will experience faster execution for read-only transactions by removing coordinator writes for those transactions.
48
48
49
49
#### Cloud support
50
50
@@ -53,11 +53,12 @@ If you have a feature request or want to prioritize feature development, please
53
53
-**Google Cloud Platform (GCP) support**
54
54
- Users will be able to deploy ScalarDB Cluster in Google Kubernetes Engine (GKE) in GCP.
55
55
56
-
### CY2024 Q4
56
+
### CY2025 Q1
57
57
58
-
#### Security
59
-
-**Fine-grained access control**
60
-
- Users will be able to authorize accesses to the underlying databases in a finer-grained way. In addition to the current simple authorization where ScalarDB checks if users are authorized to issue particular operations, ScalarDB will check if users can access particular records.
58
+
#### New capabilities
59
+
60
+
-**Native secondary index**
61
+
- Users will be able to define flexible secondary indexes. The existing secondary index is limited because it is implemented based on the common capabilities of the supported databases' secondary indexes. Therefore, for example, you cannot define a multi-column index. The new secondary index will be created at the ScalarDB layer so that you can create more flexible indexes, like a multi-column index.
61
62
62
63
#### Usability
63
64
@@ -71,24 +72,7 @@ If you have a feature request or want to prioritize feature development, please
71
72
-**Addition of more data types**
72
73
- Users will be able to use more data types so that their existing applications will be easier to migrate.
73
74
74
-
#### Performance
75
-
76
-
-**Removal of coordinator writes for read-only transactions**
77
-
- Users will experience faster execution for read-only transactions by removing coordinator writes for those transactions.
78
-
79
-
#### Cloud support
80
-
81
-
-**Red Hat OpenShift support**
82
-
- Users will be able to use Red Hat–certified Helm Charts for ScalarDB Cluster in OpenShift environments.
83
-
-**Container offering in Google Cloud Marketplace**
84
-
- Users will be able to deploy ScalarDB Cluster by using the Google Cloud container offering, which enables users to use a pay-as-you-go subscription model.
85
-
86
-
### CY2025 Q1 -
87
-
88
-
#### New capabilities
89
-
90
-
-**Native secondary index**
91
-
- Users will be able to define flexible secondary indexes. The existing secondary index is capable of the intersection of what the underlying databases' secondary indexes are capable of; thus, it is very limited. The new, native secondary index creates indexes at the ScalarDB layer so that it is more flexible. For example, the native secondary index can define multi-column indexes.
75
+
### CY2025 Q2 -
92
76
93
77
#### Usability
94
78
@@ -99,3 +83,10 @@ If you have a feature request or want to prioritize feature development, please
99
83
100
84
-**Semi-synchronous replication**
101
85
- Users will be able to provide ScalarDB-based applications in a disaster-recoverable manner. For example, assume you provide a primary service in Tokyo and a standby service in Osaka. In case of catastrophic failure in Tokyo, you can switch the primary service to Osaka so that you can continue to provide the service without data loss and extended downtime.
86
+
87
+
#### Cloud support
88
+
89
+
-**Red Hat OpenShift support**
90
+
- Users will be able to use Red Hat–certified Helm Charts for ScalarDB Cluster in OpenShift environments.
91
+
-**Container offering in Google Cloud Marketplace**
92
+
- Users will be able to deploy ScalarDB Cluster by using the Google Cloud container offering, which enables users to use a pay-as-you-go subscription model.
0 commit comments