What should we prioritize next: HBase + Kafka docs or SlateDB + S2 backend?

[em3s]

We're deciding where to focus next and want your input.

Option A: HBase + Kafka production guides

HBase + Kafka is what Actionbase runs on today at Kakao. The code is already there—it just needs documentation:

Infrastructure:

• Actionbase nodes
• HBase cluster
• Kafka cluster

Documentation needed:

• Configuration reference
• Operations and monitoring guide
• Zero-downtime migration guide

This helps if you're planning to run Actionbase at scale with HBase + Kafka.

Option B: SlateDB + S2 backend (lightweight deployment)

Run Actionbase without HBase and Kafka.

Just:

• Actionbase nodes
• S3 (or compatible object storage)

SlateDB for storage, S2 for streaming—both built on object storage.

This is new development, not just documentation:

• Rust-to-JVM bindings (SlateDB and S2 are written in Rust)
• Different trade-offs (simpler infrastructure)
• More work, but potentially more accessible

Why we're asking

We have limited bandwidth. HBase + Kafka guides help production users now, but SlateDB + S2 could make Actionbase usable for a much wider audience.

If no one plans to run HBase, writing those guides isn't valuable. If everyone wants lighter deployment, SlateDB + S2 should come first.

Vote below. Comments welcome—especially if your use case doesn't fit either option.

[em3s]

I did some research.

There's an attempt at SlateDB Java bindings at https://github.com/pditommaso/slatedb-java, with slatedb/slatedb#894 still in draft. It uses Java 24 FFI (Panama). S2 has a pure Java SDK available: https://github.com/s2-streamstore/s2-sdk-java

The "Rust-to-JVM binding work required" barrier may be lower than expected—or it may not, depending on how the Java bindings effort plays out. Production readiness is another story entirely.

(Left a comment: slatedb/slatedb#894 (comment))