Skip to content

Why HestiaStore

Use this section to decide whether HestiaStore matches your workload before you commit to integration or tuning work.

Choose HestiaStore when you need

  • an embeddable Java library instead of a separate database service
  • large local datasets with bounded-memory point lookups
  • ordered iteration and bounded range scans over persisted keys
  • operationally simple storage in a single directory
  • optional WAL-based crash recovery without adding a separate coordinator
  • strict UTF-8 descriptors for emoji or multilingual keys and values

Reconsider if you need

  • distributed replication and failover
  • SQL, joins, and relational query planning
  • multi-key transactional semantics
  • a storage engine optimized primarily for ultra-low-latency in-memory access
  • a drop-in replacement for high-write native LSM engines without validating your workload first

Decision checklist

  • Workload shape: mostly point reads, scans, ingestion bursts, or mixed traffic
  • Query shape: full ordered iteration, bounded ranges, or mostly point lookups
  • Durability: flush/close boundaries only, or WAL-backed recovery as well
  • Operations: backup windows, recovery expectations, and monitoring maturity
  • Footprint: local disk budget, cache budget, and acceptable compaction work
  • Platform: Java version, container or host filesystem constraints, and whether native dependencies are acceptable