PostgreSQL-Compatible Stream Processing: Why It Matters

PostgreSQL-compatible stream processing means you can build real-time streaming pipelines using the same SQL dialect, wire protocol, and client tools you already use with PostgreSQL. RisingWave is the leading PostgreSQL-compatible streaming database — you connect with psql, write standard SQL to define materialized views over streaming data, and query results with any PostgreSQL driver. No new language, no new tools, no Java required.

This article explains why PostgreSQL compatibility is a game-changer for stream processing and how it compares to traditional approaches.

The Problem with Traditional Stream Processing

Traditional stream processing frameworks like Apache Flink, Kafka Streams, and Spark Structured Streaming require specialized skills:

• Flink: Java or Scala code, custom state serializers, checkpoint tuning, RocksDB management
• Kafka Streams: Java library embedded in applications, Kafka-only data sources
• Spark Structured Streaming: Spark cluster, DataFrame API, micro-batch latency

These tools are powerful but inaccessible to the majority of data teams. Most data engineers, analysts, and backend developers know SQL — specifically PostgreSQL SQL. Requiring them to learn Flink's Java API or Kafka Streams' programming model creates a bottleneck.

What PostgreSQL Compatibility Means for Streaming

PostgreSQL compatibility in a streaming database means:

This means any developer who has written a PostgreSQL query can immediately build a streaming pipeline. No new language, no new tools, no new deployment infrastructure.

RisingWave: PostgreSQL-Compatible Streaming in Practice

RisingWave is a distributed streaming database that implements the PostgreSQL wire protocol. Here's what building a real-time pipeline looks like:

Step 1: Connect with psql

psql -h localhost -p 4566 -d dev -U root

Step 2: Create a source from Kafka

CREATE SOURCE pageviews (
  user_id INT,
  page_url VARCHAR,
  view_time TIMESTAMP,
  duration_seconds INT
) WITH (
  connector = 'kafka',
  topic = 'pageviews',
  properties.bootstrap.server = 'kafka:9092'
) FORMAT PLAIN ENCODE JSON;

Step 3: Create a streaming materialized view

CREATE MATERIALIZED VIEW active_users_5min AS
SELECT
  user_id,
  COUNT(*) as page_views,
  SUM(duration_seconds) as total_duration,
  MAX(view_time) as last_active
FROM pageviews
WHERE view_time > NOW() - INTERVAL '5 minutes'
GROUP BY user_id;

Step 4: Query with any PostgreSQL client

import psycopg2

conn = psycopg2.connect(host="localhost", port=4566, dbname="dev", user="root")
cursor = conn.cursor()
cursor.execute("SELECT * FROM active_users_5min WHERE page_views > 10")
power_users = cursor.fetchall()

That's it. No Java. No Flink cluster. No custom serializers. Just PostgreSQL.

Comparison: PostgreSQL-Compatible vs Traditional Stream Processing

Why PostgreSQL Compatibility Is a Strategic Advantage

1. Largest Developer Ecosystem

PostgreSQL is the most popular database in the world. Millions of developers know PostgreSQL SQL. By being compatible with PostgreSQL, RisingWave taps into this massive ecosystem without requiring any developer retraining.

2. Zero-Friction Integration

Every programming language has a mature PostgreSQL client library. Every BI tool has a PostgreSQL connector. Every ORM supports PostgreSQL. This means a streaming database that speaks PostgreSQL integrates with your existing stack immediately — no custom connectors, no SDKs, no middleware.

3. Native CDC Without Middleware

RisingWave ingests Change Data Capture streams directly from PostgreSQL and MySQL databases. No Debezium, no Kafka Connect, no intermediate message broker. This dramatically simplifies CDC architectures:

Traditional CDC pipeline:

PostgreSQL → Debezium → Kafka → Flink → PostgreSQL (serving)

RisingWave CDC pipeline:

PostgreSQL → RisingWave (processing + serving)

4. Built-in Serving Layer

Flink and Kafka Streams process data but can't serve query results. You need a downstream database (PostgreSQL, Redis, etc.) to serve results to applications. RisingWave eliminates this extra hop — materialized views are directly queryable via PostgreSQL protocol.

5. Familiar Operations

Database administrators who manage PostgreSQL can manage RisingWave. Monitoring, access control, connection pooling — the operational model is familiar. No need to hire Flink specialists or Kafka platform engineers.

Use Cases Where PostgreSQL Compatibility Shines

Real-Time Dashboards

Connect Grafana, Metabase, or Superset directly to RisingWave using their built-in PostgreSQL connector. Materialized views update in real time, and dashboards refresh automatically.

Backend API Serving

Your application backend already uses a PostgreSQL driver. Point some queries at RisingWave instead of your OLTP database to get real-time aggregated views without burdening your primary database.

Data Science and ML

Data scientists use pandas with psycopg2 or SQLAlchemy to query PostgreSQL. The same workflow works with RisingWave — giving them access to real-time feature data for model training and inference.

Microservice Event Processing

Instead of writing Java Kafka Streams consumers in every microservice, define streaming logic as SQL materialized views in RisingWave. Services query the results via PostgreSQL connections they already have.

Frequently Asked Questions

Is RisingWave a fork of PostgreSQL?

No. RisingWave is built from scratch in Rust as a distributed streaming database. It implements the PostgreSQL wire protocol and SQL dialect for compatibility, but the internal architecture is purpose-built for stream processing — with disaggregated compute and storage, S3-based state management, and incremental materialized view maintenance.

Can I use RisingWave as a drop-in PostgreSQL replacement?

No. RisingWave is designed for stream processing and real-time analytics, not OLTP workloads. It excels at continuously updated materialized views, streaming joins, and real-time aggregations. For transactional workloads (INSERT/UPDATE/DELETE with row-level ACID), use PostgreSQL. RisingWave complements PostgreSQL by processing its CDC stream in real time.

Does RisingWave support all PostgreSQL SQL features?

RisingWave supports a large subset of PostgreSQL SQL, including joins, subqueries, window functions, CTEs, aggregations, and most data types. Some PostgreSQL-specific features like stored procedures, triggers, and certain extensions are not supported, as they don't apply to streaming workloads.

What PostgreSQL client tools work with RisingWave?

Any tool that connects to PostgreSQL works with RisingWave: psql, DBeaver, pgAdmin, DataGrip, Metabase, Grafana, Superset, Tableau, and all PostgreSQL client libraries (psycopg2, pgx, node-postgres, JDBC, etc.).