ScyllaDB University LIVE, FREE Virtual Training Event | March 21
Register for Free
ScyllaDB Documentation Logo Documentation
  • Server
  • Cloud
  • Tools
    • ScyllaDB Manager
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
  • Drivers
    • CQL Drivers
    • DynamoDB Drivers
  • Resources
    • ScyllaDB University
    • Community Forum
    • Tutorials
Download
ScyllaDB Docs ScyllaDB Open Source Alternator: DynamoDB API in Scylla ScyllaDB Alternator for DynamoDB users

Caution

You're viewing documentation for a previous version. Switch to the latest stable version.

ScyllaDB Alternator for DynamoDB users¶

Scylla supports the DynamoDB API (this feature is codenamed “Alternator”). Our goal is to support any application written for Amazon DynamoDB. Nevertheless, there are a few differences between DynamoDB and Scylla, and and a few DynamoDB features that have not yet been implemented in Scylla. The purpose of this document is to inform users of these differences.

Provisioning¶

The most obvious difference between DynamoDB and Scylla is that while DynamoDB is a shared cloud service, Scylla is a dedicated service running on your private cluster. Whereas DynamoDB allows you to “provision” the number of requests per second you’ll need - or at an extra cost not even provision that - Scylla requires you to provision your cluster. You need to reason about the number and size of your nodes - not the throughput.

When creating a table, the BillingMode and ProvisionedThroughput options are ignored by Scylla. Tables default to a Billing mode of PAY_PER_REQUEST and DescribeTable API calls will return a value of 0 for the RCUs, WCUs and NumberOfDecreasesToday within the response.

Scan ordering¶

In DynamoDB, the Hash key (or partition key) determines where the item will be stored within DynamoDB’s internal storage. Another notable difference between DynamoDB and Scylla comes down to the underlying hashing algorithm. While DynamoDB uses a proprietary hashing function, ScyllaDB implements the well-known Murmur3 algorithm.

Even though regular users should not typically care about the underlying implementation details, particularly such difference causes Scan operations to return results in a different order between DynamoDB and Alternator.

Load balancing¶

DynamoDB applications specify a single “endpoint” address, e.g., dynamodb.us-east-1.amazonaws.com. Amazon’s cloud service distributes request for this single URL to many different backend nodes. Such a load-balancing setup is not included inside Alternator. You should either set one up, or configure the client library to do the load balancing itself. Instructions for doing this can be found in: https://github.com/scylladb/alternator-load-balancing/

Write isolation policies¶

Scylla was designed to optimize the performance of pure write operations - writes which do not need to read the the previous value of the item. In CQL, writes which do need the previous value of the item must explicitly use the slower LWT (“LightWeight Transaction”) feature to be correctly isolated from each other. It is not allowed to mix LWT and non-LWT writes to the same item.

In contrast, in the DynamoDB API every write operation may need the previous value of the item. So without making further assumptions, Alternator would need to use the slower LWT for all writes - to correctly isolate concurrent writes. However, if Alternator is told that a certain workload does not have any read-modify-write operations, it can do all writes with the faster non-LWT write. Furthermore, if Alternator is told that a certain workload does have do both write-only and read-modify-write, but to different items, it could use LWT only for the read-modify-write operations.

Therefore, Alternator must be explicitly configured to tell it which of the above assumptions it may make on the write workload. This configuration is mandatory, and described in the “Write isolation policies” section of alternator.md. One of the options, always_use_lwt, is always safe, but the other options result in significantly better write performance and should be considered when the workload involves pure writes (e.g., ingestion of new data) or if pure writes and read-modify-writes go to distinct items.

Avoiding write reordering¶

When a DynamoDB application writes twice to the same item, it expects “last- write-wins” behavior: The later write should overwrite the earlier write. When writes use LWT (the always_use_lwt policy described above), this is indeed guaranteed. However, for other write isolation policies, Scylla does not guarantee that writes are not reordered. In some sense, the “last” write does still win, but the meaning of which write is “last” is different from what most users expect:

In this case (write isolation policy is not always_use_lwt), each write request gets a timestamp which is the current time on the server which received this request. If two write requests arrive at different Alternator nodes, and if the local clocks on these two nodes are not accurately synchronized, then the two timestamps generated independently on the two nodes may have the opposite order as intended - the earlier write may get a higher timestamp - and this will be the “last write” that wins.

To avoid or mitigate this write reordering issue, users may consider one or more of the following:

  1. Use NTP to keep the clocks on the different Scylla nodes synchronized. If the delay between the two writes is longer than NTP’s accuracy, they will not be reordered.

  2. If an application wants to ensure that two specific writes are not reordered, it should send both requests to the same Scylla node. Care should be taken when using a load balancer - which might redirect two requests to two different nodes.

  3. Consider using the always_use_lwt write isolation policy. It is slower, but has better guarantees.

Another guarantee that that always_use_lwt can make and other write isolation modes do not is that writes to the same item are serialized: Even if the two write are sent at exactly the same time to two different nodes, the result will appear as if one write happened first, and then the other. But in other modes (with non-LWT writes), two writes can get exactly the same microsecond-resolution timestamp, the the result may be a mixture of both writes - some attributes from one and some from the other - instead of being just one or the other.

Authentication and Authorization¶

By default, Alternator does not enforce authentication or authorization, and any request from any connected client will be allowed. To enforce client authentication, and authorization of which client is allowed to do what, configure the following in ScyllaDB’s configuration:

`alternator_enforce_authorization: true`

Alternator implements the same signature protocol as DynamoDB and the rest of AWS. Clients use, as usual, an access key ID and a secret access key to prove their identity and the authenticity of their request. Alternator can then validate the authenticity and authorization of each request using a known list of authorized key pairs.

To create a user for authentication, use the CQL “CREATE ROLE” command. When a client signs a request, it uses the name of this role as the access key ID, and the salted hash of the role’s password is the secret key. This secret key for role XYZ can be retrieved by the CQL request SELECT salted_hash from system.roles WHERE role = XYZ;.

Alternator also implements authorization, or access control - defining which authenticated user is allowed to do which operation, such as reading or writing to a specific table. The way this is supported in Alternator is currently not compatible with DynamoDB’s APIs (IAM or PutResourcePolicy). Instead, one needs to grant permissions to specific roles using CQL, with the “GRANT” command. For example, an Alternator table “xyz” is visible to CQL as alternator_xyz.xyz, and the following command will allow requests from user “myrole” to read this table (with GetItem and other read operations): GRANT SELECT ON alternator_xyz.xyz TO myrole. Refer to the CQL documentation on how to use GRANT and REVOKE to control permissions, and which permissions exist: https://docs.scylladb.com/stable/operating-scylla/security/authorization.html

The following permissions are needed to run the following API operations:

  • SELECT: GetItem, Query, Scan, BatchGetItem, GetRecords

  • MODIFY: PutItem, DeleteItem, UpdateItem, BatchWriteItem

  • CREATE: CreateTable

  • DROP: DeleteTable

  • ALTER: UpdateTable, TagResource, UntagResource, UpdateTimeToLive

  • none needed: ListTables, DescribeTable, DescribeEndpoints, ListTagsOfResource, DescribeTimeToLive, DescribeContinuousBackups, ListStreams, DescribeStream, GetShardIterator

Note that the required permissions depend on the type of operation, not on what it does. For example, even though the PutItem operation can read the value of an item (when used with ReturnValues=ALL_OLD), it still requires the MODIFY permission, not the SELECT permission.

Permissions are separate for a base table and each of its GSI/LSI and CDC log, so it’s possible to give a role permissions to read one index and not the base, or vice versa, and so on. To build the GRANT command, you need to know the CQL name of each of these objects. For example, the CQL name of GSI “abc” of Alternator table “xyz” is alternator_xyz.xyz:abc. If you don’t know the name of the table, you can try a forbidden operation and the AccessDeniedException error will contain the name of the table that was lacking permissions.

Metrics¶

Scylla has an advanced and extensive monitoring framework for inspecting and graphing hundreds of different metrics of Scylla’s usage and performance. Scylla’s monitoring stack, based on Grafana and Prometheus, is described in https://docs.scylladb.com/operating-scylla/monitoring/. This monitoring stack is different from DynamoDB’s offering - but Scylla’s is significantly more powerful and gives the user better insights on the internals of the database and its performance.

Time To Live (TTL)¶

Like in DynamoDB, Alternator items which are set to expire at a certain time will not disappear exactly at that time, but only after some delay. DynamoDB guarantees that the expiration delay will be less than 48 hours (though for small tables the delay is often much shorter).

In Alternator, the expiration delay is configurable - it can be set with the --alternator-ttl-period-in-seconds configuration option. The default is 24 hours.

One thing the implementation is missing is that expiration events appear in the Streams API as normal deletions - without the distinctive marker on deletions which are really expirations. See https://github.com/scylladb/scylla/issues/5060.

Note This feature is experimental in versions earlier than ScyllaDB Open Source 5.2 and ScyllaDB Enterprise 2022.2.


Experimental API features¶

Some DynamoDB API features are supported by Alternator, but considered experimental in this release. An experimental feature in Scylla is a feature whose functionality is complete, or mostly complete, but it is not as thoroughly tested or optimized as regular features. Also, an experimental feature’s implementation is still subject to change and upgrades may not be possible if such a feature is used. For these reasons, experimental features are not recommended for mission-critical uses, and they need to be individually enabled with the “–experimental-features” configuration option. See Enabling Experimental Features for details.

In this release, the following DynamoDB API features are considered experimental:

  • The DynamoDB Streams API for capturing change is supported, but still considered experimental so needs to be enabled explicitly with the --experimental-features=alternator-streams configuration option.

    Alternator streams also differ in some respects from DynamoDB Streams:

    • The number of separate “shards” in Alternator’s streams is significantly larger than is typical on DynamoDB. https://github.com/scylladb/scylla/issues/13080

    • While in DynamoDB data usually appears in the stream less than a second after it was written, in Alternator Streams there is currently a 10 second delay by default. https://github.com/scylladb/scylla/issues/6929

    • Some events are represented differently in Alternator Streams. For example, a single PutItem is represented by a REMOVE + MODIFY event, instead of just a single MODIFY or INSERT. https://github.com/scylladb/scylla/issues/6930 https://github.com/scylladb/scylla/issues/6918

Unimplemented API features¶

In general, every DynamoDB API feature available in Amazon DynamoDB should behave the same in Alternator. However, there are a few features which we have not implemented yet. Unimplemented features return an error when used, so they should be easy to detect. Here is a list of these unimplemented features:

  • Currently in Alternator, a GSI (Global Secondary Index) can only be added to a table at table creation time. DynamoDB allows adding a GSI (but not an LSI) to an existing table using an UpdateTable operation, and similarly it allows removing a GSI from a table. https://github.com/scylladb/scylla/issues/11567

  • GSI (Global Secondary Index) and LSI (Local Secondary Index) may be configured to project only a subset of the base-table attributes to the index. This option is not yet respected by Alternator - all attributes are projected. This wastes some disk space when it is not needed. https://github.com/scylladb/scylla/issues/5036

  • DynamoDB’s multi-item transaction feature (TransactWriteItems, TransactGetItems) is not supported. Note that the older single-item conditional updates feature are fully supported. This feature was added to DynamoDB in November 2018. https://github.com/scylladb/scylla/issues/5064

  • Alternator does not yet support the DynamoDB API calls that control which table is available in which data center (DC): CreateGlobalTable, UpdateGlobalTable, DescribeGlobalTable, ListGlobalTables, UpdateGlobalTableSettings, DescribeGlobalTableSettings, and UpdateTable. Currently, all Alternator tables are created as global tables and can be accessed from all the DCs existing at the time of the table’s creation. If a DC is added after a table is created, the table won’t be visible from the new DC and changing that requires a CQL “ALTER TABLE” statement to modify the table’s replication strategy. https://github.com/scylladb/scylla/issues/5062

  • Recently DynamoDB added support, in addition to the DynamoDB Streams API, also for the similar Kinesis Streams. Alternator doesn’t support this yet, and the related operations DescribeKinesisStreamingDestination, DisableKinesisStreamingDestination, and EnableKinesisStreamingDestination. This feature was added to DynamoDB in November 2020. https://github.com/scylladb/scylla/issues/8786

  • The on-demand backup APIs are not supported: CreateBackup, DescribeBackup, DeleteBackup, ListBackups, RestoreTableFromBackup. For now, users can use Scylla’s existing backup solutions such as snapshots or Scylla Manager. https://github.com/scylladb/scylla/issues/5063

  • Continuous backup (the ability to restore any point in time) is also not supported: UpdateContinuousBackups, DescribeContinuousBackups, RestoreTableToPointInTime

  • DynamoDB’s encryption-at-rest settings are not supported. The Encryption- at-rest feature is available in Scylla Enterprise, but needs to be enabled and configured separately, not through the DynamoDB API.

  • No support for throughput accounting or capping. As mentioned above, the BillingMode option is ignored by Alternator, and if a provisioned throughput is specified, it is ignored. Requests which are asked to return the amount of provisioned throughput used by the request do not return it in Alternator. https://github.com/scylladb/scylla/issues/5068

  • DAX (DynamoDB Accelerator), an in-memory cache for DynamoDB, is not available in for Alternator. Anyway, it should not be necessary - Scylla’s internal cache is already rather advanced and there is no need to place another cache in front of the it. We wrote more about this here: https://www.scylladb.com/2017/07/31/database-caches-not-good/

  • The DescribeTable is missing information about creation data and size estimates, and also part of the information about indexes enabled on the table. https://github.com/scylladb/scylla/issues/5013 https://github.com/scylladb/scylla/issues/5320 https://github.com/scylladb/scylla/issues/7550 https://github.com/scylladb/scylla/issues/7551

  • The PartiQL syntax (SQL-like SELECT/UPDATE/INSERT/DELETE expressions) and the operations ExecuteStatement, BatchExecuteStatement and ExecuteTransaction are not yet supported. A user that is interested in an SQL-like syntax can consider using Scylla’s CQL protocol instead. This feature was added to DynamoDB in November 2020. https://github.com/scylladb/scylla/issues/8787

  • As mentioned above, Alternator has its own powerful monitoring framework, which is different from AWS’s. In particular, the operations DescribeContributorInsights, ListContributorInsights and UpdateContributorInsights that configure Amazon’s “CloudWatch Contributor Insights” are not yet supported. Scylla has different ways to retrieve the same information, such as which items were accessed most often. https://github.com/scylladb/scylla/issues/8788

  • Alternator does not support the DynamoDB feature “export to S3”, and its operations DescribeExport, ExportTableToPointInTime, ListExports. This feature was added to DynamoDB in November 2020. https://github.com/scylladb/scylla/issues/8789

  • Alternator does not support the DynamoDB feature “import from S3”, and its operations ImportTable, DescribeImport, ListImports. This feature was added to DynamoDB in August 2022. https://github.com/scylladb/scylla/issues/11739

  • Alternator does not support the TableClass table option choosing between several storage options with different cost/performance characteristics. All Alternator tables are stored the same way. This table option was added to DynamoDB in December 2021. https://github.com/scylladb/scylla/issues/10431

  • Alternator does not support the table option DeletionProtectionEnabled that can be used to forbid table deletion. This table option was added to DynamoDB in March 2023. https://github.com/scylladb/scylla/issues/14482

Was this page helpful?

PREVIOUS
Getting Started With ScyllaDB Alternator
NEXT
Features
  • Create an issue
  • Edit this page

On this page

  • ScyllaDB Alternator for DynamoDB users
    • Provisioning
    • Scan ordering
    • Load balancing
    • Write isolation policies
    • Avoiding write reordering
    • Authentication and Authorization
    • Metrics
    • Time To Live (TTL)
    • Experimental API features
    • Unimplemented API features
ScyllaDB Open Source
  • 6.2
    • master
    • 6.2
    • 6.1
    • 6.0
    • 5.4
    • 5.2
    • 5.1
  • Getting Started
    • Install ScyllaDB
      • Launch ScyllaDB on AWS
      • Launch ScyllaDB on GCP
      • Launch ScyllaDB on Azure
      • ScyllaDB Web Installer for Linux
      • Install ScyllaDB Linux Packages
      • Install scylla-jmx Package
      • Run ScyllaDB in Docker
      • Install ScyllaDB Without root Privileges
      • Air-gapped Server Installation
      • ScyllaDB Housekeeping and how to disable it
      • ScyllaDB Developer Mode
    • Configure ScyllaDB
    • ScyllaDB Configuration Reference
    • ScyllaDB Requirements
      • System Requirements
      • OS Support by Linux Distributions and Version
      • Cloud Instance Recommendations
      • ScyllaDB in a Shared Environment
    • Migrate to ScyllaDB
      • Migration Process from Cassandra to ScyllaDB
      • ScyllaDB and Apache Cassandra Compatibility
      • Migration Tools Overview
    • Integration Solutions
      • Integrate ScyllaDB with Spark
      • Integrate ScyllaDB with KairosDB
      • Integrate ScyllaDB with Presto
      • Integrate ScyllaDB with Elasticsearch
      • Integrate ScyllaDB with Kubernetes
      • Integrate ScyllaDB with the JanusGraph Graph Data System
      • Integrate ScyllaDB with DataDog
      • Integrate ScyllaDB with Kafka
      • Integrate ScyllaDB with IOTA Chronicle
      • Integrate ScyllaDB with Spring
      • Shard-Aware Kafka Connector for ScyllaDB
      • Install ScyllaDB with Ansible
      • Integrate ScyllaDB with Databricks
      • Integrate ScyllaDB with Jaeger Server
      • Integrate ScyllaDB with MindsDB
    • Tutorials
  • ScyllaDB for Administrators
    • Administration Guide
    • Procedures
      • Cluster Management
      • Backup & Restore
      • Change Configuration
      • Maintenance
      • Best Practices
      • Benchmarking ScyllaDB
      • Migrate from Cassandra to ScyllaDB
      • Disable Housekeeping
    • Security
      • ScyllaDB Security Checklist
      • Enable Authentication
      • Enable and Disable Authentication Without Downtime
      • Creating a Custom Superuser
      • Generate a cqlshrc File
      • Reset Authenticator Password
      • Enable Authorization
      • Grant Authorization CQL Reference
      • Certificate-based Authentication
      • Role Based Access Control (RBAC)
      • Encryption: Data in Transit Client to Node
      • Encryption: Data in Transit Node to Node
      • Generating a self-signed Certificate Chain Using openssl
      • Configure SaslauthdAuthenticator
    • Admin Tools
      • Nodetool Reference
      • CQLSh
      • Admin REST API
      • Tracing
      • ScyllaDB SStable
      • ScyllaDB Types
      • SSTableLoader
      • cassandra-stress
      • SSTabledump
      • SSTableMetadata
      • ScyllaDB Logs
      • Seastar Perftune
      • Virtual Tables
      • Reading mutation fragments
      • Maintenance socket
      • Maintenance mode
      • Task manager
    • ScyllaDB Monitoring Stack
    • ScyllaDB Operator
    • ScyllaDB Manager
    • Upgrade Procedures
      • ScyllaDB Versioning
      • ScyllaDB Open Source Upgrade
      • ScyllaDB Open Source to ScyllaDB Enterprise Upgrade
      • ScyllaDB Image
      • ScyllaDB Enterprise
    • System Configuration
      • System Configuration Guide
      • scylla.yaml
      • ScyllaDB Snitches
    • Benchmarking ScyllaDB
    • ScyllaDB Diagnostic Tools
  • ScyllaDB for Developers
    • Develop with ScyllaDB
    • Tutorials and Example Projects
    • Learn to Use ScyllaDB
    • ScyllaDB Alternator
    • ScyllaDB Drivers
      • ScyllaDB CQL Drivers
      • ScyllaDB DynamoDB Drivers
  • CQL Reference
    • CQLSh: the CQL shell
    • Appendices
    • Compaction
    • Consistency Levels
    • Consistency Level Calculator
    • Data Definition
    • Data Manipulation
      • SELECT
      • INSERT
      • UPDATE
      • DELETE
      • BATCH
    • Data Types
    • Definitions
    • Global Secondary Indexes
    • Expiring Data with Time to Live (TTL)
    • Functions
    • Wasm support for user-defined functions
    • JSON Support
    • Materialized Views
    • Non-Reserved CQL Keywords
    • Reserved CQL Keywords
    • Service Levels
    • ScyllaDB CQL Extensions
  • Alternator: DynamoDB API in Scylla
    • Getting Started With ScyllaDB Alternator
    • ScyllaDB Alternator for DynamoDB users
  • Features
    • Lightweight Transactions
    • Global Secondary Indexes
    • Local Secondary Indexes
    • Materialized Views
    • Counters
    • Change Data Capture
      • CDC Overview
      • The CDC Log Table
      • Basic operations in CDC
      • CDC Streams
      • CDC Stream Generations
      • Querying CDC Streams
      • Advanced column types
      • Preimages and postimages
      • Data Consistency in CDC
    • Workload Attributes
  • ScyllaDB Architecture
    • Data Distribution with Tablets
    • ScyllaDB Ring Architecture
    • ScyllaDB Fault Tolerance
    • Consistency Level Console Demo
    • ScyllaDB Anti-Entropy
      • ScyllaDB Hinted Handoff
      • ScyllaDB Read Repair
      • ScyllaDB Repair
    • SSTable
      • ScyllaDB SSTable - 2.x
      • ScyllaDB SSTable - 3.x
    • Compaction Strategies
    • Raft Consensus Algorithm in ScyllaDB
    • Zero-token Nodes
  • Troubleshooting ScyllaDB
    • Errors and Support
      • Report a ScyllaDB problem
      • Error Messages
      • Change Log Level
    • ScyllaDB Startup
      • Ownership Problems
      • ScyllaDB will not Start
      • ScyllaDB Python Script broken
    • Upgrade
      • Inaccessible configuration files after ScyllaDB upgrade
    • Cluster and Node
      • Handling Node Failures
      • Failure to Add, Remove, or Replace a Node
      • Failed Decommission Problem
      • Cluster Timeouts
      • Node Joined With No Data
      • NullPointerException
      • Failed Schema Sync
    • Data Modeling
      • ScyllaDB Large Partitions Table
      • ScyllaDB Large Rows and Cells Table
      • Large Partitions Hunting
      • Failure to Update the Schema
    • Data Storage and SSTables
      • Space Utilization Increasing
      • Disk Space is not Reclaimed
      • SSTable Corruption Problem
      • Pointless Compactions
      • Limiting Compaction
    • CQL
      • Time Range Query Fails
      • COPY FROM Fails
      • CQL Connection Table
    • ScyllaDB Monitor and Manager
      • Manager and Monitoring integration
      • Manager lists healthy nodes as down
    • Installation and Removal
      • Removing ScyllaDB on Ubuntu breaks system packages
  • Knowledge Base
    • Upgrading from experimental CDC
    • Compaction
    • Consistency in ScyllaDB
    • Counting all rows in a table is slow
    • CQL Query Does Not Display Entire Result Set
    • When CQLSh query returns partial results with followed by “More”
    • Run ScyllaDB and supporting services as a custom user:group
    • Customizing CPUSET
    • Decoding Stack Traces
    • Snapshots and Disk Utilization
    • DPDK mode
    • Debug your database with Flame Graphs
    • How to Change gc_grace_seconds for a Table
    • Gossip in ScyllaDB
    • Increase Permission Cache to Avoid Non-paged Queries
    • How does ScyllaDB LWT Differ from Apache Cassandra ?
    • Map CPUs to ScyllaDB Shards
    • ScyllaDB Memory Usage
    • NTP Configuration for ScyllaDB
    • Updating the Mode in perftune.yaml After a ScyllaDB Upgrade
    • POSIX networking for ScyllaDB
    • ScyllaDB consistency quiz for administrators
    • Recreate RAID devices
    • How to Safely Increase the Replication Factor
    • ScyllaDB and Spark integration
    • Increase ScyllaDB resource limits over systemd
    • ScyllaDB Seed Nodes
    • How to Set up a Swap Space
    • ScyllaDB Snapshots
    • ScyllaDB payload sent duplicated static columns
    • Stopping a local repair
    • System Limits
    • How to flush old tombstones from a table
    • Time to Live (TTL) and Compaction
    • ScyllaDB Nodes are Unresponsive
    • Update a Primary Key
    • Using the perf utility with ScyllaDB
    • Configure ScyllaDB Networking with Multiple NIC/IP Combinations
  • Reference
    • AWS Images
    • Azure Images
    • GCP Images
    • Configuration Parameters
    • Glossary
    • Limits
    • API Reference (BETA)
    • Metrics (BETA)
  • ScyllaDB FAQ
  • Contribute to ScyllaDB
Docs Tutorials University Contact Us About Us
© 2025, ScyllaDB. All rights reserved. | Terms of Service | Privacy Policy | ScyllaDB, and ScyllaDB Cloud, are registered trademarks of ScyllaDB, Inc.
Last updated on 08 May 2025.
Powered by Sphinx 7.4.7 & ScyllaDB Theme 1.8.6