DEV Community: Chizee

Stop Recomputing Your Dashboard on Every Page Load

Chizee — Sun, 27 Sep 2026 10:11:50 +0000

A dashboard that runs a heavy aggregation against live tables works fine in a demo and then crawls in production, because every single page load recalculates the same numbers from scratch. The usual fix is piping everything into a dedicated warehouse like Snowflake purely so the dashboard has something fast to read.

For a huge share of "internal dashboard" use cases, a materialized view does the same job with zero new infrastructure.

Pre-bake the aggregation

CREATE MATERIALIZED VIEW daily_revenue AS
SELECT date_trunc('day', created_at) AS day, sum(total) AS revenue
FROM orders
GROUP BY 1;

CREATE UNIQUE INDEX ON daily_revenue (day);

That unique index is not optional decoration — I confirmed this directly by dropping it and trying to refresh: Postgres refuses outright with cannot refresh materialized view "daily_revenue" concurrently, and tells you exactly why. It's the single most common way this recipe trips people up, so build the index in from the start.

Refresh without locking out readers

REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue;

CONCURRENTLY recalculates in the background and hot-swaps only the changed rows into place — anyone reading the view mid-refresh sees the old data until the swap completes, never a lock, never a blank dashboard.

SELECT * FROM daily_revenue ORDER BY day DESC LIMIT 30;

Your dashboard just reads this like any other table. No ETL pipeline, no separate job runner — the "transform" step is the view definition.

Put it on a schedule with zero extra infrastructure

If you have pg_cron available:

SELECT cron.schedule('refresh-daily-revenue', '*/15 * * * *',
  'REFRESH MATERIALIZED VIEW CONCURRENTLY daily_revenue');

Scheduled refresh, running inside the database you already have.

Why this beats a dedicated warehouse for most dashboards

No ETL pipeline to babysit — the transform step is a SQL view.
Dashboards stay fast as data grows, since they're reading pre-computed numbers, not raw transaction history.
You control the refresh cadence directly — hourly, nightly, or on demand, it's one command either way.

Where Snowflake still wins

Ad-hoc analytical queries across terabytes of historical data, joining many large fact tables in ways your operational schema was never modeled for. If your "warehouse" need is really "make this one dashboard fast," you may not need one.

This is one of eight infrastructure swaps in Just Use Postgres, a 24-page field manual on replacing MongoDB, Redis, Elasticsearch, Pinecone, and more with the database you're probably already running. Every recipe in it — including this one — was run against a live Postgres instance before it went in the book.

👉 Get the field manual — launch price $14 instead of paying a warehouse to pre-compute two numbers: https://payhip.com/omenabyte
🐳 Or take the $24 bundle with the full docker-compose up starter repo — all 8 modules as tested, runnable migrations + seed data: https://4693433176360.gumroad.com/

Read this on omenabyte.com → https://omenabyte.com/blog/replace-snowflake-dashboards-with-materialized-views

You're Doing Vibe-Coding Wrong. Here's the 17-Point Fix.

Chizee — Sun, 20 Sep 2026 10:59:39 +0000

Nobody tells you this about the app you shipped last weekend: it's probably leaking.

Not "might be" leaking. Probably leaking right now, to anyone who opens DevTools and spends four minutes looking. That isn't a scare tactic. Multiple independent scans run over the past year against thousands of AI-built apps landed on the same conclusion, and the details get worse the further you read.

What the scanners actually found

Three research groups scanned thousands of AI-generated web apps built with Lovable, Bolt, v0, Replit, and Cursor. The numbers line up uncomfortably well.

Vibe App Scanner ran 1,215 scans across 1,119 distinct apps between December 2025 and August 2026. 10.4% had at least one critical issue. 31.1% had something critical or high severity. Of the 359 apps using Supabase, which was 29.5% of the sample, 141 of them had a row-level-security or data-exposure problem that let information be read without authorization. That's 39.3%.

Symbiotic Security crawled 65,643 URLs, confirmed 1,085 Supabase-backed sites, and scanned 1,072 of them. They logged 6,185 vulnerabilities. 98% of sites had at least one. 16% had a critical one. Only 26 of the 1,072 came back completely clean.

Worth stating plainly: that 98% applies to Supabase-backed apps in their sample, not every AI-built app everywhere. And Vibe App Scanner flags its own bias in the other direction — their apps were voluntarily submitted by owners who already suspected a problem, so those rates over-represent risk, and 83% of their scans were the reduced quick-scan set. Their words: every prevalence number is a floor, not a ceiling. Read the two studies together and the honest read is "unusually bad, uncertain how bad."

Two percent clean. That's the rate in the larger sample.

The specific failures

172 sites let anyone delete records from the database without logging in. One DELETE request using the public key wipes entire tables.

39 sites had tables fully readable by anyone holding the Supabase anon key, which is embedded in the page's JavaScript by design. So "holding it" just means "viewed source." Among those tables: payments, admin_users, and chat_messages.

308 sites exposed the anon key in JavaScript. On its own that's expected, it's a public key. The problem is what happens when no RLS policy exists behind it.

34 sites had columns containing emails, hashed passwords, auth tokens, and phone numbers, all directly queryable through the Supabase REST API.

None of this is theoretical. CVE-2025-48757 is the one that made headlines. A researcher scanned 1,645 apps from Lovable's official showcase, found 170 with critical flaws, and the same root cause kept showing up. Missing row-level security. MITRE scored it CVSS 9.3 Critical, though Lovable disputes the rating on the grounds that each customer is responsible for their own app's data, and the researcher later published his own scoring at 8.26. NVD lists the record as disputed. The vulnerability itself, insufficient RLS in generated sites through April 2025, isn't in dispute.

Separately, a February 2026 report found an EdTech app with 16 vulnerabilities, 6 of them critical. 18,697 user records exposed, including 14,928 unique emails and 4,538 student accounts from K-12 schools plus UC Berkeley and UC Davis. The auth logic was inverted. It blocked logged-in users and let anonymous visitors straight through.

Then there's Moltbook, an AI-agent social network. Wiz Research found zero RLS on any table. 1.5 million API tokens for OpenAI and Anthropic, 35,000 email addresses, and private messages, all reachable with the public key.

Why this keeps happening

Supabase turns row-level security off by default when you create tables through SQL. The Dashboard Table Editor defaults to on, but AI coding tools generate SQL migrations. They don't click through a Dashboard. So every table the AI creates starts unprotected.

There's a documented pattern for what follows, called the fix loop. Palo Alto's Unit 42 described it. The AI writes a query, PostgreSQL returns error 42501 (insufficient privileges, which is RLS doing exactly its job), and the AI "fixes" the error by dropping the RLS policy. The query works. The table is now open. Nobody notices, because the app appears to function.

Carnegie Mellon measured the underlying gap. 61% of AI-generated code is functionally correct, but only 10.5% is secure. Auth code is where that difference draws blood.

It isn't only Supabase either. 38 apps across all platforms shipped hardcoded API keys in their JavaScript bundles. On Bolt.host, 17 of 251 apps. On Vercel's AI-generated apps, 18 of 67, which is 26.9%. One Replit app shipped Anthropic, OpenAI, and Google keys at the same time. Those keys bill per token. A leaked OpenAI key powering a loop can burn hundreds of dollars overnight.

Security headers are missing almost everywhere. 93.6% of scanned apps had no Cross-Origin-Resource-Policy. 78.4% had no Content-Security-Policy. 70.6% had no X-Frame-Options.

The common thread, as one report put it: AI code generators optimize for "does it work?" and not "is it safe?" Your prompt never said "add auth middleware to every endpoint" or "never embed API keys client-side," because neither is a functional requirement. The code works perfectly in a demo and fails catastrophically in production.

The 17-point checklist

Work through this list. It applies whether you built with Lovable, Bolt, v0, Cursor, Replit, or by hand.

Protect admin routes. Every admin path needs an auth check on the server, not a hidden link or a client-side conditional. If the route renders, the route is reachable.
Server-side permissions. Authorization decisions belong on the server. Anything the browser enforces, the browser can edit.
Enable RLS. Run ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; for every table in the public schema, then ALTER TABLE your_table FORCE ROW LEVEL SECURITY; so policies can't be bypassed. RLS with no policies locks the table entirely, which is safe but probably not what you intended. Write policies scoped to the row's owner, not to "any authenticated user." Then verify as anon, not as a logged-in test user. Most of the data-exposure findings above exist because the check was skipped for the anonymous public key, which is embedded in your page's JavaScript by design. One read is enough: const supabase = createClient(url, anonKey); const { data } = await supabase.from('payments').select('*').limit(1); Returning rows before anyone signs in is the tripwire. It also catches the policy-exists-but-does-nothing case: using (true) on a select passes an RLS-enabled scan while exposing every row to anon. Enabled is not the same as enforced.
Verify email addresses. A confirmation flow that doesn't confirm anything is decoration. Turn it on and test it.
Hash passwords securely. bcrypt, scrypt, or Argon2. Never SHA-256, never MD5, never plaintext.
Keep tokens out of local storage. Any script on the page can read localStorage. Session tokens belong in httpOnly, Secure, SameSite cookies.
Server-side API secrets. No keys in client code. Check your NEXT_PUBLIC_ and VITE_ variables specifically, because those prefixes mean "bundle this into the JavaScript that ships to every visitor." A service_role key in client code bypasses every RLS policy you wrote.
Parameterized SQL queries. Never concatenate user input into a query.
Validate form inputs. Server-side, with a schema. Client-side validation is a UX feature, not a security control.
Block cross-site scripting. Escape output, avoid dangerouslySetInnerHTML with untrusted content, set a Content-Security-Policy.
Validate file uploads. Check type and size, and never trust the filename. Don't serve uploads from the same origin as your app.
Verify webhook signatures. An unverified webhook endpoint accepts forged events from anyone who guesses the URL.
Rate limit requests. Login, signup, password reset, and anything that sends email or costs money.
Tighten CORS settings. No wildcard origins on authenticated endpoints. Origin reflection with credentials enabled means any website can make authenticated requests on a logged-in user's behalf.
Disable production debugging. Debug endpoints, verbose stack traces, GraphQL introspection, and source maps should all be off.
Update dependencies. Run the audit, fix what it flags.
Run an actual security review. Anthropic open-sourced claude-code-security-review under MIT. It's a GitHub Action that comments findings on your PRs, and Claude Code ships a /security-review slash command that does the same analysis. One caveat worth knowing: the action is not hardened against prompt injection, and Anthropic's own README says to use it only on trusted PRs. Set your repo to "require approval for all external contributors" first.

Two things people get wrong

The checklist is worth nothing if you skip these.

Confirm your .env files are actually excluded from Git, not just that they should be. Run git check-ignore .env and make sure it returns a match. If a secret ever reached a commit, rotating it is the only real fix. Rewriting history is cleanup, not a cure.

Then confirm sensitive data stays out of your logs. Logs get shipped, aggregated, and read by more people than you think. Never log tokens, passwords, full request bodies, or PII. Check your error handlers specifically, because that's where request objects get dumped wholesale.

Where this leaves you

Your app probably works. That's the part AI genuinely got good at. The security defaults underneath it are a different story, and the pattern across thousands of scanned apps says most of them haven't been touched.

None of this is expensive or exotic to fix. RLS is a policy on a table. Keeping a key server-side is moving a file. A CSP header is a config line. A large share of the exposures found in these scans were one default away from not existing.

Go check your tables. Start with the ones holding user data.

Billions of Log Rows, One Command to Make Them Disappear

Chizee — Sun, 20 Sep 2026 10:07:56 +0000

Telemetry and event logs only grow. Dump them into one giant table and every query — even one scoped to a single day — ends up scanning far more data than it needs to. That's usually the exact moment a team reaches for a dedicated time-series database like InfluxDB.

Two native Postgres features cover most of what people reach for InfluxDB to get: declarative partitioning and BRIN indexes.

Split the table without splitting the app

CREATE TABLE events (
  id          bigserial,
  event_time  timestamptz NOT NULL,
  payload     jsonb
) PARTITION BY RANGE (event_time);

CREATE TABLE events_2026_06 PARTITION OF events
  FOR VALUES FROM ('2026-06-01') TO ('2026-07-01');

One note that will save you a confusing error: id is deliberately not a primary key here. On a partitioned table, any unique or primary key constraint has to include the partition column. If you need one, it's PRIMARY KEY (id, event_time).

A featherweight index built for this exact shape of data

CREATE INDEX idx_events_time_brin
  ON events USING BRIN (event_time);

A BRIN (Block Range Index) stores just the minimum and maximum value for each physical block of disk, instead of indexing every single row the way a B-Tree does. For data that arrives roughly in time order — which almost all event data does — that's enough to skip millions of irrelevant pages instantly, at a fraction of a B-Tree's size.

SELECT count(*) FROM events
WHERE event_time BETWEEN '2026-06-10' AND '2026-06-11';

Run EXPLAIN on that and you'll see the planner only touches the one relevant partition — the rest are pruned before the query even runs.

Retention becomes a metadata operation

DROP TABLE events_2026_06;

That's it. No DELETE scan, no bloat left behind to vacuum. Dropping a partition removes its rows instantly — I tested this directly: 500 seeded rows, one DROP TABLE, zero rows left, no measurable delay.

Why this beats a dedicated time-series database

Retention policies are a DROP TABLE, not a scheduled bulk delete job.
BRIN indexes cost a sliver of what an equivalent B-Tree would.
It's the same SQL as the rest of your schema — no separate query language, no separate client library.

Where InfluxDB still wins

Purpose-built downsampling and retention policies out of the box, at ingest rates in the millions of points per second. If you're managing your own partitions and indexes comfortably below that, you're not missing anything by staying on Postgres.

👉 Get the field manual — launch price $14 instead of scanning a billion-row table for yesterday's data: https://payhip.com/omenabyte
🐳 Or take the $24 bundle with the full docker-compose up starter repo — all 8 modules as tested, runnable migrations + seed data: https://4693433176360.gumroad.com/

Read this on omenabyte.com → https://omenabyte.com/blog/replace-influxdb-with-partitioning-brin

You Don't Need MongoDB for "Flexible" Data. You Need One Column Type.

Chizee — Sun, 06 Sep 2026 10:14:11 +0000

Product catalogs, form submissions, webhook payloads — a lot of real data genuinely doesn't want a fixed schema. The usual response is reaching for MongoDB purely for that flexibility, which means a second connection pool, a second backup strategy, and a second place your data can quietly drift out of sync with the relational tables that still describe your users and orders.

jsonb solves the actual problem — flexible structure — without giving up the database you already trust for everything else.

Store anything

CREATE TABLE products (
  id          bigserial PRIMARY KEY,
  name        text NOT NULL,
  attributes  jsonb NOT NULL DEFAULT '{}'
);

CREATE INDEX idx_products_attributes
  ON products USING GIN (attributes);

Use jsonb, not json. The binary form is stored decomposed at write time instead of as text re-parsed on every read — that's the difference between something you can actually index and something you can only display.

Query it like you mean it

SELECT name FROM products
WHERE attributes @> '{"color": "red", "size": "M"}';

The GIN index makes this fast the same way a book's index works: it maps individual keys and values straight to the rows that contain them, instead of scanning every row to check.

The part MongoDB genuinely can't do as cleanly

SELECT p.name, o.order_date
FROM products p
JOIN order_items oi ON oi.product_id = p.id
JOIN orders o ON o.id = oi.order_id
WHERE p.attributes->'specs'->>'material' = 'leather';

That's a document-style attribute joined directly against relational order history, in one statement, inside one transaction. Try that across two databases and you're writing application-layer stitching code — and hoping nothing changes between the two calls.

Why this beats standing up a document database

One transaction, not two systems — the "document" and the relational rows referencing it commit or roll back together.
No sync jobs, because there's no second database to keep consistent.
You can still join it, which is the thing you actually lose by going full-document.

Where MongoDB still wins

Genuinely schema-less workloads at a write scale where horizontal partitioning across many nodes is a day-one requirement, or built-in multi-region active-active replication out of the box. Most projects reaching for Mongo on day one aren't actually at that scale yet.

👉 Get the field manual — launch price $14 instead of multiplying connection pools, backup jobs, and consistency headaches: https://payhip.com/omenabyte
🐳 Or take the $24 bundle with the full docker-compose up starter repo — all 8 modules as tested, runnable migrations + seed data: https://4693433176360.gumroad.com/

Read this on omenabyte.com → https://omenabyte.com/blog/replace-mongodb-with-jsonb

Your AI Feature Doesn't Need Pinecone. It Needs pgvector.

Chizee — Sun, 30 Aug 2026 22:50:42 +0000

Launch Workspace — "Just Use Postgres" Week 3 (Article 3 / Week 4)

Dev.to title: Your AI Feature Doesn't Need Pinecone. It Needs pgvector.
Slug: /blog/replace-pinecone-with-pgvector
Canonical URL: https://omenabyte.com/blog/replace-pinecone-with-pgvector
dev.to tags: postgres, ai, vectordatabase, tutorial
Cover: https://omenabyte.com/blog/just-use-postgres-cover.png
Series: The Field Manual Series
Medium topics: PostgreSQL, Databases, SQL, Web Development, Software Engineering

Your AI Feature Doesn't Need Pinecone. It Needs pgvector.

The moment a project needs semantic search or RAG, the instinct is to bolt on a dedicated vector database. It works fine right up until you need a semantic match and a relational filter at the same time — "find documents like this one, but only ones this specific user wrote" — and now you're querying two separate systems and stitching results back together over a network call.

pgvector puts the embedding in the same row as everything else about the thing it describes, so that query is just... a query.

The setup

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id          bigserial PRIMARY KEY,
  author_id   bigint REFERENCES users(id),
  content     text,
  embedding   vector(1536)
);

CREATE INDEX idx_documents_embedding
  ON documents USING hnsw (embedding vector_cosine_ops);

HNSW (Hierarchical Navigable Small World) builds a multi-layered graph over your vectors — think of it as a high-dimensional skip list — so approximate nearest-neighbor search stays fast as the table grows.

The query that used to need two databases

SELECT content FROM documents
WHERE author_id = 42
ORDER BY embedding <=> '[0.012, -0.045, 0.031, ...]'::vector
LIMIT 5;

Semantic ranking and a relational filter, one round trip, one transaction, one system to keep consistent.

The gotcha nobody mentions

Here's something worth knowing before you ship this: with an approximate index like HNSW, Postgres fetches the nearest candidates first, then applies the WHERE clause after. If author_id = 42 is a narrow slice of a large table, you can get back fewer than 5 rows — not an error, just a quietly short result.

The fix, if you're on pgvector 0.8 or newer:

SET hnsw.iterative_scan = 'strict_order';

This keeps scanning until the filter is actually satisfied instead of settling for whatever the first pass turned up. Worth checking your version — SELECT extversion FROM pg_extension WHERE extname = 'vector'; — since some package managers (looking at you, plain apt) ship versions old enough not to have this option yet.

Why this beats a dedicated vector database for most teams

Embeddings and the rows they describe are written in the same transaction — they can never drift out of sync.
Hybrid search (semantic + relational) is a single query instead of an application-layer join.
One fewer vendor, one fewer bill.

Where Pinecone still wins

Billion-vector scale, with dedicated horizontally-sharded ANN infrastructure and managed elastic scaling. If you're not there yet, you're paying for infrastructure you don't need.

👉 Get the field manual — launch price $14 instead of walking into a $50/month managed-vector invoice

🐳 Or take the $24 bundle with the full docker-compose up starter repo — all 8 modules as tested, runnable migrations + seed data: https://4693433176360.gumroad.com/

Read this on omenabyte.com → https://omenabyte.com/blog/replace-pinecone-with-pgvector

I Watched a Man's Certainty Evaporate in Real Time

Chizee — Sun, 30 Aug 2026 09:51:37 +0000

The most dangerous hacker in the room never touched a keyboard.

Or: why "I use strong passwords" is the least effective security strategy you own.

There's a story we tell ourselves about security. It goes like this: as long as I use strong, unique passwords, enable two-factor authentication, and never click on anything even slightly suspicious, I'm one of the safe ones.

I told myself that story for years. Then I watched a woman break it apart in real time — through a screen, on someone else's podcast — and it rattled me more than I expected it to.

The man in the hot seat ran a security-focused YouTube channel and podcast. He'd built his entire platform on exposing scammers and teaching everyday people how to outsmart them. Two-factor authentication? On. Passwords? Long, random, different on every damn site. Sketchy links? Never touched them. By every checklist the internet had ever handed him, he was bulletproof.

He sat down across from Rachel Tobac — CEO of Social Proof Security, one of the best social engineers on the planet — and offered her a challenge: research me. Try to break me.

A few sentences later, the smug was gone.

She said his full legal name — bleeped for the audio, the name he'd gone out of his way for years to never use publicly. Then she told him where he was from. Then she named the city. Then she started pulling out the strange, buried details of an old life — a competitive program he'd almost forgotten, a hobby he'd packed away years ago, even an America's Got Talent audition that never made it to air.

He stopped looking her in the eye. His hands went cold.

She hadn't hacked his computer. She hadn't cracked a single password. She hadn't touched a single line of code. She had done something far more dangerous: she had hacked him.

The uncomfortable truth: you're the weakest link

Social engineering isn't hacking computers. It's hacking the operating system that runs them: you.

And here's what decades of data breaches, security research, and live demonstrations keep proving — the strongest technical defense in the world becomes meaningless the moment a stranger can convince a human being to open the door:

"Everyone can be hacked except you. You've got two-factor authentication turned on. All of your passwords are super strong. … But you're still not safe from this person." — Rachel Tobac

The attacks that actually work aren't glamorous. They don't involve servers or exploit chains. They're:

A 30-second phone call. Rachel's first professional engagement: she called an executive's assistant, pretended to be from finance, and got everything she needed — the kind of information that could move company money — in thirty seconds. She didn't attack the gatekeeper's boss. She attacked the person whose job is to be agreeable.
MFA fatigue. Attackers don't break your two-factor authentication. They spam it — push notification after push notification at 11pm, until you're tired and annoyed and just want it to stop. Then you hit accept, and the game is over. Around half of people admit to reusing passwords (Google's survey), which is what makes the spam worth sending.
Caller ID that lies. Your phone displays a name and photo for numbers in your contacts. Attackers can make a call display as if it's from your bank — or your mom. In the interview, Rachel did something she'd never done on air: she called the host live, by phone, in front of his co-host and millions of listeners. He knew it was happening, in real time, and still almost went for it. His words afterward: "I'm still reeling from that."

The scariest part isn't that an expert got caught. It's that he wasn't special. The words that broke him would work on almost anyone in that room.

The 10 rules of being politely paranoid

The good news: if the game is two steps — build rapport, make a plausible ask — then the defense can be taught in two steps too. When Rachel was asked for her final advice, she gave a phrase that's worth writing on a sticky note:

"Be politely paranoid — because the information that's out there for almost every person on the internet can be used to trick you, or the people around you."

Here are the ten rules distilled from that conversation. Screenshot this. Read it twice. Then teach it to your parents — scammers target them through their own kindness.

1. Alerts you didn't start are always suspicious. If a login push arrives and you didn't just log in — that's your first red flag. Don't accept, don't deny, don't trust anyone on the phone who insists you do.

2. Verify through a second channel — always. Anyone asking you to move money, reset access, or share a code gets one response: a fresh conversation on a channel you control. Call the number on the back of your card. A real request survives the check. A scam never does.

3. Slow down the moment someone creates urgency. "It has to be now" is a script, not a fact. Real systems don't panic you. Scammers do. Your superpower is refusing to rush.

4. Treat caller ID as a suggestion, not proof. Numbers and contact cards can be faked. If a call looks like your bank and starts asking for anything — verify on a number you dialed yourself.

5. One unique password per account. A breach at some forgotten 2016 site should cost you exactly one account — never the keys to your bank, your email, and your work. A password manager makes this painless.

6. MFA on, but never MFA by panic. Keep two-factor authentication everywhere. Just remember its one weakness: the accept button. Treat every prompt you didn't start as suspicious.

7. Be stingy with your face and your ID. You can rotate a password. You can cancel a card. You cannot change your face. Hand out biometrics and government ID as if they were the last copies on earth — because they effectively are.

8. Treat AI output like a stranger on the phone. Plausible doesn't mean true. Rachel has documented cases where AI reinforced people's delusions instead of correcting them — an agreeable machine that never tells you you're wrong. Verify anything important it tells you.

9. Be the wall for people around you. Scammers target your family and colleagues through their own kindness. Be the person who gently asks, "wait — did you actually ask for this?" before someone loses years of savings.

10. Keep playing whack-a-mole. Security is a habit, not a finish line. New scams will keep arriving. Don't tune out — spot the current one, defend, teach, move on. That's the whole game, and you can win it.

Why the machines make it worse (and better)

Rachel's warnings about AI are the most urgent part of the conversation. There's a real case of a well-known venture capitalist who spiraled into a false belief system — convinced he was being tracked by a shadowy organization — because the LLM he talked to validated his delusions, drawing on science fiction in its training data and presenting it as fact. No attacker involved. The danger was the tool itself: an agreeable machine that could not tell him he was wrong.

But there's a counterweight. The same technology that writes a perfect phishing email can catch the worst content on the internet so no human has to look at it. Rachel once interviewed for a job moderating content for a major social platform — the interviewer asked how comfortable she'd be seeing pictures of, say, children in cages. She didn't get the job, and she's glad. Some jobs are too horrible for humans, and those are the jobs the machines should do.

The honest forecast for AI security is roughly 50/50 — a perpetual whack-a-mole between offense and defense. The side that wins is the side that stays sharp.

The strongest password you'll ever have

Here's the line that closed the conversation, and it's worth sitting with:

The strongest password you'll ever have is the refusal to believe the last person who asked.

The scammers are praying you don't know what scams look like. They bank on urgency, pressure, and a phone number that looks exactly right. When you're politely paranoid — warm, human, but unwilling to act on urgency alone — you catch them every time.

I went so deep into this conversation — the 30-second hack, the MFA fatigue game, the live call, the AI psychosis cases, and the full defense playbook — that I turned it into a book. It's called Be Politely Paranoid, and it's the complete, chapter-by-chapter breakdown of how social engineers think and how to build your human firewall.

If this post resonated, the book goes deeper — every attack dissected, every defense explained, and the full 10-rule playbook you can print and stick on your wall.

→ Get Be Politely Paranoid here

It's the cheapest security upgrade you'll ever buy — and it protects the people you love, not just your accounts.

This article is an independent commentary on a publicly available interview. It is not authorized, endorsed, or reviewed by Rachel Tobac or Social Proof Security. Quotes have been lightly edited for readability.

The Prompting Gap Is the Only Gap Left

Chizee — Sun, 30 Aug 2026 09:51:24 +0000

There's an uncomfortable pattern I keep seeing.

Two developers, same repo, same version of Claude Code, same task. One of
them is done in ten minutes — tests written, PR open, moving on. The
other is twenty minutes deep in a back-and-forth, re-explaining context
Claude should've already had, watching it guess at requirements nobody
stated.

Same tool. Wildly different outcomes.

It's not a skill gap. It's not even an experience gap. It's a
vocabulary gap — and it's the last one standing between "I have an AI
coding assistant" and "I ship noticeably faster than I did six months
ago."

The tool got good before the instructions did

Claude Code can trace a bug from a vague symptom to a root cause. It can
read a Terraform plan and tell you what's about to break. It can turn a
CSV of ad performance into twenty new headline variations that fit under
a character limit. It can do a lot of things most people never ask it
to do — because most people never think to ask.

Anthropic has actually published a lot of this — scattered across a
Common Workflows guide, a best-practices doc, a "how our own teams use
Claude Code" writeup, and a few deep dives into how their legal and
security teams use it internally. Genuinely great material. Also,
genuinely annoying to piece together from six different pages when
you're mid-task and just want to know what to type.

So I pulled all 52 prompts into one place, organized them the way you
actually work — not alphabetically, not by topic, but by where you are
in the process — and turned it into a field guide. More on that below.
First, the part that actually matters more than any single prompt:

Six patterns, not fifty-two prompts

Here's the thing nobody tells you about "good" prompts: memorizing
someone else's exact wording only gets you so far. What's actually
transferable are the patterns underneath them. Learn these six and you
can write your own prompt for a problem no cheat sheet ever anticipated.

1. Describe the outcome, not the steps.
Say what you want and let Claude find the files.

add rate limiting to the public API and make sure existing tests still pass

2. Give it a way to check its own work.
Ask for run, test, compare, or verify in the same breath so it iterates
instead of stopping after one guess.

write the migration, run it against the dev database, and confirm the schema matches

3. Point at a reference.
Name an existing file or pattern to match. Without one, Claude defaults
to generic best practices. With one, it matches your conventions.

add a settings page that follows the same layout as the profile page

4. State the measurable target.
When the goal is performance or coverage, give the number. Ambiguous
goals get ambiguous effort.

get the bundle size under 200KB and show me what you removed

5. Give it the artifact.
Paste the error, the log, the screenshot, the plan output. Don't
describe the problem — hand over the evidence.

why is the build failing? @build.log

6. Say how you want the answer.
Name the format, the length, the audience. "Explain this" and "explain
this as a diagram I can show a PM" are two different prompts with two
different amounts of usefulness.

Once these six patterns click, you stop needing a cheat sheet for
everything. You just need one for the stuff you don't do often enough
to have memorized — which is exactly what the rest of this is for.

A few, to prove it's not just theory

One from each stage, straight out of the library:

Getting oriented in a repo you've never seen:

give me an overview of this codebase: architecture, key directories, and how the pieces connect

Scoping a change before you promise a timeline:

which files would I need to touch to add a dark mode toggle to settings?

Catching a risky change before you commit it:

review my uncommitted changes and flag anything that looks risky before I commit

Investigating an incident without five browser tabs open:

the checkout endpoint started returning 500s an hour ago. check the logs, recent deploys, and config changes, then tell me the most likely cause

Turning a one-off fix into something your whole team benefits from:

you keep using default exports when this project uses named exports. add a rule to CLAUDE.md so this stops happening

None of these are clever. That's the point. The unlock isn't cleverness —
it's specificity, evidence, and knowing what to ask for at each stage of
the work.

What's in the full library

52 prompts across five stages — Discover, Design, Build, Ship,
Operate — each with the exact wording, the technique it teaches, role
tags for PM/Design/Marketing/Docs/Security/Ops/Data (this isn't just an
engineering cheat sheet), and a "try next" tip for turning a good prompt
into a standing team habit instead of something you type from memory
every time.

23 pages. One download. Every prompt copy-paste ready.

Get The Prompt Library →

— Omenabyte Intelligence

1027 AI Image Slash Commands That Will 10x Your Prompt Game

Chizee — Sun, 30 Aug 2026 09:47:28 +0000

The `/imagine` trick that started a thousand cheat sheets

The secret nobody talks about: the most powerful image prompts aren't paragraphs. They're not even single sentences.

They're slash commands — shorthand modifiers you chain together like building blocks.

/portrait /1980s /bokeh /ar-3-4

That's a complete, professional image prompt in five seconds. And it works across Midjourney, DALL-E 3, Leonardo.ai, SDXL, Flux, and ChatGPT.

Here's how this shorthand revolution started — and why you should care.

The birth of `/imagine`

In March 2022, Midjourney opened its Beta to the public. Everyone got the same first instruction: type /imagine.

Not a long prompt. Not a style guide. Just one slash and a word.

Within weeks, Discord servers were exploding with people sharing their /imagine prompts — and a pattern emerged. The most prolific generators weren't writing paragraphs. They were dropping a few keywords, a style, a camera modifier. Something like:

/imagine prompt: a woman made of smoke / cyberpunk / neon / cinematic lighting / ar 16:9

That's not a sentence. It's a command sequence. And it was faster than English.

Fast-forward to 2026. The /slash convention has gone multi-platform:

ChatGPT image gen uses /imagine (inherited from Midjourney muscle memory)
Leonardo.ai supports /model, /style, /ar shorthand
Stable Diffusion web UIs use /ar, /q, /sameseed
DALL-E doesn't natively use slashes but follows the same compositional pattern

Each platform has 50–200 native modifiers. Combined? 500–1000+ composable commands.

Why slash commands beat full prompts (most of the time)

There's a trade-off every image generator runs into:

Full Prompt	Slash Command
✍️ Write a paragraph	✅ Drop a code
📱 Copy-paste is fragile	💾 Save and reuse
🔄 Hard to edit	🔗 Combine freely
❓ 800 tokens	🔢 5 tokens

Slash commands are deterministic shortcuts. You learn them like muscle memory — type /cyberpunk /neon /ar-16-9 and you know what you'll get before the image even renders.

The sweet spot: build a library of 20–30 core commands you know by heart, then chain them per project. That's what this 1027-command handbook distills.

The 5 categories you'll use 80% of the time

Not all 1027 commands are equal. Based on analyzing which ones ship most often:

1. 📐 Foundation Modifiers (30 commands)

These control the basics — the "what format" question.

/ar-16-9     → 16:9 (YouTube thumbnail)
/ar-1-1      → 1:1 (Instagram square)
/quality-high → 2x GPU / max detail
/stylize-medium → balanced artistic flair
/no-text     → bans text in output
/seed-pin    → reproducible seed

2. 🔦 Perspective / Camera (30 commands)

The "from where" question.

/lowangle   → low camera angle
/overhead  → top-down
/birdseye   → looking straight down
/pov        → first-person point of view
/ultra-wide → fish-eye wide angle

3. 🎨 Style & Medium (30 commands)

The "how does it look" question.

/photoreal   → photo realism
/oilpainting → oil on canvas
/cyberpunk   → neon-drenched sci-fi
/lowpoly    → geometric faceted look
/glitch-art  → digital corruption aesthetic

4. 💡 Lighting (26 commands)

The "mood" question.

/goldenhour  → warm evening light
/neonlight    → neon tubes/glow
/volumetric   → visible light rays
/ring-light   → creator/streamer setup
/lowkey       → high contrast shadows

5. 📱 Output Format (20 commands)

Where it lives — the "what shape" question.

/youtube-thumbnail → 1280×720 ready
/tiktok-cover      → 9:16 mobile
/poster            → 3:4 tall poster
/book-cover         → 2:3 A4-ish
/banner             → 16:7 wide

Master these 136 commands, and you can compose ~8,000 valid combinations without ever writing a full-sentence prompt.

Advanced: chaining for complex results

Here's where slash commands get dangerous. You're not limited to one per category:

/imagine: a lone astronaut / cyberpunk / neon / lowangle / goldenhour / rain / motionblur / ar-9-16 / no-text

That's one command chain producing a cinematic, specific, ready-to-post image. The astronaut is a modifier — it slots into any scene chain.

Power users chain 3 foundation + 3 style + 2 perspective + 1 lighting + output = 9 commands. That's more creative precision than a 100-word paragraph, and infinitely more editable.

What's in the full handbook

I didn't stop at the 136 power commands. The complete handbook covers all 1027 commands across 28 categories:

🎯  Foundation         (aspect, quality, model, seed)
📐  Technical          (CAD, blueprint, exploded view, cutaway)
🧪  Science/Medical    (DNA, anatomy, microscope, MRI)
📊  Infographics      (charts, flowcharts, dashboards)
📦  Product           (product shots, packshots, unboxing)
📣  Advertising         (ads for Meta, Google, billboards)
📱  Social Media       (IG, TikTok, YouTube, LinkedIn)
📸  Photography         (film stocks, lenses, bokeh)
🎬  Cinematic           (movie posters, noir, steampunk)
🌅  Lighting            (golden hour, neon, rim light)
🌍  Camera Angles       (drone, bird's eye, Dutch tilt)
🎨  Art Styles          (oil, manga, pixel art, stained glass)
🧊  3D/CGI              (Blender, Octane, ray tracing)
🏢  Architecture         (floor plans, modern, brutalist)
👤  People/Fashion       (headshots, runway, vintage)
🏎️  Vehicles/Machines    (cars, rockets, aircraft)
🧠  Concept/Creative      (cyberpunk, dystopian, surreal)
🏷️  Branding/Design        (logos, posters, style guides)
🖼️  Image Editing         (restore, inpaint, sky replace)
🗺️  Maps/Travel            (topographic, fantasy, metro maps)
🕰️  Historical/Vintage     (decade styles, daguerreotype)
🎨  Colors & Palettes      (duotone, neon, earth tones)
🧱  Textures & Materials   (concrete, marble, holographic)
🌿  Nature/Elements        (forest, storm, aurora)
🦁  Animals/Creatures       (wildlife, dragons, mythical)
🧸  Objects & Everyday       (typewriters, books, vinyl)
💭  Emotions/Concepts       (nostalgia, tension, wonder)
🌀  Abstract/Conceptual     (fractals, mandalas, neural nets)

It also includes:

✅ How-to-use cheat sheet (page 3) — 4 example combos with full breakdowns
✅ Compatibility matrix — which commands work on Midjourney vs DALL-E 3 vs Leonardo vs SDXL vs Flux vs ChatGPT
✅ 10 quick workflows — "turn your photo into anime," "generate a product catalog," "create a YouTube thumbnail set"

Grab the complete handbook

Building this library was a rabbit hole — I dug through Midjourney's v7 changelog, DALL-E 3's latest parameter updates, Leonardo.ai's 2025 feature drops, and the SDXL/Flux ecosystem to make sure every one of these 1027 commands has an accurate compatibility tag.

The result is a 34-page PDF — not a wall of text, but a scannable command matrix. Print it. Bookmark it. Stick it beside your monitor. In a week, /cyberpunk /neon /ar-9-16 /no-text will feel as natural as writing your name.

→ Get the AI Slash Commands Handbook on Gumroad

It's the one PDF you'll reach for every time you fire up an image generator — because once you start chaining commands, full-sentence prompting starts to feel archaic.

This handbook covers slash-command shorthand used by Midjourney, DALL-E 3, Leonardo.ai, Stable Diffusion, Flux, and ChatGPT image generation. Platform names and versions referenced are accurate as of August 2026.

Bonus: 5 chaining recipes for any style (dev.to edition)

Copy-paste any of these into Midjourney, Leonardo, or ChatGPT /imagine:

1. Cyberpunk portrait

/portrait /cyberpunk /neon /rain /ar-9-16 /stylize-high /quality-high

2. Product hero shot

/producthero /studio /softbox /glass-render /ar-16-9 /no-text /quality-high

3. Movie poster

/movieposter /cinematic /dramaticlight /ar-2-3 /stylize-medium /filmgrain

4. Educational diagram

/scientificdiagram /infographic /3dmap /colorize /ar-16-9 /labelled

5. Social media thumbnail

/youtube-thumbnail /viralthumbnail /boldad /highcontrast /ar-16-9 /no-text

Each chain = 1 foundation + 1 output format + 2–3 style/perspective modifiers. The full handbook gives you 1027 commands to remix however you want.

Open source Palantir tracking every plane, ship, satellite — built in a weekend

Chizee — Sat, 29 Aug 2026 09:21:14 +0000

Just read @chizee's deep dive on God's Eye View — an ex-Google Maps PM open-sourced a browser-based 3D globe tracking every aircraft, ship, satellite, and CCTV camera on Earth in real time, under MIT license. One Google Maps API key and that's it.

The internet called it "vibe-coded Palantir". Palantir's co-founder noticed. Within 48 hours, the whole thing was on GitHub.

What's wild: it runs in your browser, every line of code is inspectable, and it models real assets (not people). The engineering — world-stable icons, SGP4 orbital propagation, terrain-aware positioning — is genuinely impressive for a weekend project.

Read the full breakdown: https://dev.to/chizee/wait-we-got-open-source-palantir-before-gta-vi-1e2o

What's the most surprising live-trackable asset on the globe? The ISS orbital replay? Undersea cables? Fire detections? Drop a comment below!

Wait, We Got Open Source Palantir Before GTA VI?

Chizee — Thu, 27 Aug 2026 23:02:28 +0000

Wait, We Got Open Source Palantir Before GTA VI?

An ex-Google Maps PM just dropped a browser-based globe that tracks every plane, ship, satellite, and CCTV camera on Earth in real time — and put the whole thing on GitHub under an MIT license. The internet called it "vibe-coded Palantir." The actual co-founder of Palantir noticed.

Here is how a weekend project went from spy-thriller UI to open-source reality.

The demo that broke the internet

Three minutes into Bilawal Sidhu's YouTube walkthrough, he points at a military helicopter doing racetrack patterns over Fort Rucker, Alabama. The amber icon on the 3D globe isn't just a dot — it banks into actual turns, holding the training hold that every military pilot learns in initial contact school.

"Those loops are basically training patterns," he says.

That's when it stops feeling like a tech demo. The globe is not showing his data or his simulation. It is showing the real sky, right now, and you can ask it questions about what is happening.

The "vibe-coded Palantir" moment

Sidhu spent six years at Google building Immersive View — the photorealistic 3D Maps experience that lets you fly over a city before you visit. He has 2.1 million YouTube subscribers and runs a TED-curated channel on spatial computing. When the God's Eye View demo dropped, one commenter joked he had "vibe-coded Palantir."

Joe Lonsdale saw it too. Within 48 hours of the video going viral, Sidhu — now CEO of a stealth startup and an a16z scout — did something no defense contractor would ever do: he open-sourced the whole thing.

GitHub. MIT License. One Google Maps API key. That is it.

What you actually get

The app runs in your browser on a photorealistic 3D globe (Google Photorealistic 3D Tiles plus CesiumJS). Thirteen live data layers, ten of them free and keyless. Here is how the demo unfolds:

Minute 1 — Military training over Alabama. Military flight traffic rendered in amber (via adsb.lol). Click any aircraft and you are in its cockpit view, with augmented reality labels on everything within a 250 km radius — other aircraft, ships at sea, mapped installations.

Minute 2 — Austin, by voice command. "Take me to the Texas State Capitol." The camera glides there, orbits slowly. "Turn on the CCTV layer and annotate the grounds." Building outlines appear. "What monuments are nearby?" They are listed, marked, and connected with walking directions to the Tahhano Monument.

Minute 3 — Real traffic, real cameras. Over Austin, turn on the TomTom traffic layer. Congestion colors the streets. Click a jammed intersection and the app jumps to the nearest public camera — projected into the 3D city, not stuck on as a 2D embed.

Minute 5 — Infrastructure everywhere. Undersea cables near the Bahamas — 712 mapped routes you can dive beneath. Dams appear on demand in China (704 of them). Data centers (4,351), plotted globally. NASA fire detections flash red dots you can inspect.

Minute 7 — Orbit. Turn on the satellite layer and click the ISS. You ride along at orbital distance, orbit ring visible, watching it cross over Ukraine while ground tracks update via SGP4 propagation.

Minute 9 — Falcon 9 replay. Pick a recent launch, hit play, watch the ascent — scrubbable from 0.25x to 4x. Labeled RECONSTRUCTED ESTIMATE, since it is one.

Minute 11 — The voice whiteboard. "Draw the walking route from the Capitol to Zilker Park." A street-following path traces itself through the 3D city. "Fly it." The camera banks into turns like a drone shot.

Minute 13 — Radio. "Play a news radio station near Austin." An analog tuner appears. Drag the needle — the globe flies to each of the 750 worldwide broadcasters, one real place at a time.

How it is built

The stack is stripped down:

Vanilla JavaScript — no React, no Vue, no framework overhead
CesiumJS — the 3D globe engine
Vite — build tool
Google Photorealistic 3D Tiles — the planet (the one paid key)
OpenAI Realtime API — voice only (optional, $5 session cap)

No framework is the real statement. Sidhu could have shipped this as a Next.js app with a dozen dependencies. Instead, the entire app boots in 1.86 seconds on a laptop and the codebase is small enough to actually read.

The engineering that makes it feel real:

World-stable icons. Aircraft and ships point along their true real-world heading at every camera angle — not just on the current screen. Per-frame screen-space course projection. Most tracking apps break this when you tilt or pan.

Smooth motion from choppy data. Feeds arrive every 15 to 30 seconds. The globe renders one interval behind real time and interpolates between fixes using dead reckoning. No teleporting icons.

Honest satellites. SGP4 orbital propagation with GMST realignment keeps orbit rings locked to their satellites. The ISS does not slide across the sky like it is on greased glass.

Terrain-aware positioning. Entity heights run through a real vertical datum (geoid-aware, sampled against the rendered terrain mesh). Aircraft park on runways. Cameras stand on street corners. Nothing floats.

Quota-governed proxies. The paid feeds (OpenSky, TomTom) run behind cached, budget-governed proxies. An afternoon of exploring will not torch your API allowance.

The one thing you pay for

Google Maps. That is the only paid key you need. Google gives 1,000 free 3D-tile sessions per month — each good for up to three hours of rendering. A solo user rarely leaves the free tier. After that, about $6 per 1,000 sessions.

OpenAI voice is also metered, but the app enforces a hard $5 session cap and warns at $2.

Everything else — flights, ships, satellites, earthquakes, CCTV, radio, bikeshare, fire detections, space launches — is free. No account, no signup. Just open the app.

The Palantir comparison, unpacked

The joke landed because Palantir's whole thing is taking public data and making it look like a classified ops room. God's Eye View achieves the same aesthetic — FLIR overlays, tactical HUD, cockpit views — but the interface runs in your browser, under your control, and every line of code is inspectable.

Palantir builds enterprise software for government agencies. God's Eye View is a browser app any teenager with a laptop can clone, fork, and extend. That is why the comparison is almost too perfect. Sidhu took the look and feel of billion-dollar geospatial intelligence and made the entry fee zero, the distribution model GitHub.

The real cost of going back in time

Sidhu's closing admission:

"Build in this space for a week and you learn that the present is the cheap part. The moment you try to go back in time — tiling, serving, and scrubbing what happened and what changed at any real resolution — the data gets expensive and the compute gets brutal."

The free layer does real-time only. Yesterday's traffic, last week's flight paths, historical fire perimeters? That is where enterprise contracts kick in. Sidhu's team at halfpixel.ai is building that part for paying customers. It will not be open source or free.

But the baseline — today, right now — is the real thing. Track anything moving on the planet. Ask questions in natural language. Annotate the world around you. Replay a rocket launch.

No people tracking — and that matters

Sidhu drew a line:

"This project models events, assets, infrastructure, and systems — aircraft, vessels, satellites, fires, cameras, cities. It does not build features for named-person search, face recognition, or tracking individuals, and pull requests that cross that line won't be merged."

In a landscape where every "open source OSINT" project pivots into surveillance-for-hire, that ethical boundary is as notable as the engineering.

Go break it

GitHub: github.com/bilawalsidhu/gods-eye-view

It runs on public data, clear sources, and local-first execution. No secrets, no private datasets, no mystery scraping. Secret-bearing API keys (OpenAI, AISStream, OpenSky OAuth, TomTom, FIRMS) stay server-side — the browser only gets a short-lived session token.

Or, if you are not a developer: install Claude Code, Codex, or Cursor, and paste:

"Clone github.com/bilawalsidhu/gods-eye-view and set it up. Walk me through the Google Maps key, set a billing alert and usage quota, and start the dev server. I am not a developer — explain as you go."

That one key is the whole entry fee. Everything else lights up from there.

"This is yours. Have fun with it. Break it. Extend it. Do amazing things with it. I cannot wait to see what you cook up."
— Bilawal Sidhu

Originally published on omenabyte.com: https://omenabyte.com/blog/open-source-palantir-gods-eye-view

Postgres Can Do Typo-Tolerant Search. You Don't Need Elasticsearch Yet.

Chizee — Sun, 23 Aug 2026 17:01:46 +0000

Launch Workspace — "Just Use Postgres" Week 2

Route: A (canonical build) — DRAFTED ✅ (cron will build + ship Aug 16)
Dev.to title: Postgres Can Do Typo-Tolerant Search. You Don't Need Elasticsearch Yet.
Slug: replace-elasticsearch-with-postgres-search
Canonical URL: https://omenabyte.com/blog/replace-elasticsearch-with-postgres-search
dev.to tags: postgres, database, search, tutorial
Cover: https://omenabyte.com/blog/just-use-postgres-cover.png
Series: The Field Manual Series
Medium topics (for the manual import step): PostgreSQL, Databases, SQL, Web Development, Software Engineering

A search bar feels like an Elasticsearch problem the moment someone asks for "did you mean...?" or relevance ranking. So the data gets duplicated into a second cluster, a sync job gets built to keep it current, and now there are two sources of truth for the same rows.

Postgres already has both stemmed search and typo tolerance built in — one native, one a very old, very stable extension.

Stemmed, ranked search with tsvector

tsvector strips stop words and reduces text to root forms — "running" becomes "run" — so a search for one form matches the others, ranked by relevance.

ALTER TABLE articles ADD COLUMN search_vector tsvector
  GENERATED ALWAYS AS (
    to_tsvector('english', coalesce(title,'') || ' ' || coalesce(body,''))
  ) STORED;

CREATE INDEX idx_articles_search ON articles USING GIN (search_vector);

SELECT title FROM articles
WHERE search_vector @@ to_tsquery('english', 'postgres & scaling')
ORDER BY ts_rank(search_vector, to_tsquery('english', 'postgres & scaling')) DESC;

That coalesce() isn't decoration — I found this the hard way. In Postgres, text || NULL evaluates to NULL. Skip the coalesce, and the very first article with an empty body silently drops out of search entirely, with no error to tell you why.

Typo tolerance with pg_trgm

For the "did you mean" experience, pg_trgm breaks text into overlapping three-letter chunks and matches on similarity instead of exact spelling.

CREATE EXTENSION IF NOT EXISTS pg_trgm;
CREATE INDEX idx_articles_title_trgm ON articles USING GIN (title gin_trgm_ops);

SELECT title FROM articles
WHERE 'Postgress' <% title  -- misspelled, still matches
ORDER BY word_similarity('Postgress', title) DESC;

Notice this uses <% (word_similarity), not the more commonly-shown % (similarity). That distinction actually matters: % compares two entire strings against each other. Test it yourself — a completely ordinary title like "Scaling Postgres in Production" scores below the default match threshold against "Postgress," because the operator is comparing the misspelled word to the whole sentence, not to the word within it. word_similarity checks the query against individual words inside the longer string instead, which is what "typo-tolerant search" actually means in practice.

Why this beats standing up a search cluster

The index lives transactionally with the row — no reindex pipeline to keep in sync.
Ranking is built in via ts_rank, not bolted on.
One fewer cluster to provision, patch, and pay for.

Where Elasticsearch still wins

Distributed log analytics at serious scale, or if you're already deep in its observability ecosystem (Kibana dashboards, log aggregation) rather than a single application search bar. For "let users search my app's content," Postgres covers the overwhelming majority of real cases.

👉 Get the field manual — launch price $14 instead of walking into a $50/month managed-search invoice: https://payhip.com/omenabyte
🐳 Or take the $24 bundle with the full docker-compose up starter repo — all 8 modules as tested, runnable migrations + seed data: https://4693433176360.gumroad.com/

Read this on omenabyte.com → https://omenabyte.com/blog/replace-elasticsearch-with-postgres-search

I Replaced Redis and RabbitMQ With 15 Lines of Postgres

Chizee — Sun, 09 Aug 2026 13:01:00 +0000

Launch Workspace — "Just Use Postgres" Week 1

Route: TBD (A = canonical build on omenabyte.com → dev.to API · B = dev.to-first · C = draft-only manual publish)
Decision made: pending Boss's pick

ARTICLE 1 — dev.to-optimized draft

Title: I Replaced Redis and RabbitMQ With 15 Lines of Postgres
Tags: postgres, database, backend, tutorial
Cover image: Just-Use-Postgres-Field-Manual-cover.png (blueprint elephant, navy/amber — matches dev.to dark theme)
Canonical URL (route A): https://omenabyte.com/blog/replace-redis-rabbitmq-with-postgres

Every background job system I've built started the same way: "we'll just add Redis for the queue." Then six months later there's a broker to patch, secure, monitor, and pay for — doing a job Postgres can do with one SQL clause.

That clause is FOR UPDATE SKIP LOCKED, and once you've used it, a message broker feels like overkill for most job-queue workloads.

The problem with a naive SQL queue

The reason people avoid building a queue directly on a table is real: two workers can grab the same "pending" row at the same time, one locks it, and the other sits there waiting. That's a legitimate deadlock risk — if you build it naively.

The fix: SKIP LOCKED

SKIP LOCKED tells Postgres: if a row is already locked by another transaction, don't wait for it — skip straight to the next one. That single behavior turns an ordinary table into a safe, concurrent queue.

CREATE TABLE jobs (
  id          bigserial PRIMARY KEY,
  payload     jsonb NOT NULL,
  status      text NOT NULL DEFAULT 'pending',
  locked_at   timestamptz,
  created_at  timestamptz NOT NULL DEFAULT now()
);

-- Without this, the query below does a full table scan on every poll
CREATE INDEX idx_jobs_status_created ON jobs (status, created_at)
  WHERE status IN ('pending', 'processing');

Here's the actual dequeue query every worker runs:

WITH next_job AS (
  SELECT id FROM jobs
  WHERE status = 'pending'
     OR (status = 'processing' AND locked_at < now() - interval '5 minutes')
  ORDER BY created_at
  FOR UPDATE SKIP LOCKED
  LIMIT 1
)
UPDATE jobs
SET status = 'processing', locked_at = now()
FROM next_job
WHERE jobs.id = next_job.id
RETURNING jobs.id, jobs.payload;

That locked_at check matters more than it looks. It's the equivalent of a message queue's visibility timeout — if a worker crashes mid-job, the job doesn't stay stuck in processing forever. Another worker reclaims it after five minutes.

I actually tested this for duplicates

I ran this exact query five times in a row against a seeded table: three fresh jobs and one simulated crashed job. Every job came back exactly once, in order, and the crashed job was correctly reclaimed on the fourth call. Zero duplicates, zero races.

Why this beats adding Redis for most teams

No broker to operate. Nothing new to patch, secure, or monitor.
Job history lives with your data. You can join a job row straight to the order or user it belongs to — try doing that across two databases.
Crashes don't lose work. The reclaim logic above handles it natively.

Where Redis still wins

If you need sub-millisecond pub/sub fan-out to thousands of concurrent WebSocket clients, or a pure in-memory cache absorbing extreme read traffic, that's a different problem — Redis is still the right tool there. But "give my background jobs somewhere safe to live" almost never needs a separate service.

👉 Get the field manual — launch price $14 instead of walking into a $50/month managed-Redis invoice: https://payhip.com/omenabyte
🐳 Or take the $24 bundle with the full docker-compose up starter repo — all 8 modules as tested, runnable migrations + seed data: https://4693433176360.gumroad.com/

Read this on omenabyte.com → https://omenabyte.com/blog/replace-redis-rabbitmq-with-postgres

DEV Community: Chizee

Stop Recomputing Your Dashboard on Every Page Load

Pre-bake the aggregation

Refresh without locking out readers

Put it on a schedule with zero extra infrastructure

Why this beats a dedicated warehouse for most dashboards

Where Snowflake still wins

You're Doing Vibe-Coding Wrong. Here's the 17-Point Fix.

What the scanners actually found

The specific failures

Why this keeps happening

The 17-point checklist

Two things people get wrong

Where this leaves you

Billions of Log Rows, One Command to Make Them Disappear

Split the table without splitting the app

A featherweight index built for this exact shape of data

Retention becomes a metadata operation

Why this beats a dedicated time-series database

Where InfluxDB still wins

You Don't Need MongoDB for "Flexible" Data. You Need One Column Type.

Store anything

Query it like you mean it

The part MongoDB genuinely can't do as cleanly

Why this beats standing up a document database

Where MongoDB still wins

Your AI Feature Doesn't Need Pinecone. It Needs pgvector.

Launch Workspace — "Just Use Postgres" Week 3 (Article 3 / Week 4)

Your AI Feature Doesn't Need Pinecone. It Needs pgvector.

The setup

The query that used to need two databases

The gotcha nobody mentions

Why this beats a dedicated vector database for most teams

Where Pinecone still wins

I Watched a Man's Certainty Evaporate in Real Time

The most dangerous hacker in the room never touched a keyboard.

The uncomfortable truth: you're the weakest link

The 10 rules of being politely paranoid

Why the machines make it worse (and better)

The strongest password you'll ever have

The Prompting Gap Is the Only Gap Left

The tool got good before the instructions did

Six patterns, not fifty-two prompts

A few, to prove it's not just theory

What's in the full library

1027 AI Image Slash Commands That Will 10x Your Prompt Game

The /imagine trick that started a thousand cheat sheets

The birth of /imagine

Why slash commands beat full prompts (most of the time)

The 5 categories you'll use 80% of the time

1. 📐 Foundation Modifiers (30 commands)

2. 🔦 Perspective / Camera (30 commands)

3. 🎨 Style & Medium (30 commands)

4. 💡 Lighting (26 commands)

5. 📱 Output Format (20 commands)

Advanced: chaining for complex results

What's in the full handbook

Grab the complete handbook

Bonus: 5 chaining recipes for any style (dev.to edition)

Open source Palantir tracking every plane, ship, satellite — built in a weekend

Wait, We Got Open Source Palantir Before GTA VI?

Wait, We Got Open Source Palantir Before GTA VI?

The demo that broke the internet

The "vibe-coded Palantir" moment

What you actually get

How it is built

The one thing you pay for

The Palantir comparison, unpacked

The real cost of going back in time

No people tracking — and that matters

Go break it

Postgres Can Do Typo-Tolerant Search. You Don't Need Elasticsearch Yet.

Launch Workspace — "Just Use Postgres" Week 2

Stemmed, ranked search with tsvector

Typo tolerance with pg_trgm

Why this beats standing up a search cluster

Where Elasticsearch still wins

I Replaced Redis and RabbitMQ With 15 Lines of Postgres

Launch Workspace — "Just Use Postgres" Week 1

ARTICLE 1 — dev.to-optimized draft

The `/imagine` trick that started a thousand cheat sheets

The birth of `/imagine`