For a long time, Kafka has been the default answer to event ingestion.
Need streaming data? Kafka.
Need durability and ordering? Kafka.
Need to move events into analytics systems? Kafka again.
Kafka is a powerful system, and for many workloads it is absolutely the right choice. But over the past few years, more and more teams are using Kafka not because they need a message bus, but because it feels like the only viable way to get events into a streaming database or a lakehouse.
That assumption is worth questioning.
When Kafka Becomes an Extra Hop
Kafka is widely used and well understood. But in many ingestion setups, the actual requirement is much simpler than it first appears. What teams really need is simply buffering.
They need a short-lived buffer that absorbs bursts, decouples producers from the database, and writes data downstream at a controlled pace. Once data is safely persisted and processed, there is usually little reason to look back.
Kafka can provide this, but it also brings a full distributed log system. Concepts like partitions, replication, consumer groups, and replay from arbitrary offsets are fundamental to Kafka’s design. These abstractions matter in large, shared streaming platforms, but in many straightforward ingestion pipelines, they are never exercised.
In practice, most applications do not replay data from arbitrary offsets. They do not run multiple consumers with independent read positions. They do not treat Kafka as a long-term system of record. Events flow forward, are processed once, and become part of the analytical state in the downstream system.
When buffering is the only real requirement, Kafka is often far more system than necessary.
Running Kafka means operating a distributed infrastructure that must be sized, monitored, and tuned, even when the workload itself is simple. The cost is not just infrastructure, but also ongoing operational and cognitive overhead.
Streaming with RisingWave Events API
This is the motivation behind the RisingWave Events API, a new project we open sourced in GitHub: https://github.com/risingwavelabs/events-api
Instead of treating Kafka as a mandatory transport layer, the Events API allows applications to stream events directly into RisingWave over HTTP. If your application can make an HTTP request, it can ingest streaming data into RisingWave.
The Events API is a lightweight HTTP service that sits between your application and RisingWave. It focuses on reliable buffering and efficient ingestion, without introducing the operational and conceptual overhead of a full message bus.
Events are accepted as JSON payloads, buffered in memory, and written to RisingWave in batches. This allows the system to absorb traffic spikes while keeping write behavior predictable.
Because the Events API is tightly integrated with RisingWave, ingested data becomes available for streaming queries and materialized views immediately. There is no intermediate log to manage and no duplicated storage layer between the producer and the database.
What the Events API Provides
At a high level, the Events API offers a small set of focused capabilities:
HTTP-native ingestion via simple POST requests
Built-in buffering and batching to smooth bursts and improve throughput
Automatic schema mapping between JSON payloads and RisingWave tables
SQL execution over HTTP for managing tables and schemas
The Events API is not trying to replace Kafka in general. It is designed for ingestion paths where RisingWave is the destination and buffering is the primary requirement.
How This Works in Practice
Skipping Kafka does not mean giving up performance or reliability.
Incoming events are buffered and written to RisingWave asynchronously. Writes are batched to reduce overhead and improve throughput while keeping latency low.
By default, events are flushed every 500 ms or when the buffer reaches 5,000 rows. These defaults work well for most workloads and rarely need tuning.
Applications emit JSON. Databases require structured schemas. The Events API bridges this gap by inspecting the target table schema in RisingWave and mapping incoming fields automatically.
Because ingestion is HTTP-native, the Events API fits naturally into existing application architectures. There is no new protocol to learn and no new client library required.
A Simple Example
Assuming you already have a local RisingWave instance running, getting started with the Events API only takes a few lines of code:
curl -L https://go.risingwave.com/events-api | sh
EVENTS_API_RW_DSN='postgres://root:@localhost:4566/dev' ./events-api
Then You can create tables and ingest events directly over HTTP:
# Create a table
curl -X POST \\
-d 'CREATE TABLE clickstream (
user_id BIGINT,
session_id STRING,
page_url STRING,
event_type STRING,
timestamp TIMESTAMP
)' \\
http://localhost:8000/v1/sql
# Send an event
curl -X POST \\
-d '{"user_id": 12345, "session_id": "sess_abc123", "page_url": "/products/laptop", "event_type": "page_view", "timestamp": "2024-01-15 10:30:00"}' \\
'http://localhost:8000/v1/events?name=clickstream'
From there, the data is immediately available for streaming queries and materialized views in RisingWave.
Where the Events API Fits Best
The Events API works best when:
RisingWave is the primary system ingesting and analyzing the data
Events originate from HTTP-native applications or services
Infrastructure and operational overhead matter
Fast iteration matters more than complex fan-out
Kafka remains the right choice when you need a shared event backbone, long-term retention, or multiple independent consumers. The Events API is meant for the many cases where Kafka is more than you need.
Kafka When You Need It, Not by Default
Kafka remains a core part of many streaming architectures, and RisingWave integrates well with it. But Kafka should be a deliberate choice, not a default assumption.
When the goal is simply to stream events into RisingWave and start analyzing them with SQL, introducing a full distributed log system adds unnecessary complexity.
The RisingWave Events API offers a simpler path.
Get Started
The RisingWave Events API is open source and available today.
Explore the project on GitHub: https://github.com/risingwavelabs/events-api
If you want to stream events into RisingWave without introducing Kafka, this is the simplest place to start.
