SaaSHub helps you find the best software and product alternatives Learn more →
Top 23 Rust Database Projects
-
MeiliSearch
A lightning-fast search API that fits effortlessly into your apps, websites, and workflow
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
sonic
🦔 Fast, lightweight & schema-less search backend. An alternative to Elasticsearch that runs on a few MBs of RAM.
-
-
neon
Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage.
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
databend
𝗗𝗮𝘁𝗮, 𝗔𝗻𝗮𝗹𝘆𝘁𝗶𝗰𝘀 & 𝗔𝗜. Modern alternative to Snowflake. Cost-effective and simple for massive-scale analytics. https://databend.com
-
risingwave
SQL stream processing, analytics, and management. We decouple storage and compute to offer speedy bootstrapping, dynamic scaling, time-travel queries, and efficient joins.
-
-
-
-
-
greptimedb
An open-source, cloud-native, distributed time-series database with PromQL/SQL/Python supported. Available on GreptimeCloud.
-
-
cozo
A transactional, relational-graph-vector database that uses Datalog for query. The hippocampus for AI!
-
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
We needed to introduce a new service for search. As we settled on using meilisearch, we needed a way to sync updates on our models with the records in meilisearch. We could've continued to use callbacks but we needed something better.
Scalable Realtime Datastore: The piece examines a scalable datastore specifically created for metrics events and real-time analytics. (2013-09-26, shares: 26787.0)
Project mention: Why SurrealDB is the Future of Database Technology - An In-Depth Look | dev.to | 2024-05-09SurrealDB was designed from the start to have unparalleled deployment flexibility, combining the ease of use of embedded databases such as SQLite and the power of client-server databases with all our multi-model features into a single Rust binary!
Sonic - a project written in Rust, uses custom network communication protocol for fast communication between the client and the server.
Project mention: just wanted to ask is there an in memory database that uses s3 or gcp cloud storage as permanent storage | /r/Database | 2023-07-04I know that very similar functionality to this is in TiDB Serverless ( https://tidbcloud.com ). TiDB is a distributed relational database. It uses TiKV ( which is a key/value engine ) as the storage engine. You could use SQL to access your K/V records. There is ongoing work in TiKV to support S3 directly as the storage backend ( https://github.com/tikv/tikv/issues/6506 ) .
Postgres (With Neon DB)
Project mention: Top 10 Rusty Repositories for you to start your Open Source Journey | dev.to | 2023-12-197. Diesel
Project mention: SableDb – a key/value store that uses RocksDB and Redis API (written in Rust) | news.ycombinator.com | 2024-04-04a few times, seems interesting. The author's also built a lot of other cool concurrency primitives for Rust as well.
[0] https://github.com/spacejam/sled
Databend vs. Snowflake: https://github.com/datafuselabs/databend/issues/13059
Project mention: Proton, a fast and lightweight alternative to Apache Flink | news.ycombinator.com | 2024-01-30How does this compare to RisingWave and Materialize?
https://github.com/risingwavelabs/risingwave
SQL with SeaORM:
Project mention: The Notifier Pattern for Applications That Use Postgres | news.ycombinator.com | 2024-05-14Those updates are not retroactive. They apply on a go forward basis. Each day's changes become Apache 2.0 licensed on that day four years in the future.
For example, v0.28 was released on October 18, 2022, and becomes Apache 2.0 licensed four years after that date (i.e., 2.5 years from today), on October 18, 2026.
[0]: https://github.com/MaterializeInc/materialize/blob/76cb6647d...
Project mention: Error Handling for Large Rust Projects - A Deep Dive into GreptimeDB's Practices | dev.to | 2024-05-12**A good error report is not only about how it gets constructed, but what is more important, to tell what human can understand from its cause and trace. We call it Stacked Error.** It should be intuitive and you must have seen a similar format elsewhere like backtrace. From this log, it's easy to know the entire thing with full context, from the user-facing behavior to the root cause. Plus the exact line and column number of where each error is propagated. You will know that this error is *"from the query "blabla", the fifth package's header is corrupted"*. It's likely to be invalid user input and we may not need to handle it from the server side. This example shows the critical information that an error should contain: - **The root cause** that tells what is happening. - **The full context stack** that can be used in debugging or figuring out where the error occurs. - **What happens from the user's perspective.** Decide whether we need to expose the error to users. The first root cause is often clear in many cases, like the DecodeMessage example above, as long as the library or function we used implements their error type correctly. But only having the root cause can be not enough. Here is another [evidence](https://github.com/delta-incubator/delta-kernel-rs/pull/151) from Delta Lake developed by Databricks:  In the following sections, we will focus on the context stack and the way to present errors. And shows the way we implement it. So hopefully you can reproduce the same practices as in GreptimeDB. ### System Backtrace So, now you have the root cause (`DecodeMessage(serde_json: invalid character at 1)`). But it's not clear at which step this error occurs: when decoding the header, or the body? A intuitive thought is to capture the backtrace. `.unwrap()` is the first choice, where the backtrace will show up when error occurs (of course this is a bad practice). It will give you a complete call stack along with the line number. Such a call stack contains the full trace, including lots of unrelated system stacks, runtime stacks and std stacks. If you'd like to find the call in application code, you have to inspect the source code stack by stack, and skip all the unrelated ones. Nowadays, many libraries also provide the ability to capture backtrace on an `Error` is constructed. Regardless of whether the system backtrace can provide what we truly want, it's very costly on either CPU ([#1261](https://github.com/GreptimeTeam/greptimedb/pull/1261)) and memory ([#1273](https://github.com/GreptimeTeam/greptimedb/pull/1273)). Capturing a backtrace will significantly slow down your program, as it needs to walk through the call stack and translate the pointer. Then, to be able to translate the stack pointer we will need to include a large `debuginfo` in our binary. In GreptimeDB, this means increasing the binary size by >700MB (4x compared to 170MB without debuginfo). And there will be many noises in the captured system backtrace because the system can't distinguish whether the code comes from the standard library, a third-party async runtime or the application code. There is another difference between the system backtrace and the proposed Stacked Error. System backtrace tells us how to get to the position where the error occurs and you cannot control it, while the Stacked Error shows how the error is propagated. Take the following code snippet as an example to examine the difference between system backtrace and virtual stack: ```rust async fn handle_request(req: Request) -> Result { let msg = decode_msg(&req.msg).context(DecodeMessage)?; // propagate error with new stack and context verify_msg(&msg)?; // pass error to the caller directly process_msg(msg).await? // pass error to the caller directly } async fn decode_msg(msg: &RawMessage) -> Result { serde_json::from_slice(&msg).context(SerdeJson) // propagate error with new stack and context }
The goto Redis client for Rust is called redis-rs. It has over 3k stars on Github. but I found it very annoying to use because I quickly found out that if you want to set any value you had to get a mutable reference to the underlying client. Which meant great pain to store Redis client in the global scope. People who do not know what a mutable reference is consider the let keyword in JavaScript. you can mutate or change a variable that is initiated with let.
Project mention: I'm writing a new vector search SQLite Extension | news.ycombinator.com | 2024-05-02Any thoughts on how your project will compare to CozoDB?
https://github.com/cozodb/cozo
"Rusqlite is an ergonomic wrapper for using SQLite from Rust." - Crates.io
I think a lot of Ratatui apps will tend to land on similar concepts for your app. There's a few good examples of apps using a component approach rather than just widgets that I'm aware of:
- https://github.com/sxyazi/yazi
- https://github.com/TaKO8Ki/gobang
- https://github.com/nomadiz/edma
Perhaps the intuitive crate would make a good abstraction on top of Ratatui?
Project mention: GlueSQL v0.14 Release - Schemaless data support and the official doc website | /r/rust | 2023-05-30
NOTE:
The open source projects on this list are ordered by number of github stars.
The number of mentions indicates repo mentiontions in the last 12 Months or
since we started tracking (Dec 2020).
Rust Database related posts
-
The new APT 3.0 solver
-
Error Handling for Large Rust Projects - A Deep Dive into GreptimeDB's Practices
-
Why SurrealDB is the Future of Database Technology - An In-Depth Look
-
How to ditch Neon
-
OAuth and OIDC Implementation in SQL
-
Serverless Postgres with Neon - My first impression
-
Show HN: I made a tool to easily compare pricing of developer tools and services
-
A note from our sponsor - SaaSHub
www.saashub.com | 17 May 2024
Index
What are some of the best open-source Database projects in Rust? This list will help you:
| Project | Stars | |
|---|---|---|
| 1 | MeiliSearch | 43,577 |
| 2 | InfluxDB | 27,876 |
| 3 | surrealdb | 25,689 |
| 4 | sonic | 19,476 |
| 5 | tikv | 14,573 |
| 6 | neon | 12,403 |
| 7 | diesel | 12,020 |
| 8 | sled | 7,798 |
| 9 | databend | 7,258 |
| 10 | risingwave | 6,366 |
| 11 | sea-orm | 6,364 |
| 12 | toydb | 5,912 |
| 13 | materialize | 5,598 |
| 14 | SpacetimeDB | 4,109 |
| 15 | Replibyte | 4,003 |
| 16 | greptimedb | 3,835 |
| 17 | redis-rs | 3,457 |
| 18 | rust-postgres | 3,312 |
| 19 | cozo | 3,137 |
| 20 | rusqlite | 2,770 |
| 21 | gobang | 2,687 |
| 22 | gluesql | 2,609 |
| 23 | incubator-horaedb | 2,507 |
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com