Database guides
RisingWave
A streaming database with a PostgreSQL-compatible front end on port 4566. AddisDB queries and browses it; Postgres-specific tooling stays off.
RisingWave is a streaming database that maintains materialized views incrementally over event streams, presenting the result through a PostgreSQL-compatible interface. AddisDB connects with its Postgres driver on port 4566, RisingWave’s default.
Who it is for
RisingWave targets the same problem as a stream processor — continuously updated aggregations over Kafka and change-data-capture feeds — but expressed entirely in SQL and queryable directly, with no separate serving store to keep in sync.
It is not an OLTP database. Its catalog is rw_catalog, and the pg_catalog it exposes is a compatibility surface so that Postgres drivers and BI tools can connect.
Set up the cluster
- For RisingWave Cloud, copy the host from the cluster’s connection panel. For a self-hosted cluster, the frontend node is the one that accepts SQL.
- The port is 4566.
- The default database is dev and the default user is root, with no password on a local install.
- For RisingWave Cloud, create a database user in the console and note its password.
# The frontend node speaks the PG wire protocol on 4566
psql -h risingwave.example.com -p 4566 -d dev -U root -c 'SELECT version();'
Connect from AddisDB
- New Connection → RisingWave. Port prefills to 4566, database to dev and username to root.
- Enter the host, and a password if the cluster requires one.
- Set SSL mode to require for RisingWave Cloud; leave it at prefer for a local cluster.
- Test, then Save.
What AddisDB gives you
Queries and the schema tree. Sources, tables and materialized views appear with their columns, and introspection runs leniently so the pg_catalog sections RisingWave does not implement come back empty instead of failing the whole load.
The results grid, exports, saved queries and the rest of the result-set tooling all work normally.
The Postgres-specific features are off. There is no Live Monitor — RisingWave has no pg_stat_activity; query rw_catalog directly for cluster state. The structured create and alter table builders are hidden because creating a source or materialized view does not match stock CREATE TABLE, and database-user management and test clones are off for the same reason.