[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-5525":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":14,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":22,"hasPages":24,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":37,"readmeContent":38,"aiSummary":39,"trendingCount":16,"starSnapshotCount":16,"syncStatus":40,"lastSyncTime":41,"discoverSource":42},5525,"risingwave","risingwavelabs\u002Frisingwave","risingwavelabs","Event streaming platform for agentic AI. Continuously ingest, transform, and serve event streams in real time, at scale.","https:\u002F\u002Fgo.risingwave.com\u002Fslack",null,"Rust",9078,777,79,1259,0,1,17,7,39.67,"Apache License 2.0",false,"main",true,[26,27,28,29,30,31,32,33,34,35,36],"apache-iceberg","data-engineering","database","etl-pipeline","event-streaming","kafka","materialized-view","postgresql","rust","stream-processing","webhook","2026-06-12 02:01:11","\n\u003Cp align=\"center\">\n  \u003Cpicture>\n    \u003Csource srcset=\".github\u002FRisingWave-logo-dark.svg\" width=\"500px\" media=\"(prefers-color-scheme: dark)\">\n    \u003Cimg src=\".github\u002FRisingWave-logo-light.svg\" width=\"500px\">\n  \u003C\u002Fpicture>\n\u003C\u002Fp>\n\n\n\u003Cdiv align=\"center\">\n\n### 🌊 Event Streaming for Agentic AI\n\n\u003C\u002Fdiv>\n\u003Cp align=\"center\">\n  \u003Ca href=\"https:\u002F\u002Fdocs.risingwave.com\u002F\">Docs\u003C\u002Fa> | \u003Ca href=\"https:\u002F\u002Fdocs.risingwave.com\u002Fget-started\u002Frw-benchmarks-stream-processing\">Benchmarks\u003C\u002Fa> | \u003Ca href=\"https:\u002F\u002Fdocs.risingwave.com\u002Fdemos\u002Foverview\">Demos\u003C\u002Fa> | \u003Ca href=\"https:\u002F\u002Frisingwave.com\u002Fcustomers\u002F\">Case Studies\u003C\u002Fa>\n\u003C\u002Fp>\n\n\u003Cp align=\"center\">\n\n\u003Cdiv align=\"center\">\n  \u003Ca\n    href=\"https:\u002F\u002Fgithub.com\u002Frisingwavelabs\u002Frisingwave\u002Freleases\u002Flatest\"\n    target=\"_blank\"\n  >\n    \u003Cimg alt=\"Release\" src=\"https:\u002F\u002Fimg.shields.io\u002Fgithub\u002Fv\u002Frelease\u002Frisingwavelabs\u002Frisingwave.svg?sort=semver\" \u002F>\n  \u003C\u002Fa>\n  \u003Ca\n    href=\"https:\u002F\u002Fgo.risingwave.com\u002Fslack\"\n    target=\"_blank\"\n  >\n    \u003Cimg alt=\"Slack\" src=\"https:\u002F\u002Fbadgen.net\u002Fbadge\u002FSlack\u002FJoin%20RisingWave\u002F0abd59?icon=slack\" \u002F>\n  \u003C\u002Fa>\n  \u003Ca\n    href=\"https:\u002F\u002Fx.com\u002Frisingwavelabs\"\n    target=\"_blank\"\n  >\n    \u003Cimg alt=\"X\" src=\"https:\u002F\u002Fimg.shields.io\u002Ftwitter\u002Ffollow\u002Frisingwavelabs\" \u002F>\n  \u003C\u002Fa>\n  \u003Ca\n    href=\"https:\u002F\u002Fwww.youtube.com\u002F@risingwave-labs\"\n    target=\"_blank\"\n  >\n    \u003Cimg alt=\"YouTube\" src=\"https:\u002F\u002Fimg.shields.io\u002Fyoutube\u002Fchannel\u002Fviews\u002FUCsHwdyBRxBpmkA5RRd0YNEA\" \u002F>\n  \u003C\u002Fa>\n\u003C\u002Fdiv>\n\nRisingWave is an event streaming platform for agentic AI. It continuously ingests data from databases, event streams, and webhooks, processes it incrementally, and serves fresh results at low latency, replacing the traditional event streaming stack (e.g., Debezium + Kafka + Flink + serving DB) with a single system.\n\n![RisingWave](.\u002Fdocs\u002Fdev\u002Fsrc\u002Fimages\u002Farchitecture_20250609.jpg)\n\n---\n\n## Try it out in 60 seconds\n\n```shell\ncurl -L https:\u002F\u002Frisingwave.com\u002Fsh | sh\n```\n\nFor Docker, Kubernetes, and other options, see the [quick start guide](https:\u002F\u002Fdocs.risingwave.com\u002Fget-started\u002Fquickstart).\n\n---\n\n## The problem\n\nAgents and real-time applications need data that is always fresh and queryable at low latency. The standard approach chains together Debezium for CDC, Kafka for transport, Flink for processing, and a database for serving. Each hop adds latency and each system adds operational overhead.\n\nRisingWave replaces the whole stack: ingest, process, serve, store.\n\n---\n\n## How it works\n\n### Ingest from any source\n\nRisingWave ingests across the full data spectrum:\n\n- **Webhooks**: HTTP-based event ingestion from SaaS applications and external systems\n- **Database changes**: native CDC from PostgreSQL, MySQL, and others via transaction log reading\n- **Event streams**: Kafka, Pulsar, Kinesis, and other message brokers\n- **Historical data**: batch ingestion from S3, data warehouses, and other storage systems\n\nAll sources are unified under the same SQL interface. Streams and tables can be joined freely.\n\n### Process continuously\n\nRisingWave performs incremental computation over ingested data. When upstream data changes, only the affected results are recomputed. End-to-end freshness is under 100 ms.\n\nThis is the core mechanism behind everything RisingWave does: materialized views that are always up to date, without full recomputation on every query.\n\n### Serve at low latency\n\nQuery results are maintained in RisingWave's internal row store and served at 10-20 ms p99 latency. Agents and applications query this layer directly using standard SQL. No polling, no cache warming, no TTL management.\n\n### Store in Apache Iceberg™\n\nFor long-term retention and analytical access, RisingWave writes to Apache Iceberg™ tables. It hosts the Iceberg REST catalog directly and handles table maintenance — compaction, small-file optimization, snapshot cleanup — without external tooling. Iceberg queries are executed via [Apache DataFusion](https:\u002F\u002Fdatafusion.apache.org\u002F), a vectorized query engine. Because Iceberg is an open format, data is also readable by Spark, Trino, DuckDB, and other engines.\n\nThe row store and Iceberg layer serve different purposes: the row store is for low-latency serving, Iceberg is for durable, open-format storage and analytical queries. RisingWave manages both.\n\n---\n\n## Use cases\n\n- **Monitoring and alerting**: continuous evaluation of streaming metrics against thresholds\n- **Feature store**s: batch and streaming features computed over the same pipeline, served from the same system\n- **Live dashboards**: materialized views updated incrementally, no scheduled refreshes\n- **Real-time enrichment**: live events joined with historical reference data in-flight, before delivery downstream\n- **Streaming lakehouses**: continuous, exactly-once ingestion into open-format tables with automated compaction and snapshot management\n\n---\n\n## Design decisions\n\n### Ultimate cost efficiency\n\nInternal state, tables, and materialized views are stored in object storage (S3 or equivalent), which is roughly 100x cheaper than RAM. This enables elastic scaling without data rebalancing and failure recovery in seconds. For latency-sensitive workloads, [elastic disk cache](https:\u002F\u002Fdocs.risingwave.com\u002Fget-started\u002Fdisk-cache) pins hot data on local SSD or EBS, keeping p99 query latency at 10-20 ms.\n\n### Native experience for both humans and agents\n\nRisingWave connects via the PostgreSQL wire protocol and works with psql, JDBC, and any Postgres-compatible tooling. For agents, RisingWave provides a MCP server, a CLI, and Skills, so agents can query and operate RisingWave without custom integration.\n\n### Openness\n\nRisingWave [natively integrates with Apache Iceberg™](https:\u002F\u002Fdocs.risingwave.com\u002Ficeberg\u002Foverview) for continuous stream ingestion, direct reads via DataFusion, and automated table maintenance. Data in Iceberg is in an open format and accessible to any compatible query engine.\n\n---\n\n## Deployment\n\n[**RisingWave Cloud**](https:\u002F\u002Fcloud.risingwave.com) is the managed option.\n\nFor self-hosted:\n- [Docker Compose](https:\u002F\u002Fdocs.risingwave.com\u002Fdeploy\u002Frisingwave-docker-compose\u002F)\n- [Kubernetes with Helm](https:\u002F\u002Fdocs.risingwave.com\u002Fdeploy\u002Frisingwave-k8s-helm\u002F)\n- [Kubernetes with Operator](https:\u002F\u002Fdocs.risingwave.com\u002Fdeploy\u002Frisingwave-kubernetes\u002F)\n\n---\n\n## Community\n\nJoin us on [Slack](https:\u002F\u002Fgo.risingwave.com\u002Fslack) for questions, discussions, and contributions.\n\n---\n\n## Telemetry\n\nRisingWave uses [Scarf](https:\u002F\u002Fscarf.sh\u002F) for anonymized installation analytics and collects anonymous usage statistics to improve the product. Both can be opted out. See the [telemetry documentation](https:\u002F\u002Fdocs.risingwave.com\u002Foperate\u002Ftelemetry\u002F) for details.\n\n---\n\n## License\n\nApache License 2.0. See [LICENSE](LICENSE).\n\n## Contributing\n\nSee the [RisingWave Developer Guide](https:\u002F\u002Frisingwavelabs.github.io\u002Frisingwave\u002F).\n","RisingWave 是一个面向代理型AI的事件流处理平台，能够持续地从多种数据源（如数据库、事件流和Webhook）中摄入数据，并实时进行转换处理，最终以低延迟提供最新结果。其核心功能包括统一的SQL接口支持多种数据源接入、流与表自由连接以及增量计算能力。技术上，RisingWave 采用Rust语言开发，具备高性能和高可靠性。适用于需要实时分析及响应的数据密集型应用场景，如智能客服、在线交易监控等，可替代Debezium + Kafka + Flink + 服务数据库的传统事件流处理架构，简化系统复杂度并降低运维成本。",2,"2026-06-11 03:03:48","top_language"]