Skip to content

Commit 489f867

Browse files
AUTO: Sync ScalarDB docs in English to docs site repo (#947)
Co-authored-by: josh-wong <[email protected]>
1 parent 7c6c156 commit 489f867

File tree

1 file changed

+39
-25
lines changed

1 file changed

+39
-25
lines changed

versioned_docs/version-3.12/roadmap.mdx

Lines changed: 39 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -17,34 +17,22 @@ If you have a feature request or want to prioritize feature development, please
1717

1818
:::
1919

20-
### CY2024 Q4
20+
### CY2025 Q1
2121

2222
#### New capabilities
2323

24-
- **Data virtualization for analytics**
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.
2624
- **Vector store abstraction**
2725
- 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.
2826

2927
#### Security
28+
3029
- **Fine-grained access control**
3130
- 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.
3231

3332
#### Usability
3433

3534
- **Addition of time-related data types**
3635
- Users will be able to use time-related data types, which will make their existing applications easier to migrate.
37-
- **Removal of extra-write strategy**
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.
39-
40-
#### Performance
41-
42-
- **One-phase commit optimization**
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.
44-
- **Reduction of storage space needed for managing ScalarDB metadata**
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.
4836

4937
#### Cloud support
5038

@@ -53,37 +41,63 @@ If you have a feature request or want to prioritize feature development, please
5341
- **Google Cloud Platform (GCP) support**
5442
- Users will be able to deploy ScalarDB Cluster in Google Kubernetes Engine (GKE) in GCP.
5543

56-
### CY2025 Q1
44+
### CY2025 Q2
5745

5846
#### New capabilities
5947

6048
- **Native secondary index**
6149
- 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.
6250

51+
#### Support for additional databases
52+
53+
- **Databricks**
54+
- Users will be able to use Databricks as an underlying database through ScalarDB Cluster.
55+
- **Snowflake**
56+
- Users will be able to use Snowflake as an underlying database through ScalarDB Cluster.
57+
6358
#### Usability
6459

65-
- **Addition of SQL operations for aggregation**
66-
- Users will be able to issue aggregation operations in ScalarDB SQL.
60+
- **Addition of decimal data types**
61+
- Users will be able to use decimal data types so that users can handle decimal numbers with high precision.
62+
- **Removal of extra-write strategy**
63+
- 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.
64+
- **Better governance in ScalarDB Analytics**
65+
- Users will be able to be authenticated and authorized by using the ScalarDB Core features.
6766

68-
- **Elimination of out-of-memory errors due to large scans**
69-
- Users will be able to issue large scans without experiencing out-of-memory errors.
70-
- **Enabling of read operations during a paused duration**
71-
- Users will be able to issue read operations even during a paused duration so that users can still read data while taking backups.
72-
- **Addition of more data types**
73-
- Users will be able to use more data types so that their existing applications will be easier to migrate.
67+
#### Performance
7468

75-
### CY2025 Q2 -
69+
- **Removal of WAL-interpreted views in ScalarDB Analytics**
70+
- Users will be able to read committed data by using ScalarDB Core instead of WAL-interpreted views.
71+
72+
### CY2025 Q3
7673

7774
#### Usability
7875

7976
- **Views**
80-
- Users will be able to define Views so that they can manage multiple different databases in an easier and simplified way.
77+
- Users will be able to define views so that they can manage multiple different databases in an easier and simplified way.
78+
- **Addition of SQL operations for aggregation**
79+
- Users will be able to issue aggregation operations in ScalarDB SQL.
80+
- **Elimination of out-of-memory errors due to large scans**
81+
- Users will be able to issue large scans without experiencing out-of-memory errors.
82+
- **Enabling of read operations during a paused duration**
83+
- Users will be able to issue read operations even during a paused duration so that users can still read data while taking backups.
8184

8285
#### Scalability and availability
8386

8487
- **Semi-synchronous replication**
8588
- 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.
8689

90+
### CY2025 Q4
91+
92+
#### Performance
93+
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+
- **Reduction of storage space needed for managing ScalarDB metadata**
97+
- 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+
87101
#### Cloud support
88102

89103
- **Red Hat OpenShift support**

0 commit comments

Comments
 (0)