Before you start: migrate from Hazelcast to KiviDB

List the structures in use, and for each one its size, the types of its keys and values, and how values are serialized:

What you have

List the structures in use, and for each one its size, the types of its keys and values, and how values are serialized:

  • Management Center shows every map, queue and topic with its entry count and memory, if you run it.
  • From a client, hz.getDistributedObjects() lists every structure that exists, with its service name (hz:impl:mapService, hz:impl:queueService, ...).
  • map.getLocalMapStats() on a member gives the owned entry count and memory for that member.

Then check which features your code relies on: TTL and max-idle, eviction, entry listeners, entry processors, predicates or SQL, near cache, MapStore, locks and atomics, and whether members are embedded in your application.

Edition and version

Which Hazelcast you run decides what there is to move:

  • The CP subsystem (FencedLock, IAtomicLong, IAtomicReference, ISemaphore, ICountDownLatch, CPMap) is an Enterprise feature since Hazelcast 5.5. On Community Edition 5.5 and later, using one fails with CP subsystem is an Enterprise feature. If you use these, you are on Enterprise or on 5.4 or older.
  • Persistence (formerly Hot Restart), which keeps map data on disk across a cluster restart, is Enterprise-only. Without it a Hazelcast cluster holds nothing that survives a full restart: everything you copy must be read from the running cluster.

Which KiviDB build

You useKiviDB build
Maps, queues, topics, counters, locks as shown herethe default build
TLS between clients and KiviDBtls or full
Lua scripts (to replace an entry processor with one server-side step)lua or full

On KiviDB Cloud, TLS is always available and Lua is a switch chosen when the database is created. Search (FT.*) and JSON are built into every build.

Sizing

Hazelcast's memory numbers include backups (one backup copy by default) and the JVM's overhead. A useful starting point is the entry count times the size of one entry as you will store it in KiviDB. Copy a sample of 10,000 entries with the program below, then read INFO memory (used_memory) on KiviDB and scale up.