[HN Gopher] Bridged Indexes in OrioleDB: architecture, internals...
       ___________________________________________________________________
        
       Bridged Indexes in OrioleDB: architecture, internals and everyday
       use?
        
       Author : pella
       Score  : 67 points
       Date   : 2025-05-30 10:31 UTC (12 hours ago)
        
 (HTM) web link (www.orioledb.com)
 (TXT) w3m dump (www.orioledb.com)
        
       | apavlo wrote:
       | "Bridged Indexes" is a non-standard term. These are just
       | secondary indexes using logical pointers with a mapping index.
       | IIRC, Oracle, Hana, and HyPer do the same thing.
       | 
       | Source: https://db.cs.cmu.edu/papers/2017/p781-wu.pdf (see Table
       | 1 + Section 6.1)
        
         | _joel wrote:
         | > secondary indexes using logical pointers with a mapping
         | index.
         | 
         | rolls off the tongue.
        
       | rubenvanwyk wrote:
       | Cannot wait for OrioldeDB to reach General Availability. Postgres
       | needs options for open-source separation of storage and compute.
        
         | the_duke wrote:
         | That kind of exists thanks to NeonDB? https://neon.com
         | 
         | Althoug with them being recently acquired by Databricks it
         | remains to be seen how the open source version will fare.
        
           | akorotkov wrote:
           | > That kind of exists thanks to NeonDB?
           | 
           | This is unrelated to NeonDB. OrioleDB has been acquired by
           | Supabase. https://supabase.com/blog/supabase-acquires-oriole
        
         | dkhenry wrote:
         | OrioleDB isn't a separation of storage and compute, its a more
         | efficient storage engine for Postgres to replace the existing
         | HEAP engine. This is like how in MySQL we could swap MyISAM for
         | InnoDB and eventually RocksDB.
         | 
         | I did some benchmarks on it previously to show how much of an
         | improvement it gives over the stock HEAP engine
         | 
         | EDIT: correct link to the public dashboard below, thanks for
         | the heads up @kiwicopple
         | 
         | https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
        
           | kiwicopple wrote:
           | fwiw I couldn't access your airtable link, but I found this
           | one online:
           | 
           | https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N
           | 
           | thanks for running the benchmarks, it helps to have external
           | parties verifying the progress
        
           | CathalMullan wrote:
           | There's an experimental feature which separates storage and
           | compute.
           | 
           | https://www.orioledb.com/docs/usage/decoupled-storage
        
           | iamdanieljohns wrote:
           | Is the need for Oriole negated by using a system that
           | separates storage from compute like Neon, Xata?
        
             | nikita wrote:
             | (Neon CEO)
             | 
             | Not really. OrioleDB solve the vacuum problem with the
             | introduction of the undo log. Neon gives you scale out
             | storage which is in a way orthogonal to OrielDB. With some
             | work you can run OrioleDB AND neon storage and get benefits
             | of both.
        
               | akorotkov wrote:
               | > OrioleDB solve the vacuum problem with the introduction
               | of the undo log.
               | 
               | Way more than just this!
               | 
               | > With some work you can run OrioleDB AND neon storage
               | and get benefits of both.
               | 
               | This would require significant design work, given that
               | significant OrioleDB benefits are derived from row-level
               | WAL.
        
             | tudorg wrote:
             | Answering on behalf of Xata, it is orthogonal. I'm curious
             | to try out Oriole on our platform when I get some time.
        
       ___________________________________________________________________
       (page generated 2025-05-30 23:01 UTC)