Forem: Abinand P

Embedding AI Inside PostgreSQL : Building a Native C++ Extension.

Abinand P — Wed, 19 Nov 2025 13:52:21 +0000

The Search for a Native Engine

As a developer who values performance and systems integrations, I felt limited by the common "Chat with DB" approach. That method often involves slow, external wrappers that pull data out of Postgres just to convert natural language into SQL. I wanted to know: why can't the database itself understand me??

My goal was a bit bold: to integrate AI directly into the Postgres kernel, making the database self-aware. This led me to a new domain, inspired by the ClickHouse open take-home challenge.

The Crucible: C/C++ Interoperability

The first major shock was realizing the true language of PostgreSQL extensions: C. This immediately created a conflict, as the powerful ClickHouse AI SDK I was required to use was written in C++.

The Conflict: C++ is incompatible with C headers, but Postgres only provides C headers.
The Magic: After some searching, I discovered the powerful solution: using the C/C++ mixing tool, extern "C". This allowed my C++ code to safely import and link against the C headers of PostgreSQL. This foundational lesson clarified the true purpose of header files in modular software development.

The package manager problem

With modern languages like TypeScript, Python, and Go, we take package managers for granted. Suddenly, I was back in the C++ world, where I learned that third-party library integration must be done manually.

To solve this, I created a CMakeLists.txt file. This configuration file became the linker and builder for my third-party libraries—the equivalent of the package.json I was used to in the Node.js ecosystem. This streamlined the build process and ensured I could properly package the extension.

How to connect System Tables

The next major hurdle was performance. Initial thoughts (and even AI suggestions) pointed toward using standard SQL functions (SPI_connect()) to query the database catalog for schema information.

The Problem: Running SQL queries internally is slow and adds overhead.
The Solution: I found that by diving into the PostgreSQL documentation, it was possible to access the schema names, table names, and columns directly by opening internal system tables using headers provided by Postgres. This was a massive performance win. By accessing the system catalogs directly, I ensured the AI had the necessary "ground truth" for prompting without adding unnecessary query latency.

AI Engine: With Controlling output

To ensure the system was reliable, I needed the AI output to be stable and predictable.

Structured Output : I moved the core logic to structured JSON output, ensuring the SQL was returned in a single, predictable field. This abstracted the AI's "quotes or explanations" and made the application robust.
Performance and Stability: I set the temperature to 0 in the prompt to ensure the output was grounded solely in the provided system context, reducing the chance of irrelevant output.

Distribution to users: A fight with Dockerfile

I created a Docker image to test the extension safely, but the image size ballooned to 1.8GB.

The Problem : The initial build contained the entire development toolchain and libraries needed to compile the C++ extension.
The Solution: I created a multi-stage build. The first stage compiled the extension, and the second, final stage took only the necessary runtime files (pg_ask.so, .control, .sql) and put them onto a fresh base Postgres image. This reduced the final image size back to a lean 500MB.

To try the extension

The final product, pg_ask, is a powerful extension that allows immediate use after a simple Docker command.

# Pull the image
docker pull ghcr.io/abiji-2020/pg_ask:latest

# Run with your API key
docker run -d \
  --name pg_ask \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -e PG_ASK_AI_KEY=your_api_key_here \
  -p 5432:5432 \
  ghcr.io/abiji-2020/pg_ask:latest

After the docker image started running we can query the database

-- Connect to your database
psql -h localhost -U postgres -d postgres

-- Create the extension
CREATE EXTENSION IF NOT EXISTS pg_ask;

-- Set up sample database to query 

-- Example query (shows the power of the extension)
SELECT pg_gen_query('count all users created in the last 7 days');

Conclusion

This project taught me that "Full Stack" means understanding the system at every layer. My ability to go low-level with C++, manage performance with internal Postgres APIs, and solve deployment issues with multi-stage Docker builds are the core lessons. If you want to build truly performant, integrated AI tools, sometimes you have to stop building wrappers and start building extensions.

You can also check the Source of my extension at : https://github.com/Abiji-2020/pg_ask

Mystic Writer : An Experiment on Agentic Development 🤖⚡

Abinand P — Wed, 22 Oct 2025 10:20:21 +0000

The Why ? 🤔

As a software developer exploring backend systems and automation, I wanted to test a bold idea :

Could I build a full-stack AI product - Backend, Authentication, Database, AI generation entirely through Agents, without writing a single line of code ?

The question became MysticWriter 🪶, an AI-powered story collaboration web application built in just two days using InsForge, Claude Haiku 4.5, and Figma Make.

My goal was to see what happens when developers stop coding line by line and start prompting their backends into existence.

What I built 🏗️🚧

MysticWriter lets users collaboratively write stories with AI, where user creates a story and the next line will be generated with AI and then along the way with back and forth communication between the humans and AI a complete story is created. It also generates a visual avatar for characters in the story as per need to have a visual effect of story.

All backend functionality such as authentication, database, story creation, bucket storage for generated images, and image generation was handled inside InsForge, an agentic-native BaaS that integrates seamlessly with AI through MCP (Model Context Protocol)

The frontend was designed in Figma Make, from prompts created the complete design and exported the design code to GitHub directly, just cloned the created Repository and then installed dependencies and started my frontend poof the design from figma is now in my local system.

The entire build from idea to working prototype happened over 48 Hours.

Here are some screenshots of the application 👇

Agentic Workflow 🪢🦾

Here's how the workflow actually unfolded :

I created an Insforge account and connected my MCP server from Insforge to Windsurf just with a simple command

 npx @insforge/install --client windsurf \
 --env API_KEY=your-api-key \
 --env API_BASE_URL=http://xxxxxxxx.insforge.app

Inside Windsurf, I used Claude Haiku 4.5 to issue structured prompts describing what I wanted InsForge to build things such as :
- "Create tables for users, stories and images. "
- "Add authentication and bucket storage for story images".
- "Setup AI collaboration for story and image generation".
Through the MCP connection, Claude communicated directly with InsForge tools to generate these backend resources, everything automatically just with AI-agents.
Whenever something went wrong (like field mismatch or auth misconfiguration), I'd prompt Claude again, and it would iterate or regenerate the setup.

Because Insforge is agent-native, everything from database creation to function deployment was prompt-driven! no SDKs, no CLI, no manual config.

Reflections After 48 Hours

This project was an eye-opener on how far agentic development has come.

Here’s what stood out:

✅ What Worked Really Well

Agent-native design: Insforge’s backend is natively accessible to AI agents through MCP! no hacks, no middle layers.
Instant visibility: The Insforge dashboard shows all created tables, functions, and AI credits, so I could track everything in real time.
Speed: From zero to a functioning app — with authentication, storage, and AI endpoints — in under two days.

What I missed ?

VS code as client : If Insforge has a VS code client along with Winsdsurf, Trae, Cursor, Claude Code, Cline it would be a nice to have.
BYOK : Bringing my own API Key for the AI models usage would be a nice to have feature, when I already have Keys for some models.

5. Tech Stack Overview

Tool / Platform	Purpose	Notes
Insforge	Agent-native BaaS	Handled auth, DB, AI calls, bucket storage, and function execution — all through prompts
MCP (Model Context Protocol)	Communication bridge	Enabled Claude to interface directly with Insforge from Windsurf
Windsurf	Agent workspace	Hosted the connected MCP server where I interacted with Claude
Claude Haiku 4.5	AI development assistant	Generated backend logic, fixed errors, and handled prompting
Figma Make	Frontend builder	Created the UI and connected it to Insforge APIs
MysticWriter	The final product	An AI storytelling app built entirely via agentic workflows

The Result

By the end of Day 2, MysticWriter was live and working:

Users could sign up, write stories, and generate illustrations.
AI endpoints handled the creative generation.
All data and media were securely stored through Insforge’s bucket and DB setup.

You can:

🌐 Try the Live Demo
💾 View the GitHub Repo

It’s a small MVP ,but a complete one and built entirely by prompting, not programming.

The Future of Agentic Development

Building MysticWriter in just two days fundamentally changed how I view development.

This wasn’t just “no-code"! It was agent-native.

With Insforge, MCP, and AI copilots like Claude, developers can focus purely on ideas and intent, while the agents handle the infrastructure and logic.

We’re moving from coding systems to collaborating with them and MysticWriter was my first real glimpse of that future.

Built between October 21–22, 2025

Proof that sometimes, two days and a few good agents are all you need.

PesudoCLI - your AI man pages.

Abinand P — Sat, 02 Aug 2025 12:50:12 +0000

This is a submission for the Redis AI Challenge: Beyond the Cache.

What I Built

This project is CLI tool built with Go(Cobra) that leverages Redis Stack for vector storage and Gemini API(Google's LLM) for both embedding and text generation.

This CLI tool demonstrates how Redis Stack can serve as a vector database, powering an intelligent question-answering system - all from terminal.

Instead of Redis being just a cache or pub-sub tool, I used it for storing high-dimensional embeddings and retrieving semantically relevant results using vector similarity search (KNN+cosine).

Tech Stack:

Go (Cobra) - CLI Interface
Gemini API - for both generating embedding and responding with LLM.
Redis Stack 8.x - as a vector store using FT.CREATE, HNSW and KNN retrieval.

Redis as a Vector Store

Traditionally, Redis is known as a caching layer. I have also started my Go journey with Redis as a caching layer. But in this project, Redis Stack is used to:

Store vector embeddings with metadata

Each chunk of input text is embedded using Gemini and stored as a document with the following schema:

Field	Type	Purpose
`Command`	TEXT	Original CLI Command name
`os`	TEXT	OS type or system
`text_chunk`	TEXT	The actual context (explanation of the commands)
`embedding`	VECTOR	Embedded vector (FLOAT32, 3072 dimension)

This is the basic schema I have created using the following command

FT.CREATE pesudo_index ON HASH PREFIX 1 doc: SCHEMA \
          command TEXT \
          os TEXT \
          text_chunk TEXT\
          embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 3072 \
          DISTANCE_METRIC COSINE

This enables semantic search directly in Redis - no separate vector DB required.

Retrieve relevant data via vector search

From the command line application when the user runs:

$ pesudocli ask "How to install packages on Arch?"

The CLI flows as :

Embeds the questions using Gemini
Performs a KNN vector search using FT.SEARCH with KNN 3.
Uses cosine similarity to rank results
Sends the top 3 context chunks to Gemini chat model as context.

Redis handles the entire retrieval part without latency or external systems.
During testing, vector search queries consistently returned results in around 150ms, demonstrating Redis’s real-time capabilities even for high-dimensional vector data.

⚙️ Behind the scenes: Vector search

Here's an example of a vector search query in Redis, which I have used:

FT.SEARCH pesudo_index "*=> [KNN 3 @embedding $vec]" \
     PARAMS 2 vec <binary_value_of_query>
     DIALECT 2

KNN 3 : Returns top 3 closest vectors
COSINE : Generally used method to find the distance between two vectors
DIALECT 2 : Required in Redis for vector support.

Under the hood, Redis uses HNSW (Hierarchical Navigable Small World) algorithm, which reduces the brute force check to reduce the latency and enabling efficient approximate nearest neighbor search in high dimensional space.

How to process user query 🧠

Demo

Since this is a CLI I have attached the image of the sample ask command here.

You can download and try the CLI from the github repo: PesudoCLI Release

How I Used Redis Stack

Redis Stack was crucial to enable Vector Search in this CLI. Here's how it fits into the pipeline:

Used Redis 8(via Redis Stack) to store vector embeddings created from chunks of input data.
The ingest command:
- Retrieves data from embed csv file,
- Uses Gemini to generate embeddings,
- Stores each chunk and its corresponding embedding vector in Redis using RediSearch, along with metadata.
The ask command:
- Converts user input into a vector using Gemini,
- Performs a KNN vector similarity search on Redis,
- Sends the top 3 matching contexts to Gemini chat model for response generation.

This combination of semantic vector search + LLM made it possible to build an intelligent CLI assistant.

🔧 CLI flow to run

This will give a overall complete run through of the cli code, and displays how the entire program should be run.


# Step 1: set config 
$ pesudocli config --gemini-api-key <your-key>

# Step 2: Init the index 
$ pesudocli init 

# Step 3: Ingest data 
$ pesudocli ingest 

# Step 4 : Ask a question 
$pesudocli ask "Explain about podman?"

After doing the initial 3 steps then we can ask any number of questions using the ask command.

Conclusion 💻

This project started with a simple idea: build a smart CLI assistant. But along the way, Redis Stack proved to be far more than a cache - it became the core of a semantic search engine.

By combining vector embeddings, KNN search with cosine similarity, and the Gemini API, I was able to build a fast, local-first and entirely terminal-bed AI assistant - without needing a separate vector database or LLM backend.

Redis Stack handled:

Real-time vector ingestion and search
Metadata filtering and schema management.
Seamless performance even with high-dimensional (3072-dim) vectors

All in all, this project shows how Redis Stack can unlock a new class of AI powered applications - from your terminal.

Thanks for reading - and thanks to the Redis team and Dev.to for hosting this challenge ! 🚀

Checkout the PesudoCLI project on Github to try it out or contribute.

Cover image is generated with Gemini, other images are generated with the help of napkin.ai, and text is modified using AI for grammar corrections

Stop abusing .env files 🔒

Abinand P — Wed, 30 Jul 2025 10:44:24 +0000

Let's be honest - we've all done it. Thrown a few secrets into .env file, pushed to github (oops), or spent 20 minutes debugging a typo like DB_PASSWROD 😵‍💫. When I started coding, .env files felt like magic. But when diving deeper into security it turns out, they're more like duct tapes - they work.. until they don't.

In this blog, I'll walk you through:

Why .env files are kind of overrated
The pain points of managing secrets traditionally
A better modern approach with tools like Infisical, Hashicorp vault.

🔐 The `.env` Era

Let's rewind a bit.
The idea of managing environment-specific configuration wasn't mainstream - until Heroku introduced Config Vars. This was back in the days when deploying with Heroku felt magic:

heroku config:set STRIPE_KEY=super-secret

Boom 💥 secret added, scoped to your app, environment-specific, and cloud-ready.

This was the first time developers really felt how clean and safe it could be to separate code from config. Inspired by this, .env files started showing up in local development tools to replace that behavior - but only with a plain text format, unencrypted approach.

Thus was born the env culture - a local hack around a powerful concept.

Why we use `.env` 🤔?

They're simple. You toss some key-value pairs in a file, and boom! Your app has access to secrets without hard-coding them. Better than putting your database password right inside your code, right?

DB_PASSWORD=dbpassword

And then in your application (I have taken Node.js):

process.env.DB_PASSWORD

Looks neat and easy right? But here comes the but.....

😬 What's wrong with `.env`?

Let's talk about the downsides. And trust me, they show up the moment you work in a team or try deploying to anything beyond your laptop.

1. Accidental Git Commit 🚨

Unless you religiously .gitignore that file, one bad git add . && git commit can leak secrets to the world. Try a GitHub search on .env boom we can have many most secure environment variables as plain text accessible to everyone 😟.

2. Sharing With your Team = Chaos

When you've got 3 developers, 1 QA, and a CI pipline - how do you make sure everyone has the same .env and that too the right one? You don't. You just hope it works.

3. No Audit Trail 🕵️

Did someone change the AWS Key last Thursday ? No idea. .env files have no versioning, no logs and can't even know if someone has tampered it - nada🙂‍↔️.

4. Copy - Paste Debugging Hell 🐛

Typos like STRIPE_SECRT will make you question life. No logs nothing, just empty message on the API call, just internal server error. Plus, some platforms want strings quoted, others don't. Python, Js, Linux - they all play by different rules.

5. Manual Updates Waste Time ⏳

The average developer loses 23 minutes recovering from a interruption when they are working in a serious mode. Manually syncing secrets across local, staging, production when trying to fix a bug that has been there for a week? That's a big productivity leak.

From Local Shell to Cloud-Native Secrets 🚀

This isn't the 2010s anymore. We've moved from FTP deployments to Docker, CI/CD pipelines, server-less, and remote teams. But many of us are still managing secrets like it's 2008. Come-on lets jump to the present 2025.

Now imagine this:

All your secrets in a secure, centralized vault
Environment-specific configs: dev, staging , prod
One-click rotation and versioning
Automatic syncing to your apps via tokens
Logs of who did what and when

That's where Infisical comes in.

Why Infisical Feels like superpower 💡

I've been using and playing around Infisical recently. It's just as their tagline - Secrets Management on autopilot. It solves many .env pain points without forcing you to change how you build things.

Here's what I love:

Centralized secrets Management ✅

No more emailing .env files or sharing over Slack. Just invite your team, and boom - everyone sees the right secrets for their environment.

Environment-based separation 🔁

Dev, Staging, Production - all organized separately. No more "wait which .env file is this?"

Tokens, Not Raw Secrets 🔐

Access secrets via revocable tokens - easy to manage, track and audit. More secure than giving full .env files to every intern.

Team Collaboration Built-in 👥

One teammate updates a secret, the whole team gets the latest values (unless you want local overrides - Infisical supports that too. ).

Audit logs & Version History 📜

Accidentally deleted a key? Need to know who made a change? Need to know when the change was made ? Infisical has you covered.

Ending Note: 🎯

.env files aren't evil - they were just never meant to scale with modern workflows. Remote teams, automated deployments, and containerized environments need something more robust, traceable and collaborative.

Infisical fills that gap beautifully.

TL;DR 📚

.env files are fine for solo hacks but break at scale.
They're hard to share, prone to typos, and lack security/audit feature
Modern apps need a better secret management strategy.
Infisical offers centralized, secure, team-friendly secret management.

Thanks for reading!!!
If this blog helped you think twice about .env files, or if you've faced similar struggles, drop a comment. I'd love to hear how you manage secrets in your projects.

Images are generated using Gemini 2.5 Pro, and the I have used the help from ChatGPT to check errors and grammar in the blog