Skip to content

Commit d261c82

Browse files
committed
AUTO: Sync ScalarDB docs in English to docs site repo
1 parent 561f288 commit d261c82

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

docs/roadmap.mdx

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -27,8 +27,8 @@ If you have a feature request or want to prioritize feature development, please
2727

2828
#### Security
2929

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.
30+
- **Attributed-based access control (ABAC)**
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 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.
3232

3333
#### Usability
3434

@@ -68,7 +68,7 @@ If you have a feature request or want to prioritize feature development, please
6868
#### Performance
6969

7070
- **Removal of WAL-interpreted views in ScalarDB Analytics**
71-
- Users will be able to read committed data by using ScalarDB Core instead of WAL-interpreted views.
71+
- Users will be able to read committed data by using ScalarDB Core instead of WAL-interpreted views, which will increase query performance.
7272

7373
### CY2025 Q3
7474

@@ -86,7 +86,7 @@ If you have a feature request or want to prioritize feature development, please
8686
#### Scalability and availability
8787

8888
- **Semi-synchronous replication**
89-
- 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.
89+
- 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.
9090

9191
### CY2025 Q4
9292

0 commit comments

Comments
 (0)