Every new project starts with the same question: what database should we use? In 2026, the answer is simultaneously simpler and more complicated than ever. Simpler because one database has pulled so far ahead of the pack that it’s the default choice for most workloads. More complicated because the ways you can deploy and consume that database have multiplied dramatically.
Let’s cut through the noise.
TL;DR
- PostgreSQL has become the default database for the vast majority of web application workloads in 2026
- Serverless Postgres platforms (Neon, Supabase) offer scale-to-zero pricing and instant provisioning, ideal for startups and side projects
- Edge databases like Turso and Cloudflare D1 solve latency problems for globally distributed applications
- Document databases still have their place, but PostgreSQL’s JSONB support has narrowed the gap considerably
- The best database decision is the one that matches your actual access patterns, not the one that looks best on a conference slide
PostgreSQL Won. Accept It.
This isn’t a hot take anymore. It’s a statement of fact. Over 48,000 companies use PostgreSQL, including Netflix, Spotify, Uber, Reddit, Instagram, and Discord. Stack Overflow’s developer surveys have placed it at the top of the “most wanted” and “most used” database lists for years running. PostgreSQL 18, released in late 2025, brought further improvements to performance, logical replication, and JSON path queries.
Why did Postgres win? A few reasons that compound over time:
- It handles almost everything. Relational data, JSON documents, full-text search, geospatial queries, time-series data, vector embeddings for AI. Most teams never need a second database.
- The extension ecosystem is extraordinary. PostGIS for geography. pgvector for AI embeddings. TimescaleDB for time-series. Citus for horizontal sharding. These aren’t bolted-on afterthoughts; they’re deeply integrated.
- It’s genuinely open source. No “open core” licensing games, no surprise relicensing. The PostgreSQL licence is one of the most permissive in existence.
- Reliability is proven at scale. Banks, governments, and the largest tech companies in the world trust it with their most critical data.
If you’re starting a new project and have no specific reason to choose something else, use Postgres. This is not a controversial position in 2026.
The Serverless Postgres Revolution
Where things get interesting is in how you run Postgres. Traditional managed Postgres (AWS RDS, Google Cloud SQL, Azure Database) works fine but comes with fixed costs. You’re paying for a server whether it’s serving requests or sitting idle at 3am.
Serverless Postgres changes the economics entirely. Platforms like Neon and Supabase have built services that scale to zero when idle and spin up instantly when traffic arrives. For startups, side projects, and applications with variable traffic patterns, this is transformative.
Neon
Neon separates compute from storage, which enables features that traditional Postgres simply can’t offer. Database branching lets you create instant, copy-on-write clones of your production database for testing or development. Scale-to-zero means you pay nothing when the database isn’t in use. And because it’s still standard Postgres under the hood, your existing tools, ORMs, and queries work without modification.
The trade-off? Cold starts. When a database scales from zero, there’s a brief latency hit on the first connection. For user-facing applications with consistent traffic, this rarely matters. For cron jobs or infrequent batch processes, it’s something to plan for.
Supabase
Supabase takes a different approach, wrapping Postgres with an entire backend-as-a-service layer: authentication, real-time subscriptions, edge functions, and auto-generated REST and GraphQL APIs. It’s particularly popular with frontend developers who want a Firebase-like experience without the vendor lock-in of a proprietary database.
The distinction matters: Neon is for teams that want serverless Postgres and nothing more. Supabase is for teams that want a complete backend platform built on Postgres. Both are valid choices, but they solve different problems.
Edge Databases: When Latency is the Enemy
For applications serving a global audience, even fast Postgres in a single region introduces latency that users can feel. A request from Tokyo to a database in Dublin takes roughly 250ms for the round trip alone, before your query even executes.
Edge databases tackle this by distributing data closer to users. Two approaches dominate:
Turso uses libSQL (a fork of SQLite) with embedded replication to place read replicas at edge locations worldwide. Writes go to a primary node and replicate outward. For read-heavy workloads, which describes most web applications, this dramatically reduces latency without requiring a distributed database architecture.
Cloudflare D1 takes a similar SQLite-based approach but integrates tightly with Cloudflare Workers. If you’re already building on Cloudflare’s edge platform, D1 is the natural database companion.
The limitation of both is that they use SQLite, not Postgres. Your team needs to be comfortable with SQLite’s type system and query capabilities, which are more constrained. For many applications, particularly content-heavy sites, APIs with predictable query patterns, and mobile app backends, that’s a worthwhile trade-off. For complex analytics or applications that rely heavily on Postgres-specific features, it’s not.
When Document Databases Still Make Sense
MongoDB, DynamoDB, and their kin aren’t dead, despite what some Postgres enthusiasts might claim. They still excel in specific scenarios:
- Truly schema-less data where the structure of documents varies significantly and unpredictably. Postgres JSONB handles semi-structured data well, but if your entire data model is document-oriented, a purpose-built document database may be a better fit.
- Massive write throughput at scale. DynamoDB’s provisioned and on-demand capacity modes handle write-heavy workloads with predictable latency in ways that require significant Postgres tuning to match.
- Existing team expertise. If your team knows MongoDB inside out and your application fits a document model, switching to Postgres purely because it’s trendy would be a poor engineering decision.
That said, we’ve seen many teams successfully consolidate from a Postgres-plus-MongoDB architecture to Postgres-only by using JSONB columns for their flexible data needs. Fewer databases means fewer operational concerns, fewer backup strategies, and fewer things to monitor at 2am.
The Decision Framework
Rather than chasing trends, match your database to your actual requirements:
| Scenario | Recommendation |
|---|---|
| General web application, SaaS | PostgreSQL (managed or serverless) |
| Startup / MVP with variable traffic | Neon or Supabase (scale-to-zero) |
| Global app, read-heavy, low latency critical | Turso or D1 at the edge |
| Complete backend platform needed fast | Supabase |
| Massive write throughput, AWS-native | DynamoDB |
| AI/ML with vector search | PostgreSQL + pgvector |
| Time-series / IoT data | PostgreSQL + TimescaleDB |
The common thread? PostgreSQL covers an astonishing range of use cases. You need a specific, compelling reason to choose something else, not the other way around.
What We See at REPTILEHAUS
Across our client projects, PostgreSQL is our default recommendation, and has been for years. What’s changed recently is the deployment model. We’re increasingly using serverless Postgres for early-stage products where cost predictability matters, and edge databases for applications with global user bases.
The database decision isn’t just about features. It’s about operational cost, team familiarity, scaling characteristics, and how well it integrates with your broader architecture. Getting that decision right at the start saves enormous pain later. Getting it wrong means a costly migration project somewhere down the line.
If you’re architecting a new application and want to make sure your data layer is built on solid foundations, talk to us. We’ve made these decisions dozens of times and can help you avoid the common pitfalls.
📷 Photo by Kevin Ache on Unsplash
