I compiled and uploaded zip files with latest orafce and plpgsql_check for PostgreSQL 17 and PostgreSQL 18 - I used Microsoft Visual C 2022.

Setup:

1. download orafce-4.16.3-x86_64-windows.zip or plpgsql_check-2.8.5-x86_64-windows.zip and extract files
2. copy related dll file to PostgreSQL lib directory (NN is number of pg release)
   orafce-NN.dll -> "c:\Program Files\PostgreSQL\NN\lib"
3. remove suffix "x64-16" or "x64-17" from dll file
   orafce-NN.dll -> orafce.dll
4. copy *.sql and *.control files to extension directory
   *.sql, *.control -> "c:\Program Files\PostgreSQL\NN\share\extension"
5. execute with super user rights SQL command CREATE EXTENSION
   CREATE EXTENSION orafce;

Certum Open Source Code Signing Certificate - Windows Setup Reference

Date: December 2025
Hardware: Certum cryptographic card with ACS ACR40T ICC Reader

As AI capabilities continue to evolve and integrate more deeply into our applications, we’re faced with interesting architectural decisions about how to expose our data to large language models (LLMs). Two approaches that have gained significant traction are Retrieval Augmented Generation (RAG) servers (such as pgEdge RAG Server) and Model Context Protocol (MCP) servers (such as pgEdge Natural Language Agent). Both have their place, but they serve quite different purposes and come with vastly different security implications – particularly when it comes to database access.

What is a RAG Server?

What is an MCP Server?

As AI capabilities continue to evolve and integrate more deeply into our applications, we’re faced with interesting architectural decisions about how to expose our data to large language models (LLMs). Two approaches that have gained significant traction are Retrieval Augmented Generation (RAG) servers (such as pgEdge RAG Server) and Model Context Protocol (MCP) servers (such as pgEdge Natural Language Agent). Both have their place, but they serve quite different purposes and come with vastly different security implications – particularly when it comes to database access.

What is a RAG Server?

What is an MCP Server?

I like reproducible development. I also like short feedback loops. Combining both for pgrx was… educational. 🙂 In this post, I share the mistakes, the small pains, and the fixes I used to get a working VS Code dev container for a Rust project that builds PostgreSQL extensions with pgrx. If you’re writing extensions or using pgrx in a team, this will save you a few grey hairs.

TL;DR:

• PostgreSQL refuses to run as root. Don’t run your devcontainer as root if cargo pgrx test must work.
• Install user-specific Rust tools as the non-root user, remember that order matters.
• Run cargo pgrx init after the container starts (use postCreateCommand) so the config persists.

A quick story

I was setting up a devcontainer for an etcd_fdw project that uses pgrx to produce a PostgreSQL extension. At first, it seemed straightforward: start from the official Rust image, install build deps, add cargo-pgrx, and be done.

But real life is noisy. I hit permission errors, failing tests, and an annoying config.toml not found. Have you run 'cargo pgrx init' yet?. After some digging, I discovered three core issues that you should watch out for.

The PostgreSQL root problem

PostgreSQL will not run as root by design. cargo pgrx test launches PostgreSQL instances for integration testing. If your devcontainer runs as root (or if you initialize pgrx as root and then switch user incorrectly), tests will fail.

First, I tried to set remoteUser: "root" in devcontainer.json and installing everything as root. The build failed with errors when tests attempted to run PostgreSQL.

The fix is (simplified Dockerfile snippet):

# Create a non-root user early in the image build
RUN useradd -m -s /bin/bash -u 1000 vscode && \
echo "vscode ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers

# Switch to that user for subsequent steps that create user-owned files
USER vscode

The key takeaway is to think about runtime actions (what cargo pgrx test will do) when you design the container user. Create and use a non-root user earl

With PostgreSQL 18 introducing built-in OAuth 2.0 and OpenID Connect (OIDC) authentication, tools like pg_oidc_validator have become an essential part of the ecosystem by enabling server-side verification of OIDC tokens directly inside PostgreSQL. If you’re new to the topic, make sure to read our earlier posts explaining the underlying concepts and the need for external validators:

• Why PostgreSQL needs external token validators
• Security aspects of OIDC validation in PostgreSQL
• Deploying pg_oidc_validator v0.1 - a DBA’s perspective

This release builds on the initial version announced in October and continues our mission to make OIDC adoption in PostgreSQL reliable, fast, and accessible for all users.

A useful new feature was introduced on 11 December 2025: Allow expiration of the oldest full backup regardless of current retention. Details are available in commit bf2b276.

Before this change, it was awkward to expire only the oldest full backup while leaving the existing retention settings untouched. Users had to temporarily adjust retention (or write a script) to achieve the same result. Expiring the oldest full backup is particularly helpful when your backup repository is running low on disk space.

Let’s see how this works in practice with a simple example.

Example of expiring the oldest full backup

Let’s use a very basic demo setup.

$ pgbackrest info
...
wal archive min/max (18): 000000010000000000000056/000000010000000300000038

full backup: 20251217-095505F
    wal start/stop: 000000010000000000000056 / 000000010000000000000056

incr backup: 20251217-095505F_20251217-095807I
    wal start/stop: 00000001000000010000001B / 00000001000000010000001B
    backup reference total: 1 full

full backup: 20251217-095902F
    wal start/stop: 000000010000000100000090 / 000000010000000100000090

incr backup: 20251217-095902F_20251217-100124I
    wal start/stop: 000000010000000200000013 / 000000010000000200000013
    backup reference total: 1 full

This gives us two full backups, each of them with a linked incremental backup. Note that I have deliberately reduced the output of the info command to the information relevant to our test case.

$ pgbackrest expire --stanza=demo --dry-run
P00   INFO: [DRY-RUN] expire command begin 2.57.0: ...
P00   INFO: [DRY-RUN] repo1: 18-1 no archive to remove
P00   INFO: [DRY-RUN] expire command end: completed successfully

If we run the expire command, nothing is expired, as I have set repo1-retention-full=2, meaning that two full backups should be kept.

Let’s now imagine that your backup repository is running out of disk space and you want to remove the oldest backup to free up some space. How would you do that?

Once you have identified the back

One of the principal and most powerful components of the pgEdge Agentic AI Toolkit is the pgEdge Postgres MCP Server. In just over a year MCP (Model Context Protocol), initially developed by Anthropic, has become the standard way to connect LLMs to external data sources and tools. Some people describe it as being like a USB for LLMs. The pgEdge Postgres MCP server makes it extremely easy to connect Claude Code, Claude Desktop, Cursor and other AI development tools directly to Postgres database – not just pgEdge distributions, but standard community Postgres, Amazon RDS, and pretty much any other relatively standard version of Postgres (so long as it is v14 or newer).Let’s walk through how to set up the pgEdge Postgres MCP Server, what makes it different, and how to use it with Claude Desktop and AI code generators like Claude Code and Cursor. Our discussion is somewhat Claude-centric, but the pgEdge MCP Server also works with OpenAI GPT-5 and local models such as Ollama.

What Makes Our MCP Server for Postgres Different

We are delighted today to be announcing the beta release of our pgEdge Agentic AI Toolkit for Postgres.  We’ve had the benefit of collaborating on real-world Postgres-based AI applications the past two years with a number of leading customers, and this product announcement is the outgrowth of this learning.We listened to customers as they refined their AI strategies in response to the rapid evolution of LLMs, Agentic AI and integration technologies such as the Model Context Protocol (MCP), and as we did so a few things stood out to us.First and foremost, many of the newly available tools and technologies are not suited to the needs of the enterprise, particularly in highly regulated industries or major government agencies.   Many of the new AI application builders and code generators – and the database platforms supporting them – do not adequately address enterprise requirements for high availability, data sovereignty, global deployment, security and compliance and the need in some cases to run on-premises or in self-managed cloud accounts.  As one CIO in financial services put it to us recently: “We’ve got a couple of dozen AI generated applications end users really want to put into production, but first we’ve got to figure out how to deploy them on our own internal compliant infrastructure.”Secondly, as compelling as it is to automate workflows with Agentic AI, or to generate new applications with tools like Claude Code, Replit, Cursor or Lovable, the biggest need is to work with existing databases and applications.  While newer Postgres-based cloud services work well with Agentic AI and AI app builders for brand new applications, they cannot accommodate existing databases and applications without a costly migration. And such a migration may well be to an environment that doesn’t meet the organization’s strict security and compliance requirements. Enterprise customers need AI tooling – including an MCP Server – that can operate against their existing databases.Additionally we saw there was no dedicated Postg

© Laurenz Albe 2025

Most major Linux distributions have upgraded to the GNU C library version 2.28 or later. Therefore, there is a growing awareness that an operating system upgrade can lead to index corruption. However, rebuilding all your indexes can slow down the upgrade process considerably. In this article, I want to discuss how you can avoid rebuilding more indexes than necessary.

A management summary of the problem

For natural language collation support (the rules to compare and sort strings in natural languages), PostgreSQL largely relies on external libraries. Depending on how how you ran initdb, that could be the C library or the ICU library. Sometimes bugfixes in the new library versions that you install during an operating system upgrade lead to a change in a collation. Since database indexes are pre-sorted data structures, a change in the rules for sorting strings can render such indexes to be sorted incorrectly. This index corruption can lead to wrong query results and violated unique constraints.

The solution is to rebuild an affected index with the REINDEX command.

Keeping the down time for an operating system upgrade short

For many users, it is important that any down time of the database is as short as possible. For such users, the need to rebuild indexes is a problem. If you want to play it safe, you cannot start working with the database before rebuilding the indexes is completed. You could also take a more relaxed attitude and risk starting the application right away. Then you would use REINDEX INDEX CONCURRENTLY to rebuild problematic indexes while your application is running. The risk is that your index scans may return wrong results for a while, and few people are willing to take such a risk.

One way to perform an operating system upgrade that avoids the problem of corrupted indexes and can keep the down time very short is logical replication. Here, the subscriber builds its indexes based on logical information (similar to SQL statements). Consequently, th

A Journey Through PostgreSQL Events

• Introduction
• Community recognition (transparency, inclusivity, organisational balance)
• If I organise a PostgreSQL event — does it have to be recognised?
• Are community-recognised events better than those that aren’t?
• Conferences — a quick flyover (pgDays, pgConfs, FOSDEM, PGConf.dev etc.)
• PostgreSQL User Groups / meet-ups
• Key takeaways
• Which PostgreSQL event to attend?

Introduction

Working at a PostgreSQL-focused company for over 10 years takes you places. Specifically, it takes you to PostgreSQL community events that are very different than your standard commercial conference.

The dynamic of community events is different. They feel like a village fête, where people have known each other for ages. There’s familiarity, shared purpose, and a genuine sense of belonging.

At the same time, there are many different Postgres-focused events — community and commercial ones, small meet-ups, bigger pgDays, and even larger pgConfs - each with a slightly different audience and scope in mind.

So when I’ve been recently asked, “Which Postgres conference would you recommend going to?” I realised this might be a good topic for a post.

A quick note —here, I’ll mention a handful of events, predominantly in Europe, but there are, of course, many others Postgres-focused events out-there. From PG Down Under in Australia to pgDay Mexico to PGConf NYC 2025 to growing user group meetings in Madagascar and Armenia, and the virtual ones, such as POSETTE and Postgres meetup for all— Postgres is definitely having its momentum.

When you see 🔔 below, those are actions or deadlines worth noting.

Community recognition

Majority of PostgreSQL conferences can be found on PostgreSQL.org events page and of those some are community recognised (note a small gold medal next to their titles) while others aren’t.

Community event recognition indicates that an event complies with the PostgreSQL event recog

Quick announcement to say that I’ve replaced the ancient markdown parser with a new one, discount, which supports tables, code fences, definition lists, and more. I reindexed pg_clickhouse this morning and it’s sooo nice to see the table properly formatted.

New uploads will use this parser for Markdown (but not MultiMarkdown) files from now on. I think I’ll start working on reindexing all existing extensions, too. Give me a holler if you don’t see an improvement in your extensions in the next few days.

• Heap sequential scans, like plain SELECT and COPY operations that stream lots of data
• VACUUM on big tables and indexes
• ANALYZE sampling
• Bitmap heap scans

Autovacuum benefits from this change too, since its workers share the same VACUUM/ANALYZE code paths. Other operations still remain synchronous for now:

• B‑tree index scans / index‑only scans
• Recovery & replication
• All write operations INSERT, UPDATE, DELETE, WAL writes
• Small OLTP lookups that touch a single heap page

Data privacy regulations such as GDPR, CCPA, and HIPAA have made it increasingly important for organisations to protect personally identifiable information (PII) in their databases. Whether you're creating a development environment from production data, sharing datasets with third parties, or simply trying to minimise risk, you'll often need to anonymise sensitive data whilst maintaining the structure and relationships within your database.I've been working on a tool to address this need: . It's a command-line utility that replaces PII in PostgreSQL databases with realistic but fake values, all whilst preserving referential integrity and data consistency.

The Problem

• The same customer email appears consistently across all tables

• Foreign key relationships remain intact

• The anonymised data looks realistic (not just "XXXX" or "test@test.com")

• The process is repeatable and auditable

Enter pgEdge Anonymizer

Installation

Configuration

On December 11, the PGDay CERN 2026 CfP committee met to finalize the talk selection. The committee members are listed here:

• Tobias Bussmann, SCNAT (chair, non voting)
• Abel Cabezas Alonso, CERN
• Maurizio De Giorgi, CERN
• Andreas Geppert, ZKB
• Julia Gugel, migrolino
• Tom Hagel, Volue
• Svitlana Lytvynenko, CYBERTEC *Gülçin Yıldırım Jelinek, Xata

IT Tage Frankfurt Dec 8-11 2025 Workshops:

• Hans-Jürgen Schönig

Talks:

• Thomas Koch
• Raphael Salguero Aragón
• Robert Baric
• Hans-Jürgen Schönig
• Adrien Obernesser
• Bernd Patolla
• Michael Mühlbeyer
• Daniel Westermann
• Dirk Krautschick
• Chris Norman Bischoff
• Jonas Gassenmeyer
• Markus Dahm
• Dr. Veikko Krypczyk

Meetup Frankfurt on December 10 2025 organised by Ilya Kosmodemiansky and Diego Calvo de No

Speaker

• Andreas Scherbaum
• Dirk Aumueller

New podcast episode What Postgres developers can expect from PGConf.dev published by Claire Giordano from her series “Talking Postgres” with Melanie Plageman.

On December 11 2025, Jimmy Angelakos organized the first PostgreSQL Edinburgh meetup. Chris Ellis and Jimmy Angelakos spoke at this meetup.

The Swiss PostgreSQL Users had a Meetup in Zurich, speakers are Stefan Keller and Lars Herrmann.

The Talk Selection Committee from the Prague PostgreSQL Developer Day finalized the schedule for P2D2 - the team consists of:

• Pavlo Golub
• Pavel Hák
• Hana Litavská
• Teresa Lopes
• Mayur B
• Esther Miñano
• Josef Šimánek
• Pavel Stěhule
• Tomáš Vondra

From time to time I see questions from otherwise well informed people about how the PostgreSQL Build farm checks how pg_upgrade checking is done across versions, e.g. how does it check upgrading from release 9.5 to release 18. I realize that this isn't well documented anywhere, so here is a description of the process.

All of the code referenced here can be found at https://github.com/PGBuildFarm/client-code.

The principal buildfarm client script is run_build.pl, which builds and tests a single branch (e.g. REL_17_STABLE). There is another script called run_branches.pl, which calls this run_build

PostgreSQL maintenance doesn't have to mean downtime anymore. With pgEdge's zero-downtime node addition, you can perform critical maintenance tasks like version upgrades, hardware replacements, and cluster expansions without interrupting production workloads. Your applications stay online. Your users stay connected. Your business keeps running.This capability is available across both single-primary deployments (with integration of the open source extension Spock) and globally distributed deployments (by default), giving you the same operational advantages whether you're running a single-region deployment or a globally distributed system. Now, for an incredibly quick and easy approach to zero-downtime node addition, you can use the pgEdge Postgres Control Plane (hosted on GitHub). This approach provides drastically simplified management and orchestration of Postgres databases using a declarative API, whether you're running a single-primary or a globally distributed deployment of PostgreSQL clusters. Spock and other high-availability components come built-in accompanying community PostgreSQL for quick database administration with simple commands.And because pgEdge and all associated components are 100% open source under the PostgreSQL license, using 100% core community PostgreSQL, you get to leverage the high-availability components that enable zero-downtime maintenance without vendor lock-in or compatibility concerns.

What Is the Spock Extension?

Zero-Downtime Node Addition: Maintenance Without Interruption

There is common misconception that troubles most developers using PostgreSQL: tune VACUUM or run VACUUM, and your database will stay healthy. Dead tuples will get cleaned up. Transaction IDs recycled. Space reclaimed. Your database will live happily ever after.

But there are couple of dirty "secrets" people are not aware of. First of them being VACUUM is lying to you about your indexes.

The anatomy of storage🔗

When you delete a row in PostgreSQL, it is just marked as a 'dead tuple'. Invisible for new transactions but still physically present. Only when all transactions referencing the row are finished, VACUUM can come along and actually remove them - reclamining the space in the heap (table) space.

To understand why this matters differently for tables versus indexes, you need to picture how PostgreSQL actually stores your data.

Your table data lives in the heap - a collection of 8 KB pages where rows are stored wherever they fit. There's no inherent order. When you INSERT a row, PostgreSQL finds a page with enough free space and slots the row in. Delete a row, and there's a gap. Insert another, and it might fill that gap - or not - they might fit somewhere else entirely.

This is why SELECT * FROM users without an ORDER BY can return rows in order initially, and after some updates in seemingly random order, and that order can change over time. The heap is like Tetris. Rows drop into whatever space is available, leaving gaps when deleted.

When VACUUM runs, it removes those dead tuples and compacts the remaining rows within each page. If an entire page becomes empty, PostgreSQL can reclaim it entirely.

And while indexes are on surface the same collection of 8KB pages, they are different. A B-tree index must maintain sorted order - that's the whole point of their existence and the reason why WHERE id = 12345 is so fast. PostgreSQL can binary-search down the tree instead of scanning every possible row. You can learn more about the fundamentals of B-Tree Indexes and what makes th

While moving production database workloads towards cloud-native (Kubernetes) environments has become very popular lately, plenty of users still rely on good old Docker containers. Compared to running PostgreSQL on bare metal, on virtual machines, or via a Kubernetes operator, Docker adds a bit of complexity, especially once you want to go beyond simple pg_dump / pg_restore for backups, upgrades, and disaster recovery.

A few years back, it was common to find open-sourced Dockerfiles from trusted companies bundling PostgreSQL with the extensions and tooling you needed. Most of those projects are now deprecated, as the ecosystem’s focus has shifted hard towards cloud-native patterns.

In many of my conversations with pgBackRest users, one theme comes up regularly: deploying pgBackRest for backups in Docker is straightforward, but restoring from those backups feels much harder. The usual advice was to “use a trusted Docker image and follow their guidelines”, but those images are mostly out-of-date now. These days you typically need to maintain your own image, and more importantly you need a reliable recovery playbook.

So I asked myself: how hard is point-in-time recovery (PITR) with pgBackRest for a PostgreSQL 18 Docker container? Turns out: not that hard, once you’ve seen it end-to-end.

This post is a small lab you can run locally. You’ll:

• build a PostgreSQL 18 + pgBackRest image
• take a full backup
• create restore points
• delete data on purpose
• restore to the moment just before the delete

The tiny lab setup

The lab image is deliberately small. It just layers pgBackRest on top of the official PostgreSQL 18 image, adds a minimal config, and enables WAL archiving on first init.

Dockerfile

FROM postgres:18

# Install PGDG repository
RUN apt-get update && apt-get install -y \
wget \
gnupg \
lsb-release \
&& wget --quiet -O /usr/share/keyrings/postgresql-archive-keyring.asc https://www.postgresql.org/media/keys/ACCC4CF8.asc \
&& echo "deb [signed-by=/usr/share/keyri

In a recent Postgres patch authored by Greg Sabino Mullane, Postgres has a new step forward for data integrity: data checksums are now enabled by default.

This appears in the release notes as a fairly minor change but it significantly boosts the defense against one of the sneakiest problems in data management - silent data corruption.

Let’s dive into what this feature is, what the new default means for you, and how it impacts upgrades.

What is a data checksum?

A data checksum is a simple but powerful technique to verify the integrity of data pages stored on disk. It's like a digital fingerprint for every 8KB block of data (a "page") in your database.

• Creation: When Postgres writes a data page (table and indexes) to disk, it runs an algorithm on the page's contents to calculate a derived, small value—the checksum.
• Storage: This checksum is stored in the page header alongside the data.
• Verification: Whenever Postgres reads that page back from disk, it immediately recalculates the checksum from the data and compares it to the stored value.

If the two values do not match, it means the data page has been altered or corrupted since it was last written. This is important because data corruption can happen silently. By detecting a mismatch, Postgres can immediately raise an error and alert you to a potential problem. Checksums are also an integral part of pgBackRest which uses these checksums to verify backups.

What is initdb and why does it matter?

The initdb command in Postgres is the utility used to create a new Postgres database cluster and initializes the data directory where Postgres stores all the permanent data. When you run initdb, it does things like:

1. create the directory structure
2. create the template databases like template1 and postgres
3. populate the initial system catalog tables
4. create the initial version of the server configuration files
5. enable and start keeping track of checkums

The syntax often looks something lik

Postgres Ibiza (PGIBZ): An open source conference designed to bring together people with a love for PostgreSQL in Ibiza, a relaxed place for fresh and innovative discussions. An international event run by the nonprofit PostgreSQL España.

This was the first time that the Data Bene team attended the event, and we’re happy to share that it was a very positive experience.

The Conference

Location and Venue

As its name suggests, this conference takes place on the Mediterranean island of Ibiza. For those who are less familiar, the Official Tourism Site provides a nice overview that you may refer to. While it should go without saying, this UNESCO World Heritage Site has incredible offerings outside of the conference itself. Combined with a potentially long-haul flight, it’s strongly recommended to plan an extra day or two (or more) to explore the island and enjoy the local experience.

The event itself is hosted at the Palacio de Congresos de Ibiza; a two-story conference center with multiple rooms and catering. Though located outside of the capital city, the venue can be reached by car in good timing (~15 minutes). To add, the venue is situated within walking distance of numerous hotels, restaurants, and a beach! We happened to have stayed at Hotel Tres Torres, which we can recommend, though admittedly it’s difficult to make a wrong decision, especially following a sprinkle of background research.

Briefly, on the topic of extracurriculars, our go-to recommendation would be to visit the capital city, Ibiza. There you will be able to find a surprisingly large amount of shopping, restaurants, and sightseeing. Adding to that a walk through the historic neighborhood and you’ve got quite the memorable experience.

Attendance

This year’s PGIBZ welcomed about 30-40 attendees from across the globe, including China and the United States. And while there are certainly two sides to the coin, I consider this group size as more of a positive. Indeed, during both the presentation Q/A sessions, as well

Postgres Ibiza (PGIBZ): An open source conference designed to bring together people with a love for PostgreSQL in Ibiza, a relaxed place for fresh and innovative discussions. An international event run by the nonprofit PostgreSQL España.

This was the first time that the Data Bene team attended the event, and we’re happy to share that it was a very positive experience.

The Conference

Location and Venue

As its name suggests, this conference takes place on the Mediterranean island of Ibiza. For those who are less familiar, the Official Tourism Site provides a nice overview that you may refer to. While it should go without saying, this UNESCO World Heritage Site has incredible offerings outside of the conference itself. Combined with a potentially long-haul flight, it’s strongly recommended to plan an extra day or two (or more) to explore the island and enjoy the local experience.

The event itself is hosted at the Palacio de Congresos de Ibiza; a two-story conference center with multiple rooms and catering. Though located outside of the capital city, the venue can be reached by car in good timing (~15 minutes). To add, the venue is situated within walking distance of numerous hotels, restaurants, and a beach! We happened to have stayed at Hotel Tres Torres, which we can recommend, though admittedly it’s difficult to make a wrong decision, especially following a sprinkle of background research.

Briefly, on the topic of extracurriculars, our go-to recommendation would be to visit the capital city, Ibiza. There you will be able to find a surprisingly large amount of shopping, restaurants, and sightseeing. Adding to that a walk through the historic neighborhood and you’ve got quite the memorable experience.

Attendance

This year’s PGIBZ welcomed about 30-40 attendees from across the globe, including China and the United States. And while there are certainly two sides to the coin, I consider this group size as more of a positive. Indeed, during both the presentation Q/A sessions, as well

In Part 1 we loaded our documentation into PostgreSQL. In Part 2 we chunked those documents and generated vector embeddings. Now it's time to put it all together with an API that your applications can use.
In this final post, we'll deploy the pgEdge RAG Server to provide a simple HTTP API for asking questions about your content. By the end, you'll have a working RAG system that can answer questions using your own documentation.

What the RAG Server Does

• Converts the query to a vector embedding

• Searches for relevant chunks using both semantic (vector) and keyword (BM25) matching

• Combines and ranks the results

• Formats the top results as context for the LLM

• Sends the context and query to the LLM

• Returns the generated answer

Prerequisites

• The database we set up in Parts 1 and 2, with documents and embeddings

• An API key for your chosen LLM provider (Anthropic, OpenAI, or local Ollama)

• Go 1.23 or later for building from source

Installing the RAG Server

Configuration

If you need to transition easily from Oracle to PostgreSQL without worrying about type conversions or other Oracle packages that require modifications to be PostgreSQL-compatible, a useful solution is IvorySQL!

Introduction

More and more companies are seeking to free themselves from the costs and constraints of Oracle by migrating to PostgreSQL. But how can this transition be achieved without spending months on it? Here is a proven, fast and secure method, based on feedback and open source tools.

Start by assessing and mapping

Before migrating, it is essential to take stock of the situation: we start by listing Oracle objects through performing a complete extraction (including tables, views, sequences, procedures, functions, and packages).

It is also important to communicate regularly with the client to refine findings and validate directions, as well as to identify dependencies (applications connected with which technology, jobs, interfaces, etc.).

Finally, identify the client’s Oracle-specific features (specific functions such as ROWID, DUAL, DBMS_XXX, etc.) and any other keywords requiring special attention.

Choosing the right open source tools

The success of a transition to PostgreSQL – because it is indeed a gradual transition and not a migration – depends as much on strategy as it does on tools.

It is not enough to simply copy objects: you need to understand the subtleties of the Oracle engine and intelligently transpose them into the PostgreSQL universe.

Among the essential tools, Ora2Pg plays a central role. Not only does it generate clear inventory reports, it also automates the conversion of schemas, data and PL/SQL code. It is a valuable accelerator for well-structured projects.

But in some contexts, the reality is more complex. Many customers accumulate significant technical debt, with thousands of lines of procedural code. Attempting to rewrite everything in PL/pgSQL in a short period of time would exhaust teams and compromise the migration itself. Maint