CedarDB, a company commercializing the Umbra research database from TU Munich, writes about database internals and query execution.
HN links it for database engineering topics such as German strings, and commenters discuss CedarDB as a Postgres-compatible, closed-source HTAP contender.
I think this question mixes up two orthogonal dimensions: transactionality (i.e., OLTP vs. OLAP) and data model (relational, document-based, graph, vector, ...).
Regarding transactionality: There is an entire area of research on "hybrid transactional and analytical processing" (HTAP) systems that unifies OLAP and OLTP systems. Hyper [1] pioneered this path at TU Munich, it's successor Umbra [2] recently incorporated as CedarDB [3]. There are lots of others. Most of these systems, AFAIK, are relational.
Regarding data model: What we've seen in the past few decades is that non-relational DBMS (excluding key-value stores) only make sense in rare edge cases that require huge scale. There has, e.g. been research [4] that shows that graph databases are still, well, lacking, compared to relational systems. The common pattern seems to be: unless you need to service very specific workloads at huge scales, SQL is probably enough [5]. Then again, it really comes down to intrinsics. If you were to, for example, implement distributed locking using Postgres, you would likely run into problems with MVCC and Xids very quickly.
So, as you already mentioned, there is no silver bullet. But even today, unless you are Meta or Google, SQL is probably enough for a long time and lots of use cases.
(Full disclosure: I'm working on Hyper full-time).
[1]: https://hyper-db.de/ [2]: https://umbra-db.com/ [3]: https://cedardb.com/ [4]: https://homepages.cwi.nl/~boncz/edbt2022.pdf [5]:…
It seems to be a quote from https://cedardb.com/blog/german_strings/ which is about this German Strings type (implemented in Polars)
But yeah, it's pretty ignorant to assume Rust can't do this since the best available examples (as with many things) are in Rust. CompactString is really nice. On a typical modern (64-bit) computer CompactString takes 24 bytes and holds up to 24 bytes of UTF-8 text inline, while also having a niche.
I guess the confusion arises because C++ people tend to assume that anywhere Rust differs from the practice in the C++ community it's a mistake, even though that's often because C++ made the wrong choice? Rust's &str is "just" &[u8] plus a rule about the meaning of these bytes, and Rust's String is correspondingly "just" Vec<u8> plus a rule about the meaning of those bytes. C++ couldn't have done the former because it only belatedly got the fat pointer slice reference (as the troubled std::span) years after having a string data type.
Rust didn't do this in the stdlib, but not because it's impossible, because it's a trade off and they wanted the provided stdlib type to be straightforward. If you need or even just want the trade off, you can just cargo add compact_str
- Data-Oriented Design Revisited: Type Safety in the Zig Compiler - Matthew Lugg - https://youtu.be/KOZcJwGdQok?si=YDal2Gwb0IJPFgrI
- Andrew Kelley Practical Data Oriented Design (DoD) - https://youtu.be/IroPQ150F6c?si=F1Z0pLO2W5hbQgpM
- CppCon 2014: Mike Acton "Data-Oriented Design and C++" - https://youtu.be/rX0ItVEVjHc?si=jv4hhTSBh3XH--xQ
- Why You Shouldn’t Forget to Optimize the Data Layout - https://cedardb.com/blog/optimizing_data_layouts/
- Handles are the better pointers - https://floooh.github.io/2018/06/17/handles-vs-pointers.html
- Enum of Arrays - https://tigerbeetle.com/blog/2024-12-19-enum-of-arrays/
- Data oriented design book - https://www.dataorienteddesign.com/dodbook/
- Data-oriented design in practice - Stoyan Nikolov - https://youtu.be/_N5-JjogNXU?si=vhaxYcfE6tl11Sux
- Programming without Pointers - Andrew Kelley - https://www.hytradboi.com/2025/05c72e39-c07e-41bc-ac40-85e8308f2917-programming-without-pointers
- More Speed & Simplicity: Practical Data-Oriented Design in C++ - Vittorio Romeo - CppCon 2025 - https://youtu.be/SzjJfKHygaQ?si=jafavSl2YJWk4vIx
- Rust Handle - https://taintedcoders.com/rust/handles
Kind of, with caveats. For one "extensions can interfere with each other and cause incorrect behavior" [1], and the practicallity of implementations varies. Say, Cypher queries using AGE can be order of magnitude slower than using a dedicated graph DB [2].
Yes, you can drive a Ford Falcon coast-to-coast, but how much gas are you going to spend? Postgres is a solid database but has roots in the 80s. Optimizing for modern hardware would reduce hosting costs and improve efficiency. [3]
This isn’t criticism of Postgres as a database but of the idea that it’s inherently sufficient for all use cases.
--
1: https://www.cs.cmu.edu/~pavlo/blog/2025/01/2024-databases-retrospective.html#:~:text=extensions%20can%20interfere%20with%20each%20other%20and%20cause%20incorrect%20behavior
2: https://blog.kuzudb.com/post/what-every-gdbms-should-do-and-vision/
3: https://cedardb.com/blog/ode_to_postgres/#why-is-everyone-still-talking-about-postgresql
Depends on your use case. Redis is a key-value store that is optimized for simpler workloads and is designed as a caching layer.
Umbra, on the other hand, is a full fledged, ACID compliant relational database systems with all bells and whistles.
However, Umbra can process multiple 100ks of transactions per second. If you're interested in more details, take a look at Figure 6 in this research paper: https://db.in.tum.de/~freitag/papers/p2797-freitag.pdf
Disclosure: I work for CedarDB (https://cedardb.com), the commercial spinoff of Umbra.
There are definitely hybrid OLTP-OLAP databases, or HTAP (Hybrid Transaction and Analytical Processing). Microsoft and, I believe, Oracle both have HTAP tech.
The most novel design, I think, is CedarDB (developed by Thomas Neumann's database group at TUM), which adaptively stores both row and column versions of the data [1], where some data is permanently compressed to columnar format and hot rows are converted "just in time" to columnar data as needed.
[1] https://cedardb.com/blog/colibri/