Managed NoSQL for data-intensive applications. Choose the right NoSQL database for your workload—from distributed operational data and industrial telemetry to low-latency application state—without operating the underlying database infrastructure yourself.
GeminiDB: Managed NoSQL
One service. Three NoSQL engines.
Choose the right NoSQL database for your workload
Data-intensive applications create different kinds of data with different access patterns. GeminiDB brings distributed operational data, time-series telemetry and low-latency application data onto one managed NoSQL foundation.
DISTRIBUTE
Cassandra API
Managed wide-column NoSQL for massive, write-intensive operational datasets that need horizontal scale.
MEASURE [NEW]
Influx API
Managed time-series NoSQL for telemetry, sensors, monitoring and high-volume timestamped data.
ACCESS [COMING SOON]
DynamoDB-compatible API
Managed key-value and document-style NoSQL for application state and predictable, low-latency access patterns.
Why managed NoSQL?
Scale the data. Not the operational burden.
Use familiar NoSQL interfaces and workload-specific data models while T Cloud Public manages the database foundation around them.
01
Workload fit
Choose wide-column, time-series or key-value/document access according to how your data is created and used.
02
Independent scaling
Decoupled compute and storage let resources adapt as workload requirements change.
03
Managed operations
Deployment, backup, restore, monitoring and alarms are integrated into the managed service.
04
Built for availability
Distributed architecture and multi-AZ deployment options support resilient workloads.
Built for data-intensive applications
From machine telemetry to application state
Modern industrial and connected applications generate more than one kind of data. GeminiDB lets each workload use the NoSQL model that matches how that data is written, queried and retained.
DISTRIBUTE
Events & histories
Capture large volumes of machine events, operational records and continuously growing datasets with GeminiDB Cassandra API.
MEASURE
Telemetry & sensors
Store timestamped temperature, vibration, pressure, energy and equipment measurements with GeminiDB Influx API.
ACCESS
Application & device state
Serve device metadata, configuration and application state through predictable key-value and document-style access patterns.
Engine deep dive
Three NoSQL engines. One managed foundation.
DISTRIBUTE – Cassandra API
Distributed NoSQL for write-intensive operational data
GeminiDB Cassandra API brings familiar Cassandra-style wide-column data access to a managed database service. It is designed for continuously growing datasets where distributed writes, horizontal scale and availability matter.
Best suited to
- Continuously generated operational data
- Large distributed datasets
- High write concurrency
- Horizontal scale
- CQL-oriented application patterns
Typical use cases
Typische Anwendungsfälle
Machine and production histories.
Customer situation: A factory operations team collects event logs from thousands of production machines.
The problem: Continuous writes produce a growing history that must be retrievable by equipment, plant and time.
How GeminiDB helps: Organize high-volume event records around well-designed partition keys and write them to GeminiDB Cassandra API.
Why this approach: Managed distributed storage and cluster operations reduce the need to run Cassandra infrastructure yourself.
Consideration: Not a substitute for an analytical warehouse; design partitions and retention for expected queries.
Large-scale device records.
Customer situation: A connected-equipment manufacturer manages records from devices deployed across customers and regions.
The problem: Each device sends updates, creating many concurrent writes and a large operational dataset.
How GeminiDB helps: Store device events and durable records using a Cassandra-style wide-column model with predictable key-based reads.
Why this approach: The managed cluster can expand as data and demand grow, with operational tooling included.
Consideration: For current device state and single-item lookups, also consider the DynamoDB-compatible API.
High-volume activity data.
Customer situation: A consumer platform collects clickstream and application activity from a large user base.
The problem: Bursty ingestion and long-running growth strain a single database server.
How GeminiDB helps: Use Cassandra API to ingest and retrieve activity records by known access keys.
Why this approach: Scale a distributed operational datastore without managing its node lifecycle.
Consideration: Personalization models and large analytical scans usually need separate processing systems.
Write-heavy long-lived datasets.
Customer situation: A logistics operator retains shipment events and operational changes for traceability.
The problem: Historical records must remain accessible while new events arrive continuously.
How GeminiDB helps: Use wide-column storage for append-heavy histories and efficient entity-based retrieval.
Why this approach: Compute and storage scaling help match infrastructure to growing records and traffic.
Consideration: Validate data retention, query patterns and backup requirements before selection.
Compatibility information
GeminiDB provides a Cassandra-compatible API rather than being the Apache Cassandra community distribution. Validate application and feature compatibility before migration.
MEASURE – Influx API
Managed time-series NoSQL for industrial telemetry [NEW]
GeminiDB Influx API is designed for timestamped data that never stops arriving: sensor measurements, equipment telemetry, monitoring metrics and historical operational data. It combines familiar Influx-style access with a managed, scalable database foundation.
Best suited to
- High-volume parallel ingestion
- Timestamped measurements
- Time-range queries and aggregation
- Historical operational analysis
- Managed scale and availability
Typical use cases
Continuous device measurements.
Customer situation: An energy operator collects temperature, pressure and voltage readings from distributed sensors.
The problem: Time-stamped measurements arrive continuously and need time-window analysis.
How GeminiDB helps: Ingest timestamped series via GeminiDB Influx API and query trends or aggregations over time.
Why this approach: Purpose-built time-series access with a managed cluster rather than a self-operated InfluxDB OSS 1.x node.
Consideration: Check supported InfluxDB 1.x query features and ingestion compatibility.
Machine and process metrics.
Customer situation: A plant engineer tracks cycle times, yield and line temperatures across shifts.
The problem: They need recent trends and historical comparisons to spot production deviations.
How GeminiDB helps: Record metrics as time series and aggregate by machine, line or period for monitoring dashboards.
Why this approach: Time-oriented storage and aggregation fit this pattern better than generic transactional tables.
Consideration: A BI platform may still be needed for complex enterprise reporting.
Operational time-series.
Customer situation: A maintenance team observes vibration, motor speed and energy use from industrial assets.
The problem: Measurements need to be monitored over time to identify drift and abnormal behavior.
How GeminiDB helps: Store and query measurements by timestamp and equipment identity to feed alerts and trend views.
Why this approach: Managed ingestion and retention-oriented design support expanding telemetry estates.
Consideration: Alerting workflows may also need external monitoring/application logic.
Historical data for tracing anomalies.
Customer situation: An engineer investigates an unexpected machine shutdown from last month.
The problem: The team must correlate sensor readings around the incident and compare earlier periods.
How GeminiDB helps: Use time-range queries and aggregations to reconstruct the sequence of measurements.
Why this approach: Keeping longer measurement histories becomes easier when storage can expand independently.
Consideration: Root-cause determination still requires domain logic and complementary event records.
ACCESS – DynamoDB-compatible API
Low-latency application data with a DynamoDB-compatible API [COMING SOON]
GeminiDB supports applications built around key-value and document-style access patterns and provides a path for DynamoDB-style application data on the T Cloud Public managed NoSQL foundation.
Best suited to
- Key-based application access
- Device and application state
- High concurrency
- Predictable access patterns
- DynamoDB-style migration scenarios
Typical use cases
Device identities, configurations and current status
Customer situation: A connected-product team maintains the latest status and configuration of each deployed device.
The problem: Applications need to look up one device quickly by its identifier.
How GeminiDB helps: Use the DynamoDB-compatible key-value/document access model for device state and metadata.
Why this approach: Predictable key-based access on a managed NoSQL foundation within T Cloud Public.
Consideration: This is not a time-series history store; use Influx API for measurements over time.
User preferences, profiles and application objects.
Customer situation: A SaaS application serves many active users and personal settings.
The problem: Each request needs fast retrieval or update of a small object by key.
How GeminiDB helps: Store application objects and retrieve them using supported DynamoDB-style API operations.
Why this approach: Keeps familiar SDK-oriented access patterns while running on GeminiDB.
Consideration: Check supported API operations and data-model constraints.
Shopping carts, product attributes and user-specific state.
Customer situation: An e-commerce platform must retrieve carts and customer context during busy campaigns.
The problem: Traffic can surge while most operations are keyed lookups or small object updates.
How GeminiDB helps: Model carts and user state for known key access and use GeminiDB DynamoDB-Compatible API.
Why this approach: A managed key-value option for application state alongside RDS for transactions.
Consideration: Payment, order integrity and multi-item transactions belong in a suitable transactional system.
Move supported DynamoDB-style application workloads.
Customer situation: A software provider is moving an application away from AWS infrastructure.
The problem: Rewriting every data-access call would increase migration effort.
How GeminiDB helps: Assess supported DynamoDB SDK/API calls, then migrate compatible key-value/document access patterns.
Why this approach: Potentially preserves much of the application access model outside AWS.
Consideration: Not complete DynamoDB feature parity: validate transactions, indexes and operational APIs.
Compatibility information
DynamoDB-compatible does not mean complete AWS DynamoDB feature parity. Application and API compatibility should be validated for migration scenarios.
T Cloud Public database portfolio
Use the database that matches the data pattern
GeminiDB complements—not replaces—the relational and in-memory services in the T Cloud Public database portfolio.
Managed relational
Transactions and structured business data across established relational engines.
In-memory
Cache and transient high-speed data access.
Distributed relational
Scale out relational workloads through distributed database middleware.
Cloud-native distributed relational
A distributed relational database option for demanding cloud-native workloads.
Managed NoSQL
High-volume specialized data models for data-intensive applications.
Built to scale differently
Your data grows. Your compute needs don't always follow.
In many node-based database deployments, adding storage means adding servers—with CPU and memory you may not need. GeminiDB separates database processing from distributed storage, so each can be expanded according to the actual workload.
Database compute
Compute nodes process reads, writes and queries. Increase processing capacity when more devices connect, traffic spikes or query demand rises—without treating every stored terabyte as a reason to add more compute.
Distributed storage
Shared storage holds growing datasets and retained history. Expand storage capacity when data accumulates, even if application traffic and processing requirements remain steady.
What changes for your business?
- Keep more history without buying unnecessary compute
An industrial plant can retain years of sensor measurements for traceability while keeping processing capacity aligned with actual query demand. - Respond to traffic growth without resizing the dataset
A connected application can add database processing capacity for more requests while its stored data volume changes little. - Spend less effort on infrastructure operations
Managed provisioning, monitoring, backups and recovery reduce routine database administration. You still control schema design, access patterns and capacity decisions.
WHY THE ARCHITECTURE MATTERS
Scale what you need. Not everything together.
With self-managed node-based Cassandra on ECS, adding nodes typically increases compute and storage together and requires cluster operations. GeminiDB's separated resources enable more targeted expansion and managed infrastructure operations. Other managed cloud databases may offer similar resource separation; the right comparison depends on the specific service and workload.
Das passende Modell finden
Passen Sie das Datenbankmodell an das Nutzungsverhalten Ihrer Daten an
Find the right model
Match the database model to the way your data is used
Cassandra API | Influx API [NEW] | DynamoDB-Compatible [COMING SOON] | |
Role | Distribute | Measure | Access |
Data model | Wide-column | Time series | Key-value / document |
Interface | Cassandra API / CQL | Influx API | DynamoDB-compatible API |
Best for | Massive, write-intensive operational data | Telemetry, sensors & time-series data | Application state & key-based access |
Industrial example | Machine events and histories | Measurements and telemetry | Device metadata and state |
New features
Learn more
Build for the way your data actually behaves
Explore GeminiDB APIs, estimate your configuration or review the technical documentation.