dev.to
Postgres for everything? not really..and here are some of ...
## You don’t need 20 tools. ... ### One boring old SQL database might be the best backend in 2025. medium.com But then reality shows up usually in the form of corporate infrastructure. You get dropped into a production environment that’s basically a dungeon crawler for database queries: - Twelve network hops before your request even touches the DB - Firewalls that block you like a bouncer at the world’s most boring nightclub - Antivirus software that somehow slows down SQL execution - Latency numbers that would make your Redis cry And the worst part? You’re not the database admin. That means: - No installing PGVector for AI search - No PG Cron for internal scheduling - No PG Crypto for secure operations - Sometimes, you don’t even *know* which region your database is in Suddenly, your “one tool for everything” dream feels like playing Elden Ring… with a potato for a GPU. … ## 4. Row-level security: when theory trolls reality On paper, **Row Level Security (RLS)** sounds brilliant. You set rules so each user only sees the rows they’re allowed to. No more messing around with manual filters in your app layer the database enforces it for you. Then you turn it on in production… and suddenly, every query plan looks like it just rolled a critical fail. What used to be a fast `SELECT` now feels like it’s doing a 14-table join for fun. Indexes? Still there, but apparently on vacation. … But here’s what actually happens: - Debugging becomes a questline from hell no proper stack traces, no modern logging tools, just squinting at SQL like it’s an ancient scroll. - Version control turns into duct tape your stored procedure updates live in random `.sql` files or, worse, only exist in production and nobody remembers who wrote them. - Your CI/CD pipeline? Doesn’t even know this logic exists, so testing is… let’s say “optional.” One developer summed it up perfectly: > *“If you maintain jobs and business logic inside Postgres, you’re giving up git for guesswork.”* It’s not that stored procedures are evil they’re great for certain performance-critical cases but making them the *default* place for all your application logic is asking for future pain. When that pain hits, it doesn’t matter how elegant your SQL was you’ll be the one spelunking through functions at 2 AM while prod is down. … ## You don’t need 20 tools. ... You get dropped into a production environment that’s basically a dungeon crawler for database queries: - Twelve network hops before your request even touches the DB - Firewalls that block you like a bouncer at the world’s most boring nightclub - Antivirus software that somehow slows down SQL execution - Latency numbers that would make your Redis cry And the worst part? You’re not the database admin. That means: - No installing PGVector for AI search - No PG Cron for internal scheduling - No PG Crypto for secure operations - Sometimes, you don’t even *know* which region your database is in Suddenly, your “one tool for everything” dream feels like playing Elden Ring… with a potato for a GPU. … ## 4. Row-level security: when theory trolls reality ... You set rules so each user only sees the rows they’re allowed to. No more messing around with manual filters in your app layer the database enforces it for you. Then you turn it on in production… and suddenly, every query plan looks like it just rolled a critical fail. What used to be a fast `SELECT` now feels like it’s doing a 14-table join for fun. Indexes? Still there, but apparently on vacation. ... But here’s what actually happens: - Debugging becomes a questline from hell no proper stack traces, no modern logging tools, just squinting at SQL like it’s an ancient scroll. - Version control turns into duct tape your stored procedure updates live in random `.sql` files or, worse, only exist in production and nobody remembers who wrote them. - Your CI/CD pipeline? Doesn’t even know this logic exists, so testing is… let’s say “optional.” One developer summed it up perfectly: > *“If you maintain jobs and business logic inside Postgres, you’re giving up git for guesswork.”* It’s not that stored procedures are evil they’re great for certain performance-critical cases but making them the *default* place for all your application logic is asking for future pain. When that pain hits, it doesn’t matter how elegant your SQL was you’ll be the one spelunking through functions at 2 AM while prod is down.
Related Pain Points4件
Stored procedures lack version control, CI/CD integration, and debugging capabilities
7Business logic and jobs stored in PostgreSQL stored procedures have no git version control, exist only in production without documentation of authorship, and cannot be tested in CI/CD pipelines. Debugging is difficult without proper stack traces or logging tools, making maintenance a time-consuming nightmare.
Network latency and infrastructure constraints in enterprise environments
7In corporate production environments, database requests traverse multiple network hops through firewalls and antivirus software, causing severe latency issues. Developers lack control over database configuration and cannot install extensions like PGVector, PG Cron, or PG Crypto, and often don't know which region their database is deployed in.
Row-Level Security (RLS) causes severe query performance degradation
7When Row-Level Security is enabled in production, query execution plans degrade dramatically. Fast SELECT queries become slow with unexpected multi-table joins, and indexes become ineffective, turning a simple database operation into a performance nightmare.
Schema migrations cause downtime due to exclusive locking on busy tables
7Certain PostgreSQL schema changes (like adding NOT NULL UNIQUE columns or renaming columns) require exclusive locks that block all other queries. On busy tables, migrations can be delayed waiting for exclusive locks, causing production downtime. Constraint backfilling and backwards-incompatible changes require multi-step migration processes.