Skip to content

Commit eb9d836

Browse files
committed
AUTO: Sync ScalarDB docs in English to docs site repo
1 parent 462b795 commit eb9d836

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

versioned_docs/version-3.12/roadmap.mdx

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

2727
#### Security
2828

29-
- **Fine-grained access control**
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 users are authorized to issue particular operations, ScalarDB will check if users can access particular records.
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.
3131

3232
#### Usability
3333

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

6969
- **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.
70+
- Users will be able to read committed data by using ScalarDB Core instead of WAL-interpreted views, which will increase query performance.
7171

7272
### CY2025 Q3
7373

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

8787
- **Semi-synchronous replication**
88-
- 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.
88+
- 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.
8989

9090
### CY2025 Q4
9191

0 commit comments

Comments
 (0)