PostgreSQL

The recently released queryCompiler feature in Prisma 6.7.0+ has introduced critical bugs affecting data integrity: JSONB columns return empty objects, String[] fields are returned as comma-separated strings instead of arrays, date fields become empty objects, and relations with @map fail to parse. Multiple users report broken functionality across PostgreSQL, D1 (SQLite), and other databases.

SQL injection vulnerabilities from unescaped user input interpolation remain the perennial top contender for most financially damaging application security vulnerability. Developers continue to make mistakes in this area.

As Supabase apps scale, critical performance issues surface including connection exhaustion and long-running queries that become operational bottlenecks. Developers lack clear monitoring signals for cache hit ratio and query performance.

PostgreSQL experiences table corruption problems that can result in data integrity issues. This was significant enough to motivate organizations like Uber to evaluate alternative databases.

PostgreSQL is not optimal for applications requiring real-time or near-real-time analytics. For massive single datasets (billions of rows, hundreds of gigabytes) with frequent joins, queries can take hours. PostgreSQL lacks native columnar storage support, necessitating non-core extensions and increasing architectural complexity.

Self-hosted Sentry is a distributed system requiring management of PostgreSQL, ClickHouse, Kafka, and Redis. It demands dedicated DevOps/SRE resources for scaling and maintenance, often resulting in total cost of ownership exceeding SaaS pricing.

Custom admin panels that work for small teams degrade rapidly as the user base or data grows, leading to performance issues, broken queries, and unexpected feature failures. Significant rebuilding is often required if scalability wasn't planned from day one.

PostgreSQL does not support in-place major version upgrades. Upgrades require either dumping and restoring the entire dataset or setting up logical replication, with rigorous application compatibility testing required. Delaying upgrades increases complexity and risk, as outdated versions miss critical security patches, transforming routine maintenance into a complex, high-risk migration project.

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

PostgreSQL default installations can allow passwordless logins ('Trust' method) if not managed, lack robust password policies, do not enable SSL/TLS encryption by default, and commonly grant unnecessary superuser privileges. Many vulnerabilities stem from misconfiguration and operational oversight rather than software flaws.

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

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

As agentic workloads caused 50x increase in branch creation, Neon experienced classic PostgreSQL failure modes including query plan drift and slow vacuum operations. Tables became more dependent on aggressive vacuuming, creating performance bottlenecks that weren't anticipated in the original system design.

PostgreSQL lacks native horizontal scalability features. When instance sizes become insufficient, teams experience downtime during scaling operations. Aurora vacuuming and scaling issues persist, and teams desire alternatives like CockroachDB that support true horizontal scaling without downtime.

PostgreSQL does not offer native multi-region replication capabilities. Organizations must rely on logical replication and third-party tools like pglogical or BDR, increasing vendor dependency, expertise requirements, and operational overhead while creating potential vendor lock-in risks.

Managing PostgreSQL replication requires intricate configuration and careful monitoring to prevent data loss or corruption. Achieving high availability demands automated failover mechanisms, load balancing between primary and standby servers, and selecting the appropriate replication strategy.

Complex database operations require writing PostgreSQL functions outside the main codebase, forcing developers to switch between TypeScript and SQL environments. This disrupts workflow and makes debugging harder for teams.

Common workarounds to extend DynamoDB (OpenSearch sync, RDS dual-write, Athena/Glue, Streams) introduce additional costs ($200-$1000/month), failure modes, operational overhead, and require specialized expertise. They essentially negate DynamoDB's simplicity benefit.

Read-heavy workloads like reporting and analytics can severely degrade performance if read replicas and caching layers aren't properly configured. This requires upfront architectural planning that many teams delay.

Write-heavy workloads with financial transactions and real-time updates require careful indexing and partitioning strategies to avoid slow inserts and locking issues. Without these, performance suffers significantly.

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

While Kubernetes can restart failed pods, it doesn't provide PostgreSQL-specific failover capabilities needed for production. Teams must implement tools like Patroni for proper leader election and failover, adding complexity and requiring dual expertise in both PostgreSQL and Kubernetes.

Teams sharing a single staging environment face resource contention and schema conflicts when multiple developers work simultaneously. Providing per-developer staging environments requires hundreds of database copies, creating management complexity and inefficient resource allocation.

PostgreSQL has an inefficient architecture for write operations compared to alternatives like MySQL. This limitation was significant enough for organizations like Uber to switch database systems.

When making schema changes to evolve the application's data handling, modifications either break tests immediately or don't, creating a worse scenario where tests no longer guarantee correctness. This requires iterative fixing of data integrity issues.

Creating secure admin panels for non-technical users requires juggling encryption, access control, and usability concerns. The complexity rivals building a secondary software system, making it difficult to maintain alongside the primary application.

PostgreSQL query execution plans can become unstable, causing previously performing queries to suddenly degrade. Developers must use advanced tools like Query Plan Management (QPM) and pg_hint_plan to ensure consistent query performance.

The 50x increase in branch creation caused the control plane database's CPU to become exhausted due to expensive billing and consumption calculations. These operations contributed significantly to the overall control plane degradation and cascading query performance issues.

As data volume grows to terabytes and petabytes, teams struggle to establish robust backup and recovery systems that ensure zero data loss. The complexity of managing backups at scale, combined with the need for rapid recovery, creates operational burden and concerns about data durability.

SQLite's default flexible typing allows values of any type to be stored in any column, which works during development but causes applications to fail when migrated to stricter databases like PostgreSQL or SQL Server that enforce type rules.

Building complex SQL queries is tedious, error-prone, and time-consuming. Developers frequently resort to AI assistance rather than writing queries manually, and must often redo work when requirements change or new clients appear.

Configuration adjustments require a full server restart to take effect, making it risky to tune in production. Logs are noisy and difficult to access in ephemeral or PaaS environments, especially without tools like PG Badger.

Unused or duplicate indexes cause every database modification to unnecessarily update those indexes, resulting in high storage utilization and IOPs consumption. This creates a silent performance drag that isn't immediately obvious.

PostgreSQL's built-in replication replicates entire clusters with the same settings and priority, not individual databases. This forces teams to manage multiple separate clusters to control replication groups, significantly increasing management complexity and operational overhead.

Development teams unfamiliar with expressive data modeling often fail to apply important constraints like foreign keys, instead relying on familiar application-level patterns. This results in databases without essential integrity constraints.

PostgreSQL's MVCC implementation copies all columns of a tuple when any column is modified, regardless of which columns change. This causes significant data duplication and increased storage demands, especially for large tables with many columns. No practical workaround exists without major PostgreSQL rewrites.

Configuring autovacuum correctly is challenging due to its complexity. Default global settings are inappropriate for large tables with millions/billions of tuples. If autovacuum invocations take too long or are blocked, dead tuples accumulate and statistics become stale, causing gradual query slowdown. Manual intervention is often required.

PostgreSQL replicas apply WAL updates, making replicas identical copies of the master at any point in time. They don't have true replica MVCC support, preventing queries from reading different versions of data on replicas compared to the primary. This design poses significant constraints for distributed systems.

Prisma lacks native support for PostgreSQL's pg_vector extension, forcing developers to either use raw queries (losing type safety) or unsupported type declarations with no query generation support.

Diagnosing failures becomes increasingly difficult when issues could originate from the database or application code. Long workflows and complex database-side logic require extensive investigation, making root cause analysis time-consuming.

Supabase's complexity creates barriers for novice developers, compounded by limited community support and insufficient documentation tailored to beginners. The platform requires significant SQL and database knowledge to use effectively.

Supabase support sometimes refuses to help with complex PostgreSQL issues, claiming they are database questions rather than platform questions. This can leave developers stuck without recourse.

Supabase lacks guides for structured database development. Developers must create workarounds like master GitHub repos of SQL commands and custom documentation, making collaboration and migration difficult.

Failing to implement connection pooling is a common mistake in PostgreSQL deployments. Each connection consumes approximately 10MB of RAM, and applications that create new connections for each database operation can quickly exhaust server resources, leading to performance degradation and application failures.

All tables, views, and functions default to the `public` schema in Supabase Studio, leading to poor organization and difficulty managing data as projects grow. Lack of logical separation for different data types (user data, billing, admin-only) creates maintenance challenges.

Working with JSON data in PostgreSQL requires special operators and functions that are difficult to use, especially with nested structures. While JSON saves time and space, querying it is error-prone.

Neon's re-architected PostgreSQL separates compute and storage into a networked system. This architectural change introduces new performance and latency challenges that developers must understand and mitigate compared to traditional monolithic PostgreSQL.

PostgreSQL requires extensive tuning across memory management, vacuum, background writer, write-ahead log, and free-space map settings. Configuration files are long with many unnecessary options for typical users. Default logging is unhelpful for new users, and there is no built-in out-of-band monitoring to diagnose startup failures or query issues without manually launching backends.

PostgreSQL validation returns only the first error per record, forcing developers to iterate through multiple correction cycles to resolve all data integrity issues. This extends debugging workflows substantially.

Failing to run VACUUM regularly can lead to bloated tables and degraded performance. Without VACUUM, PostgreSQL cannot reclaim space from deleted rows, accumulating dead tuples that consume disk space and slow down query performance over time.

Developers struggle to navigate database schemas with many foreign keys, jumping between related tables creates confusion and slows development speed even though foreign keys improve database architecture and performance.

PostgreSQL backup and restore tools have counter-intuitive workflows: pg_dump by default does not include global objects like roles, so backups are incomplete unless users manually dump additional information. pg_dumpall doesn't support custom format, and pg_restore requires non-obvious flags like -C to create databases. File naming conventions (.backup) are inconsistent with documentation.

Developers must make complex architectural decisions about which PostgreSQL extensions to use. For example, PostGIS for geospatial needs and pgvector for ML/embedding use cases are "killer apps," but selecting and integrating specialized extensions requires significant expertise.

Managing tables without primary keys presents challenges that scale poorly. No decent solution exists for identifying and managing missing primary keys in large-scale PostgreSQL deployments.

Using advanced PostgreSQL features like custom triggers and aggregations requires developers to write raw SQL directly, adding friction for those unfamiliar with database-level programming.

Using inconsistent data types across tables (e.g., SERIAL vs BIGINT for primary keys) can lead to unexpected behavior and foreign key relationship issues. This creates subtle bugs and requires careful schema design coordination across development teams.

PostgreSQL provides insufficient tracing and debugging capabilities for nested operations like PL/pgSQL calls and cascaded foreign key actions. Developers cannot easily understand what is happening in complex nested contexts without extensive manual investigation.

PostgreSQL documentation could be improved with better organization, clearer explanations, and more practical tutorials. This affects onboarding experience and developer productivity.