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: versioned_docs/version-3.12/roadmap.mdx
+50-34Lines changed: 50 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,43 +17,20 @@ If you have a feature request or want to prioritize feature development, please
17
17
18
18
:::
19
19
20
-
### CY2025 Q1
21
-
22
-
#### New capabilities
23
-
24
-
-**Vector store abstraction**
25
-
- 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.
26
-
27
-
#### Security
28
-
29
-
-**Attributed-based access control (ABAC)**
30
-
- 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 a user is authorized to issue particular operations to a table, ScalarDB will check if a user can access particular records based on the attributes of the user and the records.
31
-
32
-
#### Usability
33
-
34
-
-**Addition of time-related data types**
35
-
- Users will be able to use time-related data types, which will make their existing applications easier to migrate.
36
-
37
-
#### Cloud support
38
-
39
-
-**Container offering in Azure Marketplace**
40
-
- Users will be able to deploy ScalarDB Cluster by using the Azure container offering, which enables users to use a pay-as-you-go subscription model.
41
-
-**Google Cloud Platform (GCP) support**
42
-
- Users will be able to deploy ScalarDB Cluster in Google Kubernetes Engine (GKE) in GCP.
43
20
44
21
### CY2025 Q2
45
22
46
-
#### New capabilities
47
-
48
-
-**Native secondary index**
49
-
- 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.
50
23
51
24
#### Support for additional databases
52
25
26
+
-**IBM Db2**
27
+
- Users will be able to use IBM Db2 as an underlying database through ScalarDB Cluster.
28
+
-**TiDB**
29
+
- Users will be able to use TiDB as an underlying database through ScalarDB Cluster.
53
30
-**Databricks**
54
-
- Users will be able to use Databricks as an underlying database through ScalarDB Cluster.
31
+
- Users will be able to use Databricks as an underlying database through ScalarDB Cluster and ScalarDB Analytics.
55
32
-**Snowflake**
56
-
- Users will be able to use Snowflake as an underlying database through ScalarDB Cluster.
33
+
- Users will be able to use Snowflake as an underlying database through ScalarDB Cluster and ScalarDB Analytics.
57
34
58
35
#### Usability
59
36
@@ -66,11 +43,33 @@ If you have a feature request or want to prioritize feature development, please
66
43
67
44
#### Performance
68
45
46
+
-**Addition of read-committed isolation**
47
+
- Users will be able to run transactions with a read-committed isolation to achieve better performance for applications that do not require strong correctness.
48
+
-**One-phase commit optimization for a single relational database**
49
+
- Users will be able to run a transaction more efficiently by using one-phase commit if the operations of the transaction are all applied to a single database or a single partition.
50
+
-**Optimization for multiple write operations per database**
51
+
- Users will be able to run transactions more efficiently with a batch preparation and commitment if there are multiple write operations for a database.
52
+
-**Optimization for read-only transactions**
53
+
- Users will be able to run transactions more efficiently by avoiding coordinator writes when committing transactions.
69
54
-**Removal of WAL-interpreted views in ScalarDB Analytics**
70
55
- Users will be able to read committed data by using ScalarDB Core instead of WAL-interpreted views, which will increase query performance.
71
56
57
+
#### Cloud support
58
+
59
+
-**Container offering in Azure Marketplace for ScalarDB Cluster**
60
+
- Users will be able to deploy ScalarDB Cluster by using the Azure container offering, which enables users to use a pay-as-you-go subscription model.
61
+
-**Google Cloud Platform (GCP) support for ScalarDB Cluster**
62
+
- Users will be able to deploy ScalarDB Cluster in Google Kubernetes Engine (GKE) in GCP.
63
+
-**Container offering in Amazon Marketplace for ScalarDB Analytics**
64
+
- Users will be able to deploy ScalarDB Analytics by using the container offering, which enables users to use a pay-as-you-go subscription model.
65
+
72
66
### CY2025 Q3
73
67
68
+
#### New capabilities
69
+
70
+
-**Decoupled metadata management**
71
+
- Users will be able to start using ScalarDB Cluster without migrating or changing the schemas of existing applications by managing the transaction metadata of ScalarDB in a separate location.
72
+
74
73
#### Usability
75
74
76
75
-**Views**
@@ -82,25 +81,42 @@ If you have a feature request or want to prioritize feature development, please
82
81
-**Enabling of read operations during a paused duration**
83
82
- Users will be able to issue read operations even during a paused duration so that users can still read data while taking backups.
84
83
84
+
#### Performance
85
+
86
+
-**One-phase commit optimization**
87
+
- 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.
88
+
85
89
#### Scalability and availability
86
90
87
91
-**Semi-synchronous replication**
88
92
- Users will be able to replicate the data of 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.
89
93
90
94
### CY2025 Q4
91
95
96
+
#### New capabilities
97
+
98
+
-**Native secondary index**
99
+
- 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.
100
+
-**Better catalog management**
101
+
- Users will be able to manage a data catalog across diverse databases in a unified manner.
102
+
103
+
#### Support for additional databases (object storage)
104
+
105
+
-**Azure Blob Storage**
106
+
- Users will be able to use Azure Blob Storage as an underlying database through ScalarDB Cluster.
107
+
-**Amazon S3**
108
+
- Users will be able to use Amazon S3 as an underlying database through ScalarDB Cluster.
109
+
-**Google Cloud Storage**
110
+
- Users will be able to use Google Cloud Storage as an underlying database through ScalarDB Cluster and ScalarDB Analytics.
111
+
92
112
#### Performance
93
113
94
-
-**One-phase commit optimization**
95
-
- 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.
96
114
-**Reduction of storage space needed for managing ScalarDB metadata**
97
115
- 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.
98
-
-**Removal of coordinator writes for read-only transactions**
99
-
- Users will experience faster execution for read-only transactions by removing coordinator writes for those transactions.
100
116
101
117
#### Cloud support
102
118
103
119
-**Red Hat OpenShift support**
104
120
- Users will be able to use Red Hat–certified Helm Charts for ScalarDB Cluster in OpenShift environments.
105
121
-**Container offering in Google Cloud Marketplace**
106
-
- 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.
122
+
- 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