RisingWave is built around streaming SQL and materialized views. A replacement should be judged on what happens as data changes, not only whether an initial SELECT runs. See the RisingWave documentation and the alternatives index.
A meaningful trial
- Ingest a small event stream containing duplicates, late arrivals, and updates.
- Maintain the same aggregate in RisingWave and the candidate. Compare outputs after each event, not just at the end.
- Measure source-to-result delay while writing, reading, and recovering from a restart.
- Change a view definition and document whether downstream consumers need a rebuild or cutover.
- Test the connectors, backfill process, operational access, and cost at the expected event rate.
Write down the exact consistency and freshness your product needs. If the candidate only answers a batch query after a delay, it may still be appropriate—but it is a different architecture.
Akousa