Postgres is eating the database world

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

CodeRabbit: AI Code Reviews for Developers
Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
coderabbit.ai
featured
Nutrient - The #1 PDF SDK Library
Bad PDFs = bad UX. Slow load times, broken annotations, clunky UX frustrates users. Nutrient’s PDF SDKs gives seamless document experiences, fast rendering, annotations, real-time collaboration, 100+ features. Used by 10K+ devs, serving ~half a billion users worldwide. Explore the SDK for free.
nutrient.io
featured
  1. pg_hint_plan

    Extension adding support for optimizer hints in PostgreSQL

    pg_hint_plan —— Give PostgreSQL ability to manually force some decisions in execution plans. https://github.com/ossc-db/pg_hint_plan

  2. CodeRabbit

    CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

    CodeRabbit logo
  3. pg_ivm

    IVM (Incremental View Maintenance) implementation as a PostgreSQL extension

  4. pg_bigm

    The pg_bigm module provides full text search capability in PostgreSQL. This module allows a user to create 2-gram (bigram) index for faster full text search.

  5. doltgresql

    DoltgreSQL - Version Controlled PostgreSQL

    We're writing a postgres-compatible database that doesn't use any postgres code:

    https://github.com/dolthub/doltgresql/

    We're doing this because our main product (Dolt) is MySQL-compatible, but a lot of people prefer postgres. Like, they really strongly prefer postgres. When figuring out how to support them, we basically had three options:

    1) Foreign data wrapper. This doesn't work well because you can't use non-native stored procedure calls, which are used heavily throughout our product (e.g. CALL DOLT_COMMIT('-m', 'changes'), CALL DOLT_BRANCH('newBranch')). We would have had to invent a new UX surface area for the product just to support Postgres.

    2) Fork postgres, write our own storage layer and parser extensions, etc. Definitely doable, but it would mean porting our existing Go codebase to C, and not being able to share code with Dolt as development continues. Or else rewriting Dolt in C, throwing out the last 5 years of work. Or doing something very complicated and difficult to use a golang library from C code.

    3) Emulation. Keep Dolt's Go codebase and query engine and build a Postgres layer on top of it to support the syntax, wire protocol, types, functions, etc.

    Ultimately we went with the emulation approach as the least bad option, but it's an uphill climb to get to enough postgres support to be worth using. Our main effort right now is getting all of postgres's types working.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts

  • Show HN: Dera – A platform to manage chunks and embeddings for building RAG apps

    1 project | news.ycombinator.com | 1 Feb 2024
  • Flan – A tasty tool that lets you save, load and share Postgres dumps with ease

    1 project | news.ycombinator.com | 29 Oct 2021
  • Flan, a tool to save and share Postgres across your team

    1 project | news.ycombinator.com | 18 Aug 2021
  • Flan, a tool to quickly take snapshots of Postgres databases and share them with your team

    1 project | /r/lookatmyprogram | 3 Aug 2021
  • Flan: easily save/load postgres snapshots and share them across your team via git

    1 project | /r/CLI | 29 Jul 2021

Did you know that C is
the 6th most popular programming language
based on number of references?