Lindorm is a cloud-native multi-model database that consolidates wide tables, time series, search, and file storage into a single service. It is API-compatible with Apache HBase, Apache Cassandra, OpenTSDB, Apache Solr, and Hadoop Distributed File System (HDFS), so you can migrate existing workloads without rewriting application code.
This topic compares Lindorm with the open source databases it replaces.
Lindorm vs. Apache HBase and Apache Cassandra
LindormTable is the wide table engine for semi-structured and structured data. It supports the HBase API, Cassandra Query Language (CQL), Phoenix SQL, and standard Java Database Connectivity (JDBC) — all on the same dataset. Data written through the HBase API is immediately queryable via CQL, with no synchronization required.
| Feature | Lindorm | Apache HBase | Apache Cassandra | |
|---|---|---|---|---|
Core features | Data models | Wide tables, time series, search, and files in one service | Wide tables only | Wide tables only |
| APIs | HBase API, CQL, and Phoenix SQL with cross-protocol data interoperability | HBase API and Phoenix SQL | CQL only | |
| SQL | Standard JDBC; Phoenix SQL built in with higher stability and performance than open source Phoenix | Requires external Phoenix component | Simple SQL dialect only | |
| Data types | Multiple data types. See Data types. | BYTE[] only | Multiple data types | |
| Time-to-live (TTL) | Table, column, and cell granularity | Table and cell granularity | Table granularity only | |
| Consistency | Strong consistency and eventual consistency | Strong consistency | Strong consistency | |
| Global secondary indexes | Built-in; no external components required | Requires external components; complex configuration | Supported | |
| Full-text search and multi-dimensional queries | Built-in via LindormSearch integration. See Overview. | Not supported | Not supported | |
Performance | Throughput | 7x that of open source Apache HBase. See Analyze benchmark results. | Baseline | No data available |
| P99 latency | 1/10 of open source Apache HBase. See Analyze benchmark results. | High tail latency | High tail latency | |
Cost | Storage cost | Up to 80% lower than self-managed cloud disks; storage specifications include Performance, Standard, and Capacity | Self-managed cloud or local disks; no elastic scaling | Self-managed cloud or local disks; no elastic scaling |
| Compute-storage separation | Supported; scale storage and compute independently | Not supported | Not supported | |
| Data compression | Built-in optimized algorithm; compression ratio exceeds 10:1, more than 50% higher than Snappy | Snappy, LZ4, and LZO; lower compression ratio | Snappy and LZ4; lower compression ratio | |
| Adaptive encoding | Supported; enables fast queries without decoding | DIFF encoding; moderate compression, encoded data not retrievable | Not supported | |
| Hot and cold data separation | Automatic tiered storage; reduces storage cost by 80% and improves hot data query performance by 15%. See Overview. | Not supported | Not supported | |
Extensibility and elasticity | Minimum nodes |
Not applicable. |
At least 3 nodes | At least 3 nodes |
| Scalability | Scales to thousands of nodes | Scales to thousands of nodes | Approximately 100 nodes before performance bottleneck | |
Reliability | Active-active redundancy | Supported; includes automatic failover and dual-cluster deployment. Deploy Lindorm alongside a self-managed HBase or Cassandra instance in primary/secondary mode. | No failover support | Supported, but requires three replicas |
| Multi-data-center strong consistency | Supported; enables data center-level disaster recovery | Not supported | Not supported | |
| Backup and restoration | Backs up more than 100 TB to Object Storage Service (OSS); recovery time objective (RTO) less than 30 minutes; supports on-demand backup and point-in-time restoration. See Enable data backup and restoration. | Limited support | Limited support | |
| Active geo-redundancy | Supported; deploy across regions and units with configurable data synchronization | Not supported | Moderate support | |
Multi-tenancy and security | Authentication and access control lists (ACLs) | Username/password authentication and ACLs | Not supported | Supported |
| Resource isolation | Physical resource isolation between tenants via resource groups | Not supported | Not supported | |
| Quota management | Global request and storage quotas per tenant | No multitenancy support | Not supported | |
| Encryption at rest | Supported via Key Management Service (KMS); encrypts all data and logs | Limited support | Not supported | |
| Remote procedure call (RPC) blacklist | Supported; rate-limit specific RPC calls | Not supported | Not supported | |
| Auditing | Not supported | Not supported | Not supported | |
Advanced features | Table recycle bin | Deleted tables move to recycle bin for recovery | Not supported | Not supported |
| Cascading splitting | Regions split continuously without waiting for compaction | Not supported | Not supported | |
| Discrete TTL | Retain data across multiple time ranges in a single table | Not supported | Not supported | |
O&M and diagnostics | Operations and maintenance (O&M) tools | GUI-based cluster management for tables, namespaces, resource groups, and ACLs. See Log on to the cluster management system. | HBase Shell only | CLI tools only; no GUI |
| SQL-based data queries | Run SQL queries in a graphical interface. See Data Query. Also supports HBase Shell and cqlsh. | HBase Shell only | cqlsh only | |
Ecosystem | Data migration | Online, cross-version, automated migration from any HBase or Cassandra version; no application code changes required. See Overview. | Offline migration only | Offline migration only |
| MySQL data synchronization | Full and incremental sync from MySQL via Lindorm Tunnel Service (LTS). See Overview. | No dedicated tools; no online incremental sync | No dedicated tools; no online incremental sync | |
| Apache Spark integration | Deep integration: incremental sync, Spark SQL analysis, and result write-back to Lindorm | Manual integration requiring significant development effort | Manual integration requiring significant development effort | |
| MaxCompute integration | Incremental data archiving from Lindorm to MaxCompute | Manual integration requiring significant development effort | Manual integration requiring significant development effort | |
| Simple Log Service (SLS) integration | Subscribe to real-time data from SLS and import to Lindorm. See Overview. | Manual integration requiring significant development effort | Manual integration requiring significant development effort | |
Service capabilities | SLA | 99.9% for single-cluster deployment; 99.99% for dual-cluster deployment | No SLA provided | No SLA provided |
| O&M costs | Fully managed; no database administration required | High O&M costs | High O&M costs | |
| Technical support | Expert team including Apache Project Management Committee (PMC) members and committers | No dedicated support | No dedicated support | |
| Production track record | Tens of thousands of instances supporting Alibaba Group workloads across nine Tmall Double 11 Shopping Festivals | None | None | |
Lindorm vs. OpenTSDB
LindormTSDB is a high-performance, fully managed time series engine compatible with OpenTSDB protocols. It uses Alibaba Cloud-developed indexing, data models, and streaming aggregation to provide capabilities that OpenTSDB requires you to build yourself on top of HBase.
| Feature | LindormTSDB | OpenTSDB | |
|---|---|---|---|
O&M and management | Service availability | 99.9% | Self-managed; you must provision and configure clusters with all dependencies to achieve availability |
| Data reliability | 99.9999% | Self-managed; reliability depends on your HBase and infrastructure configuration | |
| Infrastructure cost | No hardware or software to deploy; billed by actual usage | Requires dedicated database servers | |
| Maintenance | Fully managed | Requires dedicated database administrators (DBAs) | |
| Deployment and scaling | Instant activation; elastic scaling | Requires hardware procurement, data center hosting, and manual machine deployment | |
| Dependency management | O&M-free | Requires managing AsyncHBase, HBase, and related dependencies | |
| Parameter tuning | Pre-configured based on best practices | Requires manual configuration of salt values, connection counts, flush modes, and compaction settings | |
| Table creation | Managed automatically; transparent to users | Requires manual O&M for static table creation | |
| Monitoring and alerting | Built-in monitoring across all processes | Requires third-party tools | |
Features | Data models | Multi-value and single-value | Single-value only |
| SDK | Java SDK | No SDK for queries | |
| Data types | Numeric, Boolean, and string | Numeric only | |
| SQL queries | Supported | Not supported | |
| Chinese character support | Letters and Chinese characters | Letters only | |
| Tags parameter | Optional | Required | |
| Maximum tag keys | 16 | 8 | |
| Ecosystem integration | Seamless integration with Apache Flink and IoT Platform | Limited; no native integration with Alibaba Cloud services | |
| Data compression | Dedicated time series compression algorithm; high compression ratio | General-purpose compression algorithms; lower compression ratio | |
Stability | Read/write isolation | Separate thread pools for reads and writes; stable performance under mixed workloads | Coupled read and write paths; connection exhaustion can cause failures |
| Aggregation | Streaming aggregation with fine-grained memory management | In-memory aggregation; risk of OutOfMemory exceptions | |
Lindorm vs. Elasticsearch and Apache Solr
LindormSearch is a distributed search engine compatible with the standard Apache Solr API. It integrates with LindormTable and LindormTSDB to provide unified storage and retrieval across multiple data models in a single service.
| Feature | LindormSearch | Open source Elasticsearch | Apache Solr | |
|---|---|---|---|---|
Core features | Data models | Wide tables, time series, search, and files; seamlessly stores indexes from other Lindorm engines | Search only | Search only |
| APIs | CQL, Phoenix SQL, and the Solr API | Elasticsearch API | Solr API | |
| TTL | Table and column granularity | Table granularity only | Table granularity only | |
| Unified storage and retrieval | Integrated with LindormTable and LindormTSDB for cross-model queries | Not supported | Not supported | |
Performance and cost | Throughput | 130%–200% that of Apache Solr | No data available | Baseline |
| Storage cost | Up to 80% lower than self-managed cloud disks; storage specifications include Performance, Standard, and Capacity | Self-managed cloud or local disks; no elastic scaling | Self-managed cloud or local disks; no elastic scaling | |
| Compute-storage separation | Supported; scale storage and compute independently | Not supported | Not supported | |
| Data compression | Built-in optimized algorithm; compression ratio exceeds 10:1, more than 50% higher than Snappy | Not supported | Not supported | |
| Hot and cold data separation | Automatic time-based sharding; cost-effective media for cold data | Not supported | Not supported | |
Elasticity | Storage scalability | High; decouple storage from compute and scale up or out with a few clicks; storage scales in seconds, compute in minutes | Low; data migration required before scale-out; scale-out takes hours | Low; data migration required before scale-out; scale-out takes hours |
| Read-only replicas | Each shard supports one primary and multiple read-only replicas; add replicas in seconds | Supported, but data migration required; takes hours | Supported, but data migration required; takes hours | |
Ecosystem | Data migration | Online, automated migration from Apache Solr or open source Elasticsearch; no application code changes required. See Overview. | Offline migration only | Offline migration only |
| MySQL data synchronization | Full and incremental sync from MySQL via LTS. See Overview. | No dedicated tools; no online incremental sync | No dedicated tools; no online incremental sync | |
| Apache Spark integration | Deep integration: Spark SQL analysis, incremental sync, and result write-back to Lindorm | Manual integration requiring significant development effort | Manual integration requiring significant development effort | |
| MaxCompute integration | Incremental data archiving from Lindorm to MaxCompute | Manual integration requiring significant development effort | Manual integration requiring significant development effort | |
| SLS integration | Subscribe to real-time data from SLS and import to Lindorm. See Overview. | Manual integration requiring significant development effort | Manual integration requiring significant development effort | |
Service capabilities | SLA | 99.9% for single-cluster deployment; 99.99% for dual-cluster deployment | No SLA provided | No SLA provided |
| O&M costs | Fully managed | No data available | No data available | |
| Technical support | Expert team including Apache PMC members and committers | No dedicated support | No dedicated support | |
| Production track record | Tens of thousands of instances supporting Alibaba Group workloads across nine Tmall Double 11 Shopping Festivals | None | None | |
Lindorm vs. HDFS
LindormDFS is a cloud-native file storage engine compatible with Hadoop Distributed File System (HDFS) protocols. It decouples storage from compute, enabling elastic scaling and tiered storage without the operational complexity of self-managed HDFS.
| Feature | LindormDFS | Open source HDFS | |
|---|---|---|---|
HDFS compatibility | HDFS protocol compatibility | Supported | Supported |
| Basic read/write APIs | Fully supported | Fully supported | |
| Advanced management APIs | Fully supported | Fully supported | |
Cost | Storage unit price (actual prices on the purchase page prevail) |
Starts at 0.019 USD/GB/month |
Starts at 0.023 USD/GB/month |
| Storage scaling | Smooth online scaling with no minimum step size | High minimum cost per scaling step; large step sizes | |
| Compute-storage separation | Supported; storage and compute scale independently | Not supported; storage and compute are co-deployed | |
| Hot and cold data separation | Automatic tiered storage; hot and cold data stored on different media | Not supported | |
Extensibility | Maximum nodes | No limit | 0–1,000 |
| Storage capacity | 0–1 EB | 0–10 PB | |
| Maximum files | Hundreds of billions | Tens of millions | |
| Ecosystem | Integrates with the Alibaba Cloud data ecosystem and open source big data ecosystems including Apache Hadoop and Apache Spark | Integrates with open source big data ecosystems including Apache Hadoop and Apache Spark | |
| Maintenance | O&M-free; simple to operate | Stateful service; requires complex maintenance | |