“Why not just Zstd?”
Short: Zstd-only can be smaller, but it isn’t searchable; you still pay I/O + CPU to decompress and parse JSON. SEE trades a bit of size for millisecond lookups and ~99% skipping, which often wins on TCO at scale.
“Will it hold on real data?”
Short: Best on repetitive JSON/NDJSON (logs, events, telemetry). We provide a 10-minute demo so anyone can reproduce KPIs and stress it with their own patterns.
“Why not keep a separate index?”
Short: Separate indexes add I/O/space and consistency overhead. SEE keeps searchability in the storage format, reducing random I/O and parse costs.
“Are the numbers cherry-picked?”
Short: We publish p50/p95/p99, skip (present/absent), and bloom density. The demo script prints them all, along with raw and combined sizes.
“Why not just Zstd?” Short: Zstd-only can be smaller, but it isn’t searchable; you still pay I/O + CPU to decompress and parse JSON. SEE trades a bit of size for millisecond lookups and ~99% skipping, which often wins on TCO at scale.
“Will it hold on real data?” Short: Best on repetitive JSON/NDJSON (logs, events, telemetry). We provide a 10-minute demo so anyone can reproduce KPIs and stress it with their own patterns.
“Why not keep a separate index?” Short: Separate indexes add I/O/space and consistency overhead. SEE keeps searchability in the storage format, reducing random I/O and parse costs.
“Are the numbers cherry-picked?” Short: We publish p50/p95/p99, skip (present/absent), and bloom density. The demo script prints them all, along with raw and combined sizes.