DEV Community: Chizee

I Replaced 8 Services With Postgres. Here's Where It Actually Breaks.

Chizee — Sun, 18 Oct 2026 10:09:50 +0000

Over the last few months I've written about replacing Redis, Elasticsearch, Pinecone, MongoDB, InfluxDB, Snowflake, a GIS stack, and a hand-built API layer — all with a single Postgres instance. Every one of those posts was true, tested, and worth doing for most teams.

None of that means Postgres has no limits. It means most applications never actually reach them. Here's exactly where the line sits, because "it depends" isn't a real answer and I'd rather just tell you.

Where this genuinely stops working

Horizontal sharding is still hard

Postgres scales vertically with real grace, but splitting one logical database across many physical nodes adds genuine operational complexity. Tools like Citus help — they don't make it free.

Extreme ingest rates

If you're ingesting millions of events per second, a single Postgres primary becomes your bottleneck before your application code does.

Sub-millisecond, massive-fanout caching

Thousands of concurrent WebSocket connections, or read-after-write caching at extreme QPS, still wants a pure in-memory store. This is the one place on the list where the tool I told you to delete is genuinely the right one.

Connection limits

Postgres handles a few thousand direct connections comfortably. Past that you need a pooler — PgBouncer or Supavisor — which is normal operations at scale, not a flaw to work around.

Vacuum and bloat

Heavy update/delete workloads need autovacuum tuned deliberately, or table bloat creeps in over time. This is routine Postgres maintenance, not optional homework.

One database, one blast radius

Consolidating everything onto one instance means a single maintenance window or outage touches everything it powers. Plan replicas and backups accordingly — this is the actual cost of the simplicity, not a hidden one.

The honest takeaway

None of this means don't do it. It means know exactly where the line is, and cross it on purpose — not by accident, three months after your traffic graph quietly tripled.

If you've read the previous eight posts in this series and are wondering "so when do I actually need to reach for something else" — this is that answer, in full, with nothing softened for the sake of a tidier narrative.

This wraps an eight-part series on replacing common infrastructure with Postgres. All nine pieces — including the honest limits above, plus a 5-phase rollout plan for migrating without a 2am incident — are collected in Just Use Postgres, a field manual with runnable SQL for every recipe.

👉 Get the field manual — launch price $14: 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/where-postgres-only-architecture-breaks

Let Your Database Generate the API and Guard the Door

Chizee — Sun, 11 Oct 2026 10:09:16 +0000

Most CRUD backends are the same boilerplate repeated per table: a route, a controller, a serializer, an authorization check. That's thousands of lines maintaining plumbing that doesn't encode a single real business rule.

PostgREST turns your schema directly into a documented REST API. Row-Level Security moves authorization into the database itself, enforced on every query — including ones that bypass your application entirely.

The policy

ALTER TABLE notes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see only their own notes"
  ON notes FOR SELECT
  USING (auth_user_id = NULLIF(current_setting('request.jwt.claim.sub', true), '')::uuid);

PostgREST injects request.jwt.claim.sub automatically from the caller's JWT on every request — you never set this yourself in application code.

That NULLIF(..., '') is there for a reason I only found by testing this directly. current_setting(name, true) correctly returns NULL the first time a custom setting is unset in a session — but once it's been referenced even once (say, inside a transaction that later rolled back), Postgres leaves behind an empty-string placeholder for the rest of that session. From then on, current_setting returns '', not NULL, and casting an empty string to uuid throws an error. NULLIF closes that gap for both cases.

The bypass nobody warns you about

Table owners and superusers bypass Row-Level Security by default — policies simply don't apply to them. I confirmed this directly: as the table owner, a query against a two-row table with a strict policy in place still returned both rows. If you test your policy logged in as the role that created the table, it will always look unrestricted, whether or not the policy is actually correct.

ALTER TABLE notes FORCE ROW LEVEL SECURITY;

This closes the gap if the policy needs to hold even for the owner. Either way, always test as the actual application role, not your own login.

What PostgREST auto-generates from this

GET  /notes   ->  rows already filtered by the policy above
POST /notes   ->  insert validated against the same policy set

Add a column, the API reflects it immediately. No controller to update.

Why this beats hand-rolling an API layer

No controller per table — the schema is the API surface.
Security lives in one place instead of scattered across every endpoint that happens to touch a table.
The rule holds even if a client somehow calls the database directly — it's enforced below the application layer, not inside it.

Where a custom API still wins

Complex multi-step workflows, third-party orchestration, or business logic that genuinely doesn't map onto table operations — payment flows, multi-system sagas, anything truly procedural. For straightforward CRUD, you're likely maintaining code that generates itself.

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 hand-writing a controller for every table: 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-your-api-layer-with-postgrest-rls

Two People Bought the Last Ticket. Both Got a Confirmation Email.

Chizee — Sat, 10 Oct 2026 18:22:10 +0000

One seat left. Row F, seat 12. Maya in Chicago and Leo in Denver hit Buy inside the same millisecond, and both of them get a confirmation email.

Your code did nothing wrong. That's the part that should worry you.

The bug is a gap, not an error

Here's the flow nearly every application writes at some point:

seat = SELECT * FROM seats WHERE id = 'F12';
if (seat.status == 'available') {
    UPDATE seats SET status = 'sold' WHERE id = 'F12';
    send_confirmation_email();
}

Read, check, write. Three steps, and nothing in that snippet is wrong on its own.

Both lanes do the same three correct steps. The amber band is the window where Leo’s read lands between Maya’s check and Maya’s write. Diagram: Omenabyte Intelligence.

Now run two of them at once. Maya's request reads the row: available. Before her write lands, Leo's request reads the same row. Maya hasn't committed yet, so from where Leo is standing the seat is still available. Both checks pass. Both writes go through. Two emails, one chair.

This is a race condition, and the useful thing to understand is that it isn't a crash. It's the ordinary result of two requests arriving at the same time. Nothing threw. Nothing logged a warning. The database accepted both writes because both writes were valid requests. The outcome depended entirely on which header arrived first, and nobody wrote that rule down.

The name for the shape is check-then-act: you made a decision based on a value, then acted on a world that had already moved. Every version of this bug, in every language, is that same gap between the reading and the writing.

Why the database didn't stop you

It's tempting to assume the database should have caught this. It had all the information.

Two things make the double sale possible, and both are deliberate.

First, PostgreSQL's default isolation level is Read Committed. A plain SELECT sees a snapshot of the database as of the moment the query began. While Maya's transaction is open and uncommitted, her write is invisible to everyone else, which is exactly the point of running transactions. Isolation is supposed to hide in-progress work. So Leo legitimately sees available.

Second, and this matters more, a plain SELECT doesn't lock anything meaningful. Read Committed will happily let a hundred transactions read the same row simultaneously. Reads don't conflict with reads.

So the database behaved correctly. It was asked to record a fact that was true when it was written, and it did.

The engine is doing what it was told. Nothing in the transaction was malformed; the problem is the shape of the operation, not the hardware running it. Photo: PiDatacenters / CC BY-SA 4.0

Fix one: make the second request wait

The direct approach is a row lock.

BEGIN;

SELECT * FROM seats
WHERE id = 'F12'
FOR UPDATE;

-- returns 'available', and the row is now locked for this transaction
UPDATE seats SET status = 'sold' WHERE id = 'F12';
COMMIT;

FOR UPDATE locks the retrieved rows as though for update. While Maya holds that lock, Leo's SELECT ... FOR UPDATE on the same row blocks. It doesn't fail, it doesn't return a stale value, it waits. When Maya commits, the lock releases and Leo's query proceeds and returns the updated row, which now says sold. Leo gets an error instead of a ticket, and the order of the queue was never in doubt.

This is pessimistic locking: assume contention, coordinate before anyone moves.

Four things decide whether it actually works.

The lock only exists inside a transaction

This is the mistake that makes people conclude locking doesn't work. In autocommit mode, a statement ends the moment it finishes, so the lock is released before your UPDATE ever runs. The lock has to span the read, the decision, and the write. BEGIN is not optional.

Lock the row you mean, not the table

WHERE status = 'pending' FOR UPDATE with no index on status scans the table and locks every matching row on the way past. Lock on a primary key or another indexed column and you get a narrow lock instead of a queue for the whole table.

A lock is a reservation on one row. Aim it at a column without an index and you have reserved far more than you meant to. Photo: Carl Lender / CC BY 2.0

Decide how long to wait

An unbounded wait turns a lock into an outage. FOR UPDATE NOWAIT fails immediately if the row is already locked (55P03, lock_not_available), and lock_timeout caps the wait at a duration you chose. Either way you can turn the failure into a retry, a "just taken" message, or a queued job.

Locks queue, and queues have a cost

This is the source video's honest caveat, and it's worth repeating: if thousands of fans are fighting over the same section, requests pile up behind the lock. Each one is short. The total wait grows with the length of the line.

Contention on one row queues everyone. Contention spread across ten thousand different rows barely conflicts at all. Photo: Wvdp / CC0

Fix two: delete the gap

The better fix changes the shape of the operation so there's nothing to interleave.

UPDATE seats
SET status = 'sold'
WHERE id = 'F12'
  AND status = 'available';

One statement. The check and the write are the same event, evaluated against the same row, in the same instant. Maya's update matches the row and changes it. Leo's update arrives, finds no row that is still available, and changes zero rows.

Maya's update changes one row. Leo's changes zero. That difference is the entire result of the race, and the database hands it to you for free.

Now the mechanism, because this is where most explanations stop and it's worth knowing why the UPDATE is safe rather than lucky. This is straight from the PostgreSQL manual on Read Committed:

The search condition of the command (the WHERE clause) is re-evaluated to see if the updated version of the row still matches the search condition.

The part worth slowing down on: it isn't only that the two operations happen atomically, it's that if your UPDATE finds a row another transaction has already modified, it waits for that transaction, then re-checks your WHERE clause against the new version of the row. Leo's AND status = 'available' is re-evaluated against the row Maya just committed, fails, and the row is skipped.

So the guarantee isn't luck or a narrow timing window. It's a documented re-evaluation the engine performs for you.

The consequence is that the operation can succeed silently with nothing to do, and that's a trap:

UPDATE seats
SET status = 'sold'
WHERE id = 'F12' AND status = 'available'
RETURNING *;

If the result set comes back empty, the seat went to someone else. If you don't check, your code sails on believing it booked a seat it never touched, and you've rebuilt the original bug with extra steps. Zero rows affected is your conflict signal, and it only helps if you read it.

Fix three: put the guarantee in the schema

Application code has bugs. Your concurrency logic will be tested by people who don't know it's there, in code you haven't written yet.

CREATE TABLE tickets (
    id         bigserial PRIMARY KEY,
    event_id   bigint NOT NULL REFERENCES events (id),
    seat_id    text   NOT NULL,
    created_at timestamptz NOT NULL DEFAULT now(),
    CONSTRAINT one_ticket_per_seat UNIQUE (event_id, seat_id)
);

With that constraint in place, two confirmed tickets for the same seat cannot exist in the table. Not "should not," not "unlikely to." The engine refuses the second insert and raises 23505, unique_violation, regardless of what your application layer believes.

Be clear about what this does and doesn't do. It does not make your checkout flow correct. It makes the final invariant unbreakable, which is a different and more valuable thing: it's the property that survives every future refactor, every new endpoint, every script somebody runs by hand at midnight.

It also moves a decision into your error handling. The unique violation is a normal outcome under contention, not an exceptional one. Catch 23505, translate it into "that seat just went," and move on. If you let it bubble up, your loser gets a 500 for a situation the design anticipated.

What each mechanism actually buys you

These are not three ways to do the same thing. They handle the conflict at different moments and give the loser a different experience:

The same seat, three mechanisms. The conditional UPDATE is the recommended default; the constraint is what stays true after every other layer has been refactored. Diagram: Omenabyte Intelligence.

Mechanism	Conflict handled	What the loser sees	Fits
`SELECT ... FOR UPDATE`	before the decision	waits, then sees the new value	short multi-step decisions that need stable rows
Conditional `UPDATE ... WHERE`	at the attempted write	zero rows affected	state transitions with a clean precondition
Unique constraint	at insert	`23505` raised	the final invariant, unconditionally

A booking system uses all three. The conditional update takes the seat. The constraint backstops it. FOR UPDATE earns its place when the decision needs several reads or writes against state that must not move underneath you, like validating a balance, writing a ledger entry, and updating an account.

The parts nobody puts in the cheat sheet

Deadlocks are real and have a code

If two transactions lock rows in opposite orders, one gets aborted with 40P01, deadlock_detected. The fix is ordering: always acquire locks on multiple objects in the same sequence, and take the most restrictive lock you'll need first. PostgreSQL detects deadlocks and breaks them, but it's choosing a victim, not resolving your design.

Serialization failures need a retry loop

Under Serializable, the engine can abort a transaction with 40001, serialization_failure, even when there's no obvious conflict. That's the contract: you retry the whole transaction from a fresh read, with bounded attempts and backoff. Retrying from where you left off defeats the purpose.

Isolation level changes what `FOR UPDATE` does on conflict

Under Read Committed, a blocked FOR UPDATE waits and then returns the updated row, as above. Under Repeatable Read or Serializable, it throws instead, because the row changed since your transaction's snapshot. Both are defensible. You just have to know which one you're getting.

Retries duplicate side effects

If a transaction can charge a card, send an email, or publish a message, a retry can do it twice. Keep external I/O outside the locked transaction wherever you can, and make the operations that must cross the boundary idempotent with a key the receiver understands.

Sometimes you want the queue to be skippable

SELECT ... FOR UPDATE SKIP LOCKED doesn't wait for a locked row, it moves on to the next one. For a work queue where workers are draining a table of jobs, that's the right behaviour, and it's the standard pattern for job tables. It's the wrong behaviour for a seat, where you want that specific row.

Two rules that outlive the example

Keep your checks inside the write, and keep the final guarantee in the schema.

The first rule is about where the decision happens: if a condition decides whether a write is allowed, that condition belongs in the WHERE clause, not in an if above it. The second is about who can be trusted: your application is code you're still writing, but a constraint is a property the engine will enforce against every caller forever, including the ones you haven't imagined.

Together they close the gap from both ends. The write stops being interruptible, and the outcome stops depending on anything the write got right.

Which has cost you more time, the bug, or the incident review after it?

The seat-booking framing, the Maya and Leo example, and the three-mechanism structure are from a Knowmore video on database concurrency, which states its lock and constraint guarantees accurately. The mechanism-level detail added here is from the PostgreSQL 18 manual: the WHERE re-evaluation under Read Committed, lock ordering and deadlock codes, NOWAIT and SKIP LOCKED, and the isolation-level differences. Photography from Wikimedia Commons under the licences noted in each caption; both diagrams were drawn for this article.

Originally published on omenabyte.com -> https://omenabyte.com/blog/the-gap-between-checking-and-writing

"Find What's Nearby" Doesn't Need a Separate GIS Stack

Chizee — Sun, 04 Oct 2026 10:08:59 +0000

Store finders, delivery radius checks, geofencing — any "what's near this point" feature looks like it needs specialized spatial infrastructure. Done naively (raw coordinate math checked against every row), it genuinely does fall over past a few thousand points. Done with PostGIS, it's an index like any other.

PostGIS isn't a lightweight workaround, either — it's the de facto industry standard most dedicated GIS tooling gets benchmarked against.

The setup

CREATE EXTENSION IF NOT EXISTS postgis;

CREATE TABLE coffee_shops (
  id        bigserial PRIMARY KEY,
  name      text,
  location  geography(Point, 4326)
);

CREATE INDEX idx_coffee_shops_location
  ON coffee_shops USING GIST (location);

A GiST index draws simple bounding boxes around your geometries first, so Postgres can instantly discard millions of points that obviously aren't close, before running the precise (and expensive) distance math on the small set that remain.

The query

SELECT name FROM coffee_shops
WHERE ST_DWithin(
  location,
  ST_SetSRID(ST_MakePoint(-122.42, 37.77), 4326)::geography,
  1000  -- meters
);

The trap that's actually worth knowing about

I went looking for the "obvious" PostGIS gotcha (mismatched SRIDs throwing hard errors) and, tested directly against a live PostGIS instance, that specific fear turned out to be overstated — casting straight to geography without an explicit SRID mostly just works, since geography only ever supports SRID 4326 anyway.

The trap that's real and far more dangerous: PostGIS does not validate that your coordinates are actually in range. Feed it projected/UTM meters where it expected longitude/latitude degrees, and it silently coerces the values into valid range with nothing but a quiet NOTICE — no error, no loud failure, just garbage coordinates that look plausible until someone notices the map is wrong. If you're piping coordinates in from another system, double-check the units before they ever hit this table.

Why this beats a separate GIS engine

It's the standard, not a substitute — documentation and tooling assume PostGIS by default.
Spatial joins work against ordinary relational tables in the same query.
Decades of production hardening, not a new or experimental extension.

Where dedicated GIS tooling still wins

Heavy cartographic rendering or raster analysis — satellite imagery, terrain modeling — which is a genuinely different workload from querying point and polygon data. For "what's near this address," you likely already have everything you need.

👉 Get the field manual — launch price $14 instead of standing up a tile server for a distance query: 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-gis-tools-with-postgis

Eight Layers Between an Attacker and Your Data. You've Only Configured One.

Chizee — Fri, 02 Oct 2026 23:23:09 +0000

When you think about network security, you probably picture one thing. A firewall. Something blocking hackers on the other side of a wall.

That's one piece. There are eight layers in the model, and the firewall is the one least likely to be the reason you get breached, precisely because it's the one everybody configures.

Think about a bank. It doesn't lock the front door and call it done. There's a guard, a vault, cameras, an alarm, probably a second vault inside the first. Getting past one obstacle doesn't get you the money. You have to get past all of them.

So follow an attacker from the outside in and see what actually stops them at each stage.

One thing worth saying first, because it trips people up constantly: these eight are a control stack, not the OSI model's seven network layers. Some names overlap and the numbering does not match at all. When I say "the application layer" here, I mean the sixth barrier in this list, not OSI layer 7.

The eight barriers, in the order an attacker meets them, with what each one exists to stop. Diagram: Omenabyte Intelligence.

Layer 1: Physical security

Before firewalls or passwords, a simpler question. Can someone walk up and touch the hardware?

Locked doors, cameras, access badges, guards. All of it exists to stop someone plugging directly into a server or walking out with a drive under their arm. It sounds almost too obvious to mention, which is why it's the foundation everything else sits on. You can have the best firewall in the world, and if anyone can stroll into the server room, none of it matters.

Layer 2: Perimeter security

The network is physically protected, but attackers don't need to enter the building. They come through the connection.

This is the firewall, and the right mental model is a checkpoint rather than a wall. Every connection trying to enter or leave gets checked against rules. Some traffic is allowed. Some is blocked because it came from an untrusted source, used a restricted port, or failed the network's policy. A company might let employees browse the web while blocking unexpected inbound connections to internal servers.

Firewalls also police traffic between internal zones, not just between you and the internet. That matters for what comes next.

Layer 3: Network segmentation

An attacker got past the perimeter. Do they now have everything?

Only if your network is one flat space. Well-designed networks are broken into zones with VLANs, subnets and access control lists so different parts can't freely talk to each other. Employee laptops in one zone. Finance systems in another. Servers holding sensitive data in a third.

The payoff is specific. Compromising a single employee laptop doesn't hand an attacker a path to the database. Same logic as keycard doors inside a building: getting through the front entrance doesn't open every door.

This is where the model starts earning its keep, because it reframes what you're buying. Network security isn't only about keeping attackers out. It's about limiting what they can reach once they're in.

Segmentation is physical before it is logical: every zone boundary lands somewhere, on a switch port and a cable run. Photo: Wikimedia Commons / Public domain.

Layer 4: Identity and access

Controlling where someone can go isn't enough. You also need to know who they are and what they're allowed to touch.

Two ideas live here, and this is the pair people mix up most.

Authentication asks who you are. Proving identity, usually with a password, ideally backed by a second factor like a code on your phone.

Authorization asks what you may do. A regular employee account shouldn't open the same systems an IT administrator can, even though both logged in successfully.

That gap is where least privilege comes from. Give people access to only what they actually need, nothing more. If someone does steal a login, least privilege limits the damage to whatever that one account could touch. Even inside a segmented zone, with valid-looking credentials, something is still deciding what's reachable.

The distinction the source video flags as the easiest one to lose track of. Diagram: Omenabyte Intelligence.

Layer 5: Endpoint security

Everything so far has been the network. But there's still a device sitting at the end of it, and that device needs its own armour.

Antivirus, host-based firewalls, system updates, plus detection tools that watch for suspicious behaviour. Here's the uncomfortable part. A perfectly secured network can be completely compromised through one infected laptop. Someone downloads a malicious attachment or plugs in a stray USB drive. The threat isn't trying to break down the front door anymore. It's already inside, running code on a device that was allowed to be there all along.

That's why the endpoint is a primary target rather than a passive tool sitting safely behind the network's defences.

Physical and perimeter controls are the two layers most organisations do get right, which is exactly why attackers work elsewhere. Photo: Yann / CC BY-SA 3.0.

Layer 6: Application security

Protecting the device isn't the end of it either, because the software on that device can have flaws of its own.

A login form that doesn't check its inputs. Software that hasn't been patched. A bug that lets someone bypass a permission check entirely. The network is fine, the device is fine, and the application is the way in.

The controls are secure coding, vulnerability testing before attackers get there, authentication built into the application, input validation that doesn't trust what users type, and in some cases a web application firewall filtering traffic aimed at the app rather than the network.

The distinction worth holding on to is this. Network security protects the path data travels on. Application security protects the software using that path. You can lock down every road into a city and still have a building with a broken door.

Layer 7: Data security

Every layer so far was about stopping an attacker getting closer. This one matters if all of them fail, because this is the thing they were actually after.

Encryption in transit protects data while it moves, so an interception yields something unreadable without the key. Encryption at rest protects it while it sits on a server doing nothing. Access controls decide who can open it. Backups mean that if data is deleted, corrupted, or held for ransom, a copy exists elsewhere. Data classification sorts information by sensitivity so the most critical material gets the strictest handling.

Which leads to the reframe this layer buys you. Security isn't only about stopping someone getting in. It's also about making sure that if they do get in and walk away with something, it's useless to them. Encrypted data without the key is noise.

Layer 8: Monitoring and incident response

An attacker made it past everything. What now?

Logs record activity. Intrusion detection tools flag suspicious behaviour. SIEM platforms pull all of it into one place and look for patterns a human would never catch on their own. A login from a country the employee has never visited. A server suddenly shipping gigabytes outbound at 3am.

When something trips, incident response takes over. Detect the threat. Investigate what actually happened. Contain it before it spreads. Then recover, restoring systems, patching whatever let the attacker in, and learning from it.

This layer is what makes the whole system honest. Layers 1 through 7 are prevention, all of them betting an attack can be stopped. Layer 8 accepts that prevention fails, and makes sure failure isn't the end of the story.

Monitoring only pays off if someone is watching and empowered to act on what the screens say. Photo: Zhonghua Minguo Zongtongfu / CC BY 2.0.

Where this model quietly breaks

Eight layers is a good map. Here's what it leaves out.

Attacks chain layers, they don't pick one

Phishing gets in through the application layer as a malicious link, executes as malware on the endpoint, performs ARP spoofing at the data link layer to intercept traffic, then moves sideways because the network was never segmented. Defence in depth works because the chain gets interrupted somewhere, not because each layer is individually perfect. Treating the layers as independent hides the part that actually matters.

Controls get pointed at the wrong layer

This is the most common engineering error. A firewall rule operates on IP addresses and ports, so it cannot stop SQL injection. Injection is an application-layer problem wearing a valid-looking HTTP request, well-formed traffic on an allowed port. Teams then conclude the firewall failed, when the firewall was never the right tool.

There's more than one thing called a firewall

Traditional firewalls work at OSI's network and transport layers, filtering by address and port. A web application firewall inspects HTTP content and is also called a firewall. Same word, different layer, different job. Assuming you have "the firewall" covered when you own one of the two is how Layer 6 stays open.

Encryption isn't one thing either

IPsec at OSI's network layer protects all traffic between two endpoints, transparently to applications. TLS protects one application's session. Same goal, different scope, and reaching for the wrong one is a classic layer mismatch.

Nobody implements all eight equally well

That's fine, and pretending otherwise is worse than admitting it. The useful exercise is knowing which layer you're weakest at. For most small teams, it isn't the perimeter.

The practical version

The skill worth taking away isn't memorising eight names. It's matching the control to the layer of the problem.

Network path problem, think firewall or segmentation. Admission problem, think network access control. Malicious traffic that needs blocking inline, think intrusion prevention. Endpoint behaviour after execution, think EDR. Sensitive data leaving through email or cloud sharing, think DLP. Injection or cross-site scripting in a web app, think input validation and a WAF.

Get the layer right and the tool choice mostly makes itself. Get it wrong and you'll spend money on the wrong control, then wonder why the problem is still there.

Which of those eight did you last actually look at? For most teams it's the firewall. For most teams the firewall was never the layer that was going to fail.

If you made it this far, you now know more about network security than most people who click "remind me later" on a software update.

The eight-layer framing is from "Every Layer of Network Security Explained" by Tech Learning Zone. The material on chained attacks, misplaced controls, IPsec versus TLS scope, and the NIST SP 800-61 incident-response framing is added editorial context, not from that video. Photography from Wikimedia Commons under the licences noted in each caption; both diagrams were drawn for this article.

Originally published on omenabyte.com -> https://omenabyte.com/blog/every-layer-of-network-security

He Put 5,000 Users on a 12-Dollar Server. The Database Was Fine.

Chizee — Wed, 30 Sep 2026 23:25:20 +0000

The server cost twelve dollars a month. One CPU core, two gigabytes of RAM.

On it, a developer built a Twitter-style social API and loaded it with 50,000 users, 500,000 posts, and two million likes. The whole thing ran on that one machine: nginx, Node, and Postgres, no separate database box.

Then he rented a second server for four hours and used it to attack the first one with k6, spinning up virtual users by the thousand. Each one ran a loop that looks roughly like a person. Load the feed, wait a second or two, like something, maybe post something, load the feed again.

Ten users did nothing. So did fifty, a hundred, two hundred, a thousand.

At two thousand, the tail latency started moving. The average was still clean. P95 and P99 were climbing.

At three thousand he'd crossed his own failure threshold and backed down to 2,500. That was the ceiling: roughly 232 requests per second, P95 around 288 milliseconds.

Here's the part worth sitting with. RAM was still under a gigabyte. Postgres was completely fine. The CPU was at 90%.

The bottleneck wasn't where he expected it

Most people building a social app spend their early architecture budget on the database. Replicas, connection poolers, a caching layer, maybe a queue. The assumption is that the data tier buckles first under real concurrency.

Not here. At the limit, the database was sitting idle-ish and the single CPU core was the wall.

That makes sense once you look at what each request costs. Assembling a feed means parsing a request, authenticating it, querying, building objects, and serializing JSON. All of that is CPU work. Every request takes a fixed slice of that one core. Divide the load test's throughput into its CPU budget and you land at roughly four milliseconds of CPU per request.

Four milliseconds is the number that sets the ceiling. Nothing about it involves Postgres.

It also explains why the averages looked fine while the tail didn't. A saturated CPU queues work. Most requests arrive when the queue is short and get served quickly. The ones that land behind a backlog wait proportionally longer. Averages hide that, because the queue is only deep some of the time.

Every request costs a fixed slice of CPU: parsing, auth, query building, JSON serialization. At the ceiling that worked out to roughly four milliseconds per request. Photo: Martijn Boer / Public domain

And nobody experiences your average response time. They experience the worst request in their session. If a page fires twenty requests and your P99 is three seconds, that user has a real chance of feeling the app stall on every load. P95 and P99 aren't vanity metrics for dashboards nobody reads.

Two changes, roughly double the capacity

He resisted the obvious move. No Redis, no migration to a bigger box.

First he cached the feed response inside Node, with a one-second TTL. That's the whole change. His reasoning was practical: if you're running one server anyway, you already have the memory, and using it is free. You don't need to introduce a separate service to hold a value for one second.

It took him from 2,500 to about 4,000 concurrent users.

Why one second works so well comes down to traffic concentration. The feed is the same response for everyone during that window. If most of your 232 requests per second are asking for the same thing, collapsing thousands of identical requests into a handful of database queries and render passes removes almost all of that CPU cost at once. The gain is proportional to how much your traffic asks for the same thing. A global feed caches beautifully. Per-user data caches far worse.

Turns out you do not need much machine. The whole API stack ran on one core and two gigs of RAM while serving thousands of concurrent users. Photo: Jwrodgers / CC BY-SA 3.0

Then he moved that cache out of Node and into nginx. This added less than the first change did, which is worth noting: the easy win was the one inside the application, and the second change bought the remaining thousand. When nginx answers from its own cache the request never enters the Node process at all, so there's no request parsing, no middleware chain, no JSON serialization, and no garbage collection pressure from thousands of response objects. The CPU that was pegged at 90% is only busy on cache misses now.

That pushed him past 5,000 concurrent users on the same twelve-dollar machine.

Moving the cache out of Node and into the reverse proxy meant cached requests never entered the application process at all. Photo: RAIL P (RAIL.PHOTOGRAPHY) / CC0

His rule for this is the useful part: move the cache as close to your users as you can reasonably get it. It sounds like a slogan until you've watched it happen. Every hop you remove from the request path is CPU you don't spend, and CPU was the entire problem.

Amber is where the server started. The first cache bought 1,500 users; moving it into nginx bought the next 1,000. The fading tail on the last bar is deliberate: the test stopped at 5,000, so that end is a floor and not a ceiling.

Chart by Omenabyte Intelligence. Figures as measured by Arjaythedev.

The extrapolation, and where it gets shaky

Five thousand concurrent users doesn't mean five thousand customers. Real people don't all use an app at the same instant. Based on typical usage patterns he estimates that concurrency level would correspond to somewhere around 25,000 to 30,000 daily active users.

That's the honest version of the headline, and it's worth being careful with. "A twelve-dollar server handles 5,000 users" is true for this application, this load profile, and this definition of handling. Swap the workload for video transcoding, per-request image resizing, or LLM inference and the number moves by orders of magnitude, because those burn vastly more CPU per request. The transferable part of this experiment isn't the number. It's the method, and the two fixes.

The method deserves more attention than it usually gets. He measured before he optimized. He found the actual bottleneck instead of the assumed one, and he fixed that specific thing. Most teams never do the first step, and then spend real money on the second.

What the video skips

A single-machine setup that passes a load test still has problems the test doesn't cover.

When a one-second cache entry expires, every concurrent request misses at the same moment and they all stampede the database together. nginx has a real fix for this: proxy_cache_lock on. When an entry expires, exactly one request goes upstream while the rest wait for it and then get served from the newly filled cache. Hand-rolled in-process caches rarely bother, which is why a one-second TTL on a hot key can produce a nasty sawtooth in your database load. The cache helps on average and hurts in bursts.

In-process caches also don't survive a restart. A deploy empties them, and if a cold cache means every request hits the database at once, your deploy just created a self-inflicted traffic spike. Run Node in cluster mode or more than one container and each process holds its own copy with its own idea of the truth. Fine for one global feed. Actively wrong for sessions, rate-limit counters, or anything per-user.

The migration this experiment argues against. Big iron solves the problem money can solve, not the one measurement would have found. Photo: Christopher Bowns / CC BY-SA 2.0

And one machine is one point of failure. The load test measured capacity. It measured nothing about availability. A deploy is downtime, a hardware fault is an outage, and there's no redundancy anywhere in that stack. Sometimes that's an acceptable trade for a product at this stage. It should be a decision you made on purpose rather than something you discover at 2am.

There's also the load model itself. k6 virtual users follow a fixed loop, which makes them far more polite than real people. Real traffic arrives in bursts. A single scheduled notification or one post that gets picked up can spike you to a multiple of your baseline within seconds. Capacity planning has to plan for peak rather than mean, which is the standard guidance for sizing load tests: test at your projected peak, then push past it to find your margin.

The instinct this should push back on

Reaching for distributed infrastructure is usually an anxiety response, not an engineering one. The reasoning goes: this is a real product now, real products have scale problems, and scale problems need Kubernetes plus a queue plus a managed cache tier plus a service mesh. Money gets spent on a topology diagram before anyone has measured a single bottleneck.

That twelve-dollar server had one CPU core and it served over 5,000 concurrent users. It got there with two changes that cost nothing, because the person running the experiment had the discipline to find out what was actually limited before deciding how to fix it.

You might not need a distributed system. You might need to know what your CPU is doing.

The uncomfortable part is that the only way to find out which one you need is to run the test. Until you have, the migration you're planning is a guess about a number you don't know.

Source: load-test figures are from How many users can a $12 server support? by Arjaythedev, a hands-on k6 experiment on a $12/month VPS (1 vCPU, 2 GB RAM).

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.

👉 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.

DEV Community: Chizee

I Replaced 8 Services With Postgres. Here's Where It Actually Breaks.

Where this genuinely stops working

Horizontal sharding is still hard

Extreme ingest rates

Sub-millisecond, massive-fanout caching

Connection limits

Vacuum and bloat

One database, one blast radius

The honest takeaway

Let Your Database Generate the API and Guard the Door

The policy

The bypass nobody warns you about

What PostgREST auto-generates from this

Why this beats hand-rolling an API layer

Where a custom API still wins

Two People Bought the Last Ticket. Both Got a Confirmation Email.

The bug is a gap, not an error

Why the database didn't stop you

Fix one: make the second request wait

The lock only exists inside a transaction

Lock the row you mean, not the table

Decide how long to wait

Locks queue, and queues have a cost

Fix two: delete the gap

Fix three: put the guarantee in the schema

What each mechanism actually buys you

The parts nobody puts in the cheat sheet

Deadlocks are real and have a code

Serialization failures need a retry loop

Isolation level changes what FOR UPDATE does on conflict

Retries duplicate side effects

Sometimes you want the queue to be skippable

Two rules that outlive the example

"Find What's Nearby" Doesn't Need a Separate GIS Stack

The setup

The query

The trap that's actually worth knowing about

Why this beats a separate GIS engine

Where dedicated GIS tooling still wins

Eight Layers Between an Attacker and Your Data. You've Only Configured One.

Layer 1: Physical security

Layer 2: Perimeter security

Layer 3: Network segmentation

Layer 4: Identity and access

Layer 5: Endpoint security

Layer 6: Application security

Layer 7: Data security

Layer 8: Monitoring and incident response

Where this model quietly breaks

Attacks chain layers, they don't pick one

Controls get pointed at the wrong layer

There's more than one thing called a firewall

Encryption isn't one thing either

Nobody implements all eight equally well

The practical version

He Put 5,000 Users on a 12-Dollar Server. The Database Was Fine.

The bottleneck wasn't where he expected it

Two changes, roughly double the capacity

The extrapolation, and where it gets shaky

What the video skips

The instinct this should push back on

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

Isolation level changes what `FOR UPDATE` does on conflict