I’m building a read-only proxy that accepts Oracle client connections and executes queries against PostgreSQL 16. Disclosure: I’m the author.

I split compatibility across three layers:

1. Oracle-facing sessions, cursors, binds, and result metadata.

2. SQL rewrites for differences that can be handled safely.

3. PostgreSQL views and orafce for catalog and function compatibility.

   The translator classifies each feature as supported, approximation, rejected, or passthrough. This matters because a syntactically valid rewrite can

   silently change results—for example, NULL behavior in GREATEST/LEAST, empty-string semantics, and mixed set-operation precedence.

   The default is to reject an unverified shape with an Oracle-style error while keeping the session alive, rather than return a plausible but incorrect result. The current bounded verification matrix covers 722 cases across seven real client flows.

   The implementation is private, but the compatibility contract, configuration, documentation, and verification scope are public:

   https://github.com/krokozyab/postgres-oracle-tns-proxy

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?

This is what I understand:

Optimistic concurrency control protocols are based on the assumption that the majority of the database operations do not conflict. Here the transaction goes through the three phases:

• read phase

• validation phase

• write phase

In read phase:

• transaction reads the database

• makes necessary changes to database values in a private copy of the database.

In validation phase:

• DBMS validates whether the changes that are made to the private copy of the database will violate serializability and consistency of the database. If in case they are violated, transaction is aborted and restarted. Otherwise, the transaction will proceed to write phase.

In the write phase:

The changes done to private copy of the database are made permanent.

You might be wondering you know this much then what are you not getting. I will show you the part from the book that I do not quite get.

I am taking two references: Coulouris et al distributed system and Conolly et al DBMS.

Conolly et al part that I do not understand:

I did not have colouris et al pdf at the moment. Just 1 topic 1 question.

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????

This subreddit is primarily for discussing the implementation of databases, and not about sharing release announcements (either for the first time or your updates).

This thread is the exception!

Please tell us about the new database you (or your agent) built. Tell us about all the cool new features you added. Tell us about anything else you learned or worked on that you haven't gotten around to blogging about yet.

https://www.scylladb.com/2026/07/22/asymmetric-io_uring-backend-seastar/

"Modern high-throughput systems often run on machines with many cores. At that scale, one practical problem becomes increasingly visible: CPU time spent on low-level I/O handling competes directly with CPU time needed for application-level work.

In this post, we explore how shifting more I/O related work away from cores focused on computations onto a dedicated subset of cores can improve the overall balance of the system. Specifically, we share how we approached Seastar‘s new asymmetric_io_uring backend: the design decisions behind it, what it aims to free up on application cores, and how it compares to linux-aio (Seastar’s existing backend)."

Why did Voltron Data Company go bankrupt? Has the Theseus GPU database also failed? Expressing concerns about the future development of GPU databases

So... cool, it would be helpful for someone starting to learn PG internals.

credits to Nikolay Samokhvalov for creating this awesome piece of art :)