r/databasedevelopment

I recently dug into Meta’s Velox, an open-source C++ execution engine designed to act like a reusable “engine block” for data systems.

Instead of Presto, Spark, etc. independently implementing things like vectorized execution, joins, memory management, spilling, and file readers, Velox provides these building blocks as a shared execution layer.

The performance numbers are interesting too:

• 8.4× faster on TPC-H Q1
• 9× faster on Q6
• 6–7× average speedup on Meta production traffic
• Up to 3× fewer servers

Checkout this interesting deep dive that how Velox actually works and why this architecture could matter for the future of data engines.

https://prestodb.io/blog/2026/08/13/inside-velox-open-source-universal-engine-block-for-big-data-and-ai/

Do you think shared execution layers like Velox will become the norm, or will specialized engines always win?

Isledb is an embedded Go key-value database library on S3 using LSM trees.

1. Writes are batched in the memtable and then flused into SST which gets uploaded to object store.
2. A CAS conditional(e-tag) commits of Current Manifest is made with fencing for the SST to be made viisible for the reader.
3. Compaction can run on seperate process.
4. Reader reads directly from s3 object store

Source Code: https://github.com/ankur-anand/isledb

Blog: Outlines all the design in detail and various nuances and decisions: https://medium.com/@ankur_anand/building-a-key-value-database-on-s3-in-go-fb08d040f0af

Hi All
I’ve been working on a custom data structure and algorithm for hierarchical indexing.

while I designed the algorithm myself, I wouldn't claim to be a definitive master of hierarchy trees, nor postgres. Its actually a Rust project I've turned into an extension. I'm mainly sharing these early numbers in hopes of connecting with the right people to see if there's genuine value.

I'm not sure if I'm violating rule 5; I'd appreciate any guidance on 3rd party benchmarks for this kind of algo compare to ltree.

I ran benchmarks against 500k, 1M, 2M and 20M node recursive trees. The baseline comparisons against ltree are looking solid:

• Huge I/O Drop: For descendant queries, B-tree range scans touch up to 74x fewer buffer pages.
• Query Speed: Subtree queries run 2.5x to 6x faster (500k). up to 16x for 20M nodes. Ancestor lookups (via SP-GiST) execute up to 7.3x faster.
• Storage Density: A custom compact encoding shrank the on disk value size by 42.7%. This translates to a ~23% smaller B-tree index footprint.
• Write Performance: Appending 50,000 leaf nodes is roughly 2x faster. Reparenting large subtrees is 1.2x to 2.7x faster

I have some thoughts where this may be beneficial but lacking some subject matter expertise when it comes to practical application of hierarchy data (and these types of ops), this is the main point of my post, to ask for some insight:

- Could it make servers run more efficiently?
- Do other more efficient extensions/algos beat these benchmarks? Is LTREE just a default?
- What kinds of large scale operations would this benefit? Domains/applications?
- What should my benchmark tests look like?

Eager to get some expert opinions and either validate my thoughts or give me some reality - cheers!

Need suggestions for writing blogs. This was my 1st ever blog, which I published last year, and that's it. No other blog yet 😅. I would love to know, what kind of blogs would you love to read from a guy who contributes to the open-source postgres project?

1. Deep dives like this one on postgres internals? TBH, I think this space so crowded?
2. How did I find a bug and fix it?
3. The new features I am working on?
4. or new features that are going to be released
5. or something cool????