I spent a week researching why devs hate Supabase, LangChain, PostHog & Neon (and what I found)

Mujib — Mon, 01 Jun 2026 14:16:02 +0000

If you hang out on Reddit or Hacker News long enough, you’ll notice a pattern. Every few days someone posts:

“Supabase RLS is driving me insane”
“LangChain is death by a thousand abstractions”
“Neon cold starts are killing my API response times”
“PostHog autocapture is just noise”

I’ve used all four tools. And yeah, I’ve felt the pain. But I wanted to know: how bad is it really? Not just vibes, but actual hours lost. So I did something stupid for a student with free time.

I researched it Properly.

I read through GitHub issues, Reddit threads, Hacker News comments, and Discord rants. I even used AI to help me aggregate and categorize the complaints. (Yes, AI helped - I’m not hiding that I’m a student, not a journalistic purist.)

Here’s what I learned -

The short version:

Add it up for a team using all four? That’s 40+ hours a week of non-feature work. Basically one engineer just fighting tools.

And here’s the kicker: a lot of these problems already have solutions. People just don’t know about them.

Supabase RLS — the biggest trap
Supabase markets itself as “build in a weekend” But then you hit Row Level Security.

“I know I should learn Postgres better, but I feel misled.” — some Reddit user, speaking for thousands.

RLS policies aren't just access rules. They're PostgreSQL expressions that run inline with every query. When they fail, you get a generic “permission denied” and zero clue why.

One engineer said debugging RLS means opening nine different log tabs and manually correlating timestamps. Nine tabs For one bug.

LangChain — why I’m glad I didn’t build my AI agent with it
I almost used LangChain for Kommit (my AI commit CLI). Thank god I didn’t.

People describe debugging LangChain as “peeling an onion of abstractions until you cry” A simple API call becomes: PromptTemplate → OutputParser → Chain → AgentExecutor → LCEL pipe operators.

One team removed LangChain entirely after a year. They said: “We spent as much time understanding LangChain internals as building features”

The worst part? Hidden LLM calls. One developer reported an agent that called the wrong tool 14 times in a loop and burned $40 of API credits before returning gibberish.

My take: Use the raw OpenAI/Anthropic SDK unless you really need agent orchestration. LangGraph is better but still complex.

PostHog — the data cleanup tax
PostHog’s autocapture is both a blessing and a curse It tracks everything Clicks, rageclicks, form submissions, you name it.

But then you spend hours filtering out the noise

One GitHub issue I found: a developer was trying to stop $rageclick events from firing when users click up/down arrows on a date picker. Normal behavior Not a rageclick

PostHog has a “drop events” transformation, but that’s reactive. You’re cleaning up after the mess

What works: Disable autocapture from day one and implement explicit event tracking with a schema. Boring, but saves weekends

Neon — serverless is cool until it sleeps
Neon’s scale-to-zero saves money. But when your database wakes up, you get a 300-700ms cold start. On the free tier, it’s even worse.

And the connection pooling? It uses PgBouncer in transaction mode. That means SET search_path and prepared statements break. Your app works locally (direct connection) but fails in production (pooled connection). Fun times.

Fix: Set a minimum compute size to keep it warm or accept the cold start. Also maintain two connection strings - one pooled, one direct for migrations.

The pattern I didn’t expect
Almost every problem falls into three buckets:

Leaky abstractions - the tool hides complexity until it breaks, then you need to understand the internals anyway.

Configuration fatigue - too many env vars, YAML files, and dashboard settings that interact in weird ways.

Data/schema drift - changes made in dashboards instead of migrations, or events accumulating without governance.

None of this is new. Joel Spolsky wrote about leaky abstractions in 2002. But somehow every new tool repeats the same mistakes.

What I’m doing with this
I’m not writing this to bash the tools. They’re all well-engineered and solve real problems.

But as a student looking for an internship, I wanted to understand: what do engineers actually hate? Because if I can build something that fixes a small piece of that, maybe I can get paid to build it instead of fighting it.

I already have a few ideas. But first, I’m turning this research into a small series on Dev.to. Next post will be: “Three unsolved problems I found in the research (and what I’m building next).”

One last thing
If you’re using Supabase, LangChain, PostHog, or Neon - what’s your biggest pain point? I’m genuinely curious. I might try to build a fix for one of them.

Drop a comment or Find me on GitHub or Dev.to

– Mujib, sophomore who spends too much time in the terminal.

How I Built a Real-Time PostgreSQL WAL Reader in GO

Mujib — Sat, 09 May 2026 08:41:40 +0000

Most developers use PostgreSQL every day without knowing
what happens under the hood when they run an INSERT. I
wanted to find out. So I built pgstream — a tool that
reads every database change in real time directly from
PostgreSQL's internal log.

What is the WAL?

Every time you insert, update, or delete a row, Postgres
doesn't immediately write to the actual data files. It
first writes the change to a file called the WAL — Write
Ahead Log. This is how Postgres guarantees nothing gets
lost if the server crashes mid-write.

I had read about WAL in docs before but never really
understood why it existed until I started building this.
It clicked when I realized — the WAL is basically a
journal. Postgres writes every intention down first,
then acts on it.

Logical Replication and pgoutput

WAL records are stored in raw binary. You can't just
read them like a text file. Postgres has a built-in
plugin called pgoutput that decodes that binary into
readable messages — INSERT, UPDATE, DELETE — with the
actual row data included.

To read from the WAL stream your program creates a
replication slot. Think of it as a bookmark. Postgres
tracks your position in the stream and holds WAL records
until your reader has consumed them. This means you can
stop and restart your reader without missing any changes.

Building pgstream

I built pgstream in Go using the pglogrepl library which
handles the low level replication protocol. The project
has four main parts:

Connector — opens a replication connection to Postgres
and creates the slot.

Decoder — this was the hardest part. It reads raw bytes
coming from Postgres and figures out what each message
means. Postgres sends different message types — Relation
messages that describe table schemas, Insert messages,
Update messages, Delete messages, and keepalive
heartbeats. The decoder has to handle all of them
correctly.

The tricky part was the Relation message. Before Postgres
sends an INSERT event it sends a Relation message
describing the table structure — column names, types.
You have to store that and reference it later when
decoding the actual row data. Without this you get raw
bytes with no idea which column is which.

Handler — takes the decoded event and prints it cleanly
to the terminal.

The part that surprised me

What surprised me most was how fast it is. The moment
you run an INSERT in pgAdmin the change appears in the
terminal almost instantly. There is basically no delay.

I knew replication was fast in theory but seeing it
happen live made it real. This is the same mechanism
companies use to sync databases across regions in
real time.

What I learned

I understood Postgres as a database before this. Now I
understand it as a system. WAL, logical decoding,
replication slots, LSN — these are the internals that
make Postgres reliable at scale.

Go was also new to me coming from JavaScript and C.
The concurrency model with goroutines and channels
is genuinely different from anything I had used before.

Try it yourself

pgstream is open source.
github.com/mujib77/pgstream

If you want to understand what's happening inside your
Postgres database — clone it, run it, and watch your
changes stream in real time.

DEV Community: Mujib