orioledb
sled
Our great sponsors
orioledb | sled | |
---|---|---|
25 | 37 | |
2,631 | 7,758 | |
3.6% | - | |
9.3 | 1.8 | |
14 days ago | 14 days ago | |
C | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
orioledb
-
Supabase Acquires OrioleDB
hey hn, supabase ceo here
we've been fans of Oriole for a while now and have been long-time supporters
in case you're jumping straight to the comments: OrioleDB is a table storage extension for Postgres. it acts as a drop-in replacement for the default postgres storage engine using the Table Access Method APIs (pluggable storage). the storage engine changes the representation of table data on disk. its architecture is designed to take advantage of modern hardware like SSDs and NVRAM. it implements MVCC, the feature that allows allows multiple connected users to see different versions of the data depending on when their transaction started, via an UNDO log rather than tuple versioning.
one caveat: it requires several patches to the postgres core to expand on the type of features external storage engines extensions can implement. for this reason it could be a while before you see this land as a default engine on supabase. we will probably make it available as an option for customers who want to experiment - no timeline is decided yet.
finally, we have been working with the team on decoupled storage and compute [0]. this is experimental but promising, especially with some recent advances in S3 (specifically Express One Zone [1]). we have a demonstration in the blog post.
i'll message Alexander in case there are any technical questions
[0] https://github.com/orioledb/orioledb/blob/main/doc/usage.md#...
[1] https://aws.amazon.com/s3/storage-classes/express-one-zone/
-
Jepsen: MySQL 8.0.34
When I saw "cloud native" I was expecting S3-ish the way Neon does it but they say it's experimental: https://github.com/orioledb/orioledb/blob/beta4/doc/usage.md... and for them to say "beta, don't use in production" and then a separate "experimental" label must make it really bad
-
When Did Postgres Become Cool?
There are some interesting things in development to potentially solve that problem.
Here's a recent HN submission about OrioleDB of the more promising ones: https://news.ycombinator.com/item?id=36740921
Source code: https://github.com/orioledb/orioledb
-
PostgreSQL: No More Vacuum, No More Bloat
https://github.com/orioledb/orioledb/blob/main/doc/arch.md
> - PostgreSQL is very conservative (maybe extremely) conservative about data safety (mostly achieved via fsync-ing at the right times), and that propagates through the IO stack, including SSD firmware, to cause slowdowns
This is why our first goal is to become pure extension. Becoming part of PostgreSQL would require test of time.
> - MVCC is very nice for concurrent access - the Oriole doc doesn't say with what concurrency are the graphs achieved
Good catch. I've added information about VM type and concurrency to the blog post.
> - The title of the Oriole doc and its intro text center about solving VACUUM, which is of course a good goal, but I don't think they show that the "square wave" graphs they achieve for PostgreSQL are really in majority caused by VACUUM. Other benchmarks, like Percona's (https://www.percona.com/blog/evaluating-checkpointing-in-pos...) don't yield this very distinctive square wave pattern.
Yes, it's true. The square patters is because of checkpointing. The reason of improvements here is actually not VACUUM, but modification of relevant indexes only (and row-level WAL, which decreases overall IO).
- OrioleDB Reached Beta
- OrioleDB – building a modern cloud-native storage engine for Postgres
-
The Part of PostgreSQL We Hate the Most (Multi-Version Concurrency Control)
I took a look at https://github.com/orioledb/orioledb which is a project attempting to remedy some of Postgres' shortcomings, including MVCC. It looks like they're doing something similar to MySQL with a redo log, as well as some other optimizations. So maybe this is the answer.
-
Production grade databases in Rust
You don’t need a database written (or rewritten in Rust). we’re working to make Postgres scalable for the next decade too https://github.com/orioledb/orioledb
-
Features I'd Like in PostgreSQL
> I’d love to see B-Tree primary storage option. Aka store the row data inside the primary index.
It is coming: https://github.com/orioledb/orioledb
-
Supabase-JS v2
sorry to underwhelm!
if you like Neon, then I imagine you like their database branching model? On Friday we announced[0] our 500K investment into OrioleDB, who are working on branching[1], with the plan to upstream these changes into Postgres core.
It would be possible for us to run a fork of Postgres today which supports branching, but our long-term view is that developers would prefer a non-forked version of Postgre (to mitigate any risk of lock-in). So we will work on adding branching to Postgres core in the background, which will be a benefit to the entire Postgres ecosystem.
[0] Announcement:https://supabase.com/blog/supabase-series-b#where-were-going
[1] https://github.com/orioledb/orioledb/wiki/Database-branching
sled
-
SableDb – a key/value store that uses RocksDB and Redis API (written in Rust)
a 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
-
Is Something Bugging You?
- Dropbox [3] uses a similar approach but they talk about it a bit more abstractly.
Sans-IO is more documented in Python [4], but str0m [5] and quinn-proto [6] are the best examples in Rust I’m aware of. Note that sans-IO is orthogonal to deterministic test frameworks, but it composes well with them.
With the disclaimer that my opinions are mine and mine alone, and don’t reflect the company I work at —— I do work at a rust shop that has utilized these techniques on some projects.
TigerBeetle is an amazing example and I’ve looked at it before! They are really the best example of this approach outside of FoundationDB I think.
[0]: https://risingwave.com/blog/deterministic-simulation-a-new-e...
[1]: https://risingwave.com/blog/applying-deterministic-simulatio...
[2]: https://dropbox.tech/infrastructure/-testing-our-new-sync-en...
[3]: https://github.com/spacejam/sled
[4]: https://fractalideas.com/blog/sans-io-when-rubber-meets-road...
[5]: https://github.com/algesten/str0m
[6]: https://docs.rs/quinn-proto/0.10.6/quinn_proto/struct.Connec...
-
RFC: redb (embedded key-value store) nearing version 1.0
Sled uses bw-tree actually https://github.com/spacejam/sled/wiki/sled-architectural-outlook
-
Production grade databases in Rust
There is a valid argument to be made for threads over async in a large percentage of use cases where async is considered the default. If this is what you are referring to however, I don't think they ever referred to async as completely useless: https://github.com/spacejam/sled/issues/1123.
-
Best local database that works on all platforms including web?
Have you looked into other pure-Rust databases as well, such as sled or GlueSQL which has an SQL interface on top of sled? I wonder how those would compare to Persy.
-
Are there any embedded databases that have multiple-process support?
I'm not sure what you need. Are these of any use? https://github.com/meilisearch/heed https://github.com/spacejam/sled
- Some key-value storage engines in Rust
-
Are there a demand for management system of embedded storage like RocksDB? I plan to build one in Rust as the language becoming a core of many popular databases but wonder if there’s a demand. Can’t find any similar project even in other languages.
There is also Sled but as I understand it that is being reworked to use the author's new DB core Marble
-
GreptimeDB: a new open source database designed for large-scale time-series data storage and processing, written in rust
There are some databases like sled/FlashDB designed to be embedded to other applications even bare metal microcontrollers. But I do doubt the potential bussiness value of a pure embedded database.
-
Ask HN: Serverless” key value store with transactions?
https://github.com/spacejam/sled
To add transaction support, you probably need a good understanding of how the memtable works in Log Structured Merge trees:
What are some alternatives?
neon - Neon: Serverless Postgres. We separated storage and compute to offer autoscaling, branching, and bottomless storage.
RocksDB - A library that provides an embeddable, persistent key-value store for fast storage.
tsbs - Time Series Benchmark Suite, a tool for comparing and evaluating databases for time series data
rust-rocksdb - rust wrapper for rocksdb
timescale-analytics - Extension for more hyperfunctions, fully compatible with TimescaleDB and PostgreSQL 📈
redis-rs - Redis library for rust
postgres - PostgreSQL with extensibility and performance patches
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
plv8 - V8 Engine Javascript Procedural Language add-on for PostgreSQL
mini-redis - Incomplete Redis client and server implementation using Tokio - for learning purposes only
promscale - [DEPRECATED] Promscale is a unified metric and trace observability backend for Prometheus, Jaeger and OpenTelemetry built on PostgreSQL and TimescaleDB.
heed - A fully typed LMDB wrapper with minimum overhead 🐦