PostgreSQL vs MongoDB: Why Postgres Is Almost Always the Right Choice

PostgreSQL is the better default database for nearly every project. Unless you already know — with 100% certainty — that your workload demands a specific MongoDB capability, start with Postgres. PostgreSQL's JSONB support handles document-style data natively, its ACID transactions guarantee data integrity, and extensions like pgvector add vector search without a second database. A 2024 Stack Overflow survey found PostgreSQL is the most-wanted and most-used database among professional developers for the fourth consecutive year, used by 49% of respondents — nearly double MongoDB's 25%. With PostgreSQL, you get relational integrity, flexible JSON storage, full-text search, and an ecosystem of managed hosting options with generous free tiers.

TL;DR

Always start with PostgreSQL. If you need MongoDB, you already know it — and you would not be reading this guide. You can always migrate to MongoDB later if it turns out to be the correct choice (it almost never is). PostgreSQL handles 95%+ of real-world workloads better than MongoDB, and switching away from it is rarely necessary.

What Are PostgreSQL and MongoDB?

If you are new to databases, here is what you need to know. PostgreSQL (often called "Postgres") is a relational database. It stores data in tables with rows and columns — think of it like a spreadsheet where every row has the same columns. You use SQL (Structured Query Language) to read and write data. SQL has been the standard for decades and is used by nearly every database, BI tool, and data platform.

MongoDB is a document database (also called NoSQL). Instead of tables, it stores data as JSON-like documents — each document can have different fields. You use MongoDB's own query language (MQL) instead of SQL. MongoDB became popular around 2012–2015 when "NoSQL" was trendy, but many teams that adopted it early have since migrated back to PostgreSQL.

-- Create a table with a fixed schema
CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  email TEXT UNIQUE NOT NULL,
  created_at TIMESTAMPTZ DEFAULT now()
);

-- Insert a row
INSERT INTO users (name, email) VALUES ('Alice', 'alice@example.com');

-- Query with SQL
SELECT name, email FROM users WHERE created_at > '2026-01-01';

// Documents can have different shapes
db.users.insertOne({
  name: "Alice",
  email: "alice@example.com",
  createdAt: new Date(),
  // This field might not exist in other documents
  preferences: { theme: "dark", language: "en" }
});

// Query with MQL
db.users.find({ createdAt: { $gt: new Date("2026-01-01") } });

How Did We Get Here? A Brief History

Understanding why MongoDB became popular — and why that popularity has been fading — helps you avoid repeating the same mistake many teams made.

The Rise of MongoDB (2009–2015)

MongoDB launched in 2009, at the peak of the "NoSQL movement." The pitch was seductive: no schemas, no SQL, just store JSON. It felt faster to get started with — no need to design tables upfront, no migrations, no foreign keys. For developers coming from JavaScript, it was especially appealing: the same JSON format from frontend to backend to database.

Then came the MEAN stack (MongoDB, Express, Angular, Node.js) around 2013. Tutorials, bootcamps, and YouTube courses all taught MEAN as the way to build web apps. MongoDB was not chosen because experienced database engineers evaluated it against alternatives — it was bundled into a beginner-friendly stack because it was "all JavaScript, all the way down." Thousands of developers learned MongoDB as their first and only database, never realizing there were trade-offs.

The MEAN/MERN hype created a generation of developers who genuinely believed MongoDB was a general-purpose database. Companies adopted it for workloads it was never designed for: e-commerce with complex inventory relationships, financial systems requiring transactions (which MongoDB did not even support until 2018), and analytics dashboards that needed joins across collections. The result was a wave of painful rewrites and migrations back to relational databases.

The Rise of PostgreSQL (2015–Present)

While MongoDB was riding tutorial hype, PostgreSQL was quietly becoming the most capable database on the planet. Key milestones:

• 2012 — JSONB support landed, giving PostgreSQL native document-storage capabilities. This eliminated MongoDB's core selling point for most use cases.
• 2016 — Parallel query execution made complex analytical queries dramatically faster on multi-core hardware.
• 2017 — Logical replication enabled flexible data streaming between PostgreSQL instances.
• 2018 — MongoDB changed its license to SSPL, which is not considered open source by the OSI. AWS, Google Cloud, and others dropped managed MongoDB offerings. Meanwhile, PostgreSQL remained under its permissive, truly open-source license.
• 2021 — pgvector brought vector similarity search to PostgreSQL, positioning it for the AI era.
• 2022–2024 — Neon, Supabase, and serverless PostgreSQL platforms exploded in popularity, making PostgreSQL as easy to start with as MongoDB ever was — free tiers, instant provisioning, zero configuration.

The trajectory is clear. MongoDB's adoption was driven by marketing, bootcamp curriculum, and the "NoSQL" trend. PostgreSQL's adoption was driven by engineers who evaluated the options and chose the tool that solved more problems with fewer trade-offs. Today, PostgreSQL is the #1 most-used and most-loved database in every major developer survey — a position earned by capability, not hype.

How Do PostgreSQL and MongoDB Compare?

Why PostgreSQL Wins for Most Projects

1. JSONB eliminates MongoDB's main selling point

The most common reason teams choose MongoDB is "we need flexible JSON storage." PostgreSQL's JSONB type gives you exactly that — with the added benefit of SQL joins, transactions, and GIN indexing on JSON paths. You get document storage and relational integrity in one database.

-- Store flexible JSON documents in PostgreSQL
CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  attributes JSONB NOT NULL DEFAULT '{}'
);

-- Index specific JSON paths for fast lookups
CREATE INDEX idx_products_category ON products ((attributes->>'category'));

-- Query JSON fields with SQL — combine relational and document queries
SELECT name, attributes->>'color' AS color
FROM products
WHERE attributes->>'category' = 'electronics'
  AND (attributes->>'price')::numeric < 500
ORDER BY (attributes->>'price')::numeric;

-- Check if a JSON document contains a key
SELECT name FROM products WHERE attributes ? 'warranty';

-- Update a nested JSON field without rewriting the whole document
UPDATE products
SET attributes = jsonb_set(attributes, '{price}', '299.99')
WHERE name = 'Keyboard';

2. ACID transactions matter more than you think

Every SaaS app, e-commerce system, or financial application needs transactions. PostgreSQL has had full ACID compliance since its inception. MongoDB added multi-document transactions in v4.0 (2018), but they come with performance overhead and a 60-second time limit. If you are building anything that involves money, user accounts, or inventory — PostgreSQL's transaction model is strictly superior.

What is ACID? ACID stands for Atomicity, Consistency, Isolation, and Durability. In plain terms: either all your changes happen together, or none of them do. If your app transfers money between accounts, ACID guarantees the debit and credit both succeed — you will never lose money to a half-completed operation.

-- Transfer $100 from account A to account B
-- If anything fails, NOTHING happens — your data stays consistent
BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 'A';
  UPDATE accounts SET balance = balance + 100 WHERE id = 'B';
  -- If account A doesn't have enough funds, roll back
  -- (enforced by a CHECK constraint on the table)
COMMIT;

3. SQL is a career-long skill

SQL is a universal, standardized language. Every developer knows it, every BI tool supports it, and it transfers across PostgreSQL, MySQL, SQLite, and dozens of other databases. MongoDB's MQL is proprietary — your query knowledge is locked to one vendor. If you are just starting out, learning SQL is one of the highest-leverage skills you can invest in.

4. PostgreSQL scales further than you think

The "MongoDB scales horizontally" argument is overblown for 99% of projects. PostgreSQL handles millions of rows with proper indexing. Read replicas handle read scaling. The Citus extension adds true horizontal sharding. Amazon Aurora PostgreSQL serves workloads with 3x the throughput of standard PostgreSQL. Most applications will never need MongoDB's sharding — and if they do, they can migrate at that point.

5. Extension ecosystem is unmatched

PostgreSQL's extension system lets you add capabilities without switching databases:

Every one of these is a capability that would require a separate service or database in MongoDB's ecosystem. With PostgreSQL, it is a single CREATE EXTENSION statement.

When Would You Actually Need MongoDB?

There are a small number of genuine use cases where MongoDB is the better choice. But if any of these apply to you, you already know it — you would not be searching for "PostgreSQL vs MongoDB."

• Massive write-heavy IoT ingestion — millions of sensor readings per second with varying schemas, where you need native sharding across geographic regions (though TimescaleDB on PostgreSQL handles most time-series workloads — see below)
• Deeply nested, truly schema-less documents — CMS content with unlimited nesting levels and wildly varying structures that change constantly
• Real-time change streams at scale — MongoDB's change streams are more mature than PostgreSQL's logical replication for certain event-driven architectures
• Rapid prototyping with zero schema design — when you genuinely do not know what your data will look like yet and need to iterate fast (but be warned: you will pay for this flexibility later)

For everything else — SaaS apps, APIs, e-commerce, dashboards, analytics, user management, content platforms — PostgreSQL is the better choice.

MongoDB Use Case Deep Dive

To be fair to MongoDB, here is what it looks like when it is used correctly — for workloads that genuinely fit the document model:

// Each sensor type has completely different fields
// This is where MongoDB genuinely shines
db.sensorReadings.insertMany([
  {
    sensorId: "temp-001",
    type: "temperature",
    timestamp: new Date(),
    value: 23.5,
    unit: "celsius",
    location: { lat: 59.33, lng: 18.07 }
  },
  {
    sensorId: "vibr-042",
    type: "vibration",
    timestamp: new Date(),
    axes: { x: 0.02, y: 0.15, z: 0.01 },
    frequency: 120,
    alerts: ["threshold_warning"]
  },
  {
    sensorId: "cam-007",
    type: "image",
    timestamp: new Date(),
    resolution: "1920x1080",
    detectedObjects: ["person", "vehicle"],
    confidence: [0.95, 0.87]
  }
]);

// Time-series query — find recent high temperatures
db.sensorReadings.find({
  type: "temperature",
  value: { $gt: 30 },
  timestamp: { $gt: new Date(Date.now() - 3600000) }
}).sort({ timestamp: -1 });

// Blog posts, landing pages, and product pages all in one collection
// Each has wildly different content structures
db.pages.insertOne({
  slug: "/blog/my-post",
  type: "blog",
  title: "My Post",
  blocks: [
    { type: "heading", level: 1, text: "Introduction" },
    { type: "paragraph", text: "Some content..." },
    { type: "image", src: "/img/photo.jpg", alt: "A photo", caption: "Fig 1" },
    { type: "code", language: "python", source: "print('hello')" },
    {
      type: "table",
      headers: ["Name", "Score"],
      rows: [["Alice", 95], ["Bob", 87]]
    },
    {
      type: "callout",
      variant: "warning",
      children: [
        { type: "paragraph", text: "Be careful with this approach." }
      ]
    }
  ],
  metadata: {
    author: "Alice",
    tags: ["tutorial", "python"],
    seo: { description: "A tutorial", ogImage: "/img/og.jpg" }
  }
});

Notice the pattern: MongoDB's sweet spot is data where every record has a genuinely different shape and you need to query across them. If your documents all have the same fields (users, orders, products), you are better off with PostgreSQL tables.

What About Time-Series and IoT Data? TimescaleDB Changes the Equation

One of MongoDB's strongest remaining arguments is IoT and time-series data. But TimescaleDB — a PostgreSQL extension — largely eliminates this advantage too. TimescaleDB turns PostgreSQL into a purpose-built time-series database with automatic partitioning by time, columnar compression that achieves 90–98% storage reduction, and continuous aggregation for real-time rollups. It handles millions of inserts per second on a single node.

-- Install TimescaleDB (available on most managed PostgreSQL providers)
CREATE EXTENSION IF NOT EXISTS timescaledb;

-- Create a regular table, then convert it to a hypertable
CREATE TABLE sensor_data (
  time        TIMESTAMPTZ NOT NULL,
  sensor_id   TEXT NOT NULL,
  temperature DOUBLE PRECISION,
  humidity    DOUBLE PRECISION,
  metadata    JSONB  -- flexible fields per sensor type
);

-- This single command enables automatic time-based partitioning
SELECT create_hypertable('sensor_data', by_range('time'));

-- Insert millions of rows — TimescaleDB handles partitioning automatically
INSERT INTO sensor_data (time, sensor_id, temperature, humidity)
VALUES (now(), 'temp-001', 23.5, 65.2);

-- Time-series queries with SQL — no new query language to learn
SELECT
  time_bucket('1 hour', time) AS hour,
  sensor_id,
  AVG(temperature) AS avg_temp,
  MAX(temperature) AS max_temp
FROM sensor_data
WHERE time > now() - INTERVAL '7 days'
GROUP BY hour, sensor_id
ORDER BY hour DESC;

-- Enable columnar compression — 90-98% storage reduction
ALTER TABLE sensor_data SET (
  timescaledb.compress,
  timescaledb.compress_segmentby = 'sensor_id'
);
SELECT add_compression_policy('sensor_data', INTERVAL '7 days');

-- Continuous aggregates — pre-computed rollups, updated automatically
CREATE MATERIALIZED VIEW hourly_temps
WITH (timescaledb.continuous) AS
SELECT
  time_bucket('1 hour', time) AS bucket,
  sensor_id,
  AVG(temperature) AS avg_temp,
  COUNT(*) AS readings
FROM sensor_data
GROUP BY bucket, sensor_id;

With TimescaleDB, you get time-series performance that matches or exceeds MongoDB's, while keeping full SQL, ACID transactions, and joins with your relational data. Your sensor readings can reference your users table, your devices table, and your billing table — all in one query. That is something MongoDB cannot do without denormalizing everything. TimescaleDB is available on Neon, Supabase, Aiven, AWS RDS, and most other managed PostgreSQL providers.

Security: MongoDB's Dangerous History of Insecure Defaults

This is one area where PostgreSQL has always been significantly safer. MongoDB shipped without authentication enabled by default until version 2.6 (2014). That means for years, a fresh MongoDB installation would accept connections from anyone on the internet with zero credentials. The consequences were catastrophic.

The MongoDB Ransomware Epidemic

In 2017, attackers launched automated scans for unprotected MongoDB instances. They found over 208,500 publicly exposed MongoDB servers, with 3,100 fully accessible without any authentication. Of those exposed servers, 45.6% (1,416 instances) had already been wiped — databases deleted and replaced with ransom notes demanding ~$500 in Bitcoin. A 2020 study found that an unprotected MongoDB instance is breached within an average of 13 hours of being connected to the internet, with the fastest recorded breach at just 9 minutes.

These attacks continue today. Researchers have identified 763 Docker container images containing insecure MongoDB configurations — binding to all network interfaces without authentication — that collectively have tens of thousands of pulls.

Security Comparison

If You Must Use MongoDB: Security Checklist

# ALWAYS enable authentication
security:
  authorization: enabled

# NEVER bind to 0.0.0.0 in production
net:
  bindIp: 127.0.0.1
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

# Disable the legacy HTTP interface and REST API
net:
  http:
    enabled: false

PostgreSQL, by contrast, ships secure by default. Authentication is required, it only listens on localhost, and pg_hba.conf gives you fine-grained control over which users can connect from which hosts using which authentication methods.

How Do They Scale?

Scaling is the most misunderstood argument in the PostgreSQL vs MongoDB debate. Here is how each actually scales in practice:

PostgreSQL Scaling Patterns

• Vertical scaling — increase CPU, RAM, and storage. A single PostgreSQL instance can handle terabytes of data and thousands of concurrent connections with proper tuning. This is enough for the vast majority of applications.
• Read replicas — route read queries to replica instances. Most apps are 90%+ reads, so this multiplies your capacity significantly.
• Connection pooling — use PgBouncer or Supavisor to handle thousands of connections with a small number of actual database connections.
• Table partitioning — split large tables by date, region, or tenant. Built into PostgreSQL, no extensions needed.
• Citus (horizontal sharding) — distributes data across multiple PostgreSQL nodes. Handles petabyte-scale workloads. Now open source and available on Azure.
• Amazon Aurora — PostgreSQL-compatible with 3x throughput, up to 128 TB of storage, and up to 15 read replicas with sub-10ms replica lag.

MongoDB Scaling Patterns

• Replica sets — automatic failover with primary/secondary nodes. Similar to PostgreSQL read replicas.
• Native sharding — MongoDB's main scaling advantage. Data is distributed across shards by a shard key. Good for write-heavy workloads that can be partitioned cleanly.
• Zone sharding — pin data to specific geographic regions. Useful for data residency requirements.

The reality: most applications never outgrow a single PostgreSQL instance with read replicas. Premature sharding adds massive operational complexity. If you do not already have millions of users, you do not need horizontal sharding — and by the time you do, you will have the team and budget to implement it regardless of which database you chose.

How Do Backups and Recovery Compare?

PostgreSQL Backups

PostgreSQL has mature, battle-tested backup tools built in:

# Logical backup — portable, human-readable SQL dump
pg_dump --format=custom mydb > mydb.dump

# Restore from a logical backup
pg_restore --dbname=mydb mydb.dump

# Physical backup — block-level copy, faster for large databases
pg_basebackup -D /backups/mydb -Ft -z -P

# Continuous archiving (WAL) — point-in-time recovery (PITR)
# Restore your database to ANY point in time, down to the second
# Configured in postgresql.conf:
#   archive_mode = on
#   archive_command = 'cp %p /archive/%f'

# Managed services (Neon, Supabase, RDS, Aurora) handle all of this
# automatically — daily snapshots + continuous WAL archiving

MongoDB Backups

# Logical backup — dumps BSON
mongodump --uri="mongodb://localhost:27017/mydb" --out=/backups/

# Restore from logical backup
mongorestore --uri="mongodb://localhost:27017/mydb" /backups/mydb/

# For replica sets — use filesystem snapshots or mongodump with --oplog
mongodump --oplog --out=/backups/

# MongoDB Atlas handles automated backups with point-in-time recovery
# Self-hosted: you need to configure oplog-based backups yourself

Both databases support point-in-time recovery, but PostgreSQL's WAL-based archiving is more mature and widely supported across hosting providers. Every managed PostgreSQL provider includes automated backups in their base plans. For MongoDB, point-in-time recovery is only available on Atlas or requires careful self-managed oplog configuration.

What About Migrating Later?

Starting with PostgreSQL is the safer bet because migrating from PostgreSQL to MongoDB is straightforward — export your data as JSON and import it. Migrating from MongoDB to PostgreSQL is painful — you need to design a relational schema, normalize denormalized data, and rewrite all queries from MQL to SQL. Starting with PostgreSQL keeps both doors open. Starting with MongoDB locks you in.

# Step 1: Export PostgreSQL data as JSON
psql -d mydb -c "COPY (SELECT row_to_json(t) FROM users t) TO STDOUT" > users.json

# Step 2: Import into MongoDB
mongoimport --db=mydb --collection=users --file=users.json

# That's it. Your relational data maps cleanly to documents.
# The reverse (MongoDB → PostgreSQL) requires schema design,
# data normalization, and rewriting every query.

Where to Host PostgreSQL (Free and Cheap)

PostgreSQL has fierce competition among managed hosting providers, driving prices down and free tiers up.

Recommendation: Start with Neon or Supabase for side projects and prototypes (both have generous free tiers). Move to DigitalOcean or AWS RDS for production workloads.

Where to Host MongoDB (Free and Cheap)

If you do end up needing MongoDB, here are your options:

Note: MongoDB Atlas is the only provider with a truly free forever tier for MongoDB. Most other providers charge from the start or offer limited trial credits.

What Else Should You Consider?

If you are choosing PostgreSQL (and you should), your next decision is which managed PostgreSQL service to use. The big three cloud providers all offer enhanced PostgreSQL services that go beyond standard hosted Postgres:

Amazon Aurora PostgreSQL

Aurora is AWS's PostgreSQL-compatible engine with 3x the throughput of standard PostgreSQL. It separates storage from compute, automatically replicates data across 3 availability zones, and supports up to 128 TB of storage. Aurora Serverless v2 can scale to zero when idle, making it cost-effective for variable workloads. This is the go-to choice if you are already in the AWS ecosystem and need high availability without managing replication yourself.

Google Cloud SQL & AlloyDB

Google offers two options. Cloud SQL for PostgreSQL is their standard managed offering — simple, reliable, well-integrated with other GCP services. For higher performance, AlloyDB is Google's answer to Aurora — a PostgreSQL-compatible engine optimized for demanding transactional and analytical workloads. AlloyDB claims up to 4x faster transactional performance than standard PostgreSQL and 100x faster analytical queries.

Azure Database for PostgreSQL

Azure's managed PostgreSQL supports elastic clusters (powered by Citus) for horizontal scaling, native vector search and AI extensions, and autonomous performance tuning with machine learning. Microsoft claims up to 58% TCO savings compared to on-premises deployments. The Citus integration is unique — it means you get true horizontal sharding built into your managed service, which is a direct competitor to MongoDB's sharding story.

The key takeaway: PostgreSQL's managed ecosystem is far larger and more competitive than MongoDB's. You have options at every price point, from free (Neon, Supabase) to enterprise (Aurora, AlloyDB).

Can You Use Both?

Yes — and sometimes you should. If part of your data genuinely fits the document model (deeply nested CMS content, event logs with wildly varying schemas) while the rest is relational (users, billing, inventory), you can run PostgreSQL as your primary database and MongoDB as a specialized store for the data that benefits from it. This is more common than people think:

• PostgreSQL for core data — users, accounts, orders, permissions, billing, anything with relationships and transactions
• MongoDB for document-shaped data — CMS blocks, chat message metadata, ML feature stores, or event payloads that vary per event type
• Duplicated data for different access patterns — store the canonical data in PostgreSQL and replicate a denormalized copy to MongoDB for read-heavy queries that benefit from the document model (or vice versa)

The trade-off is operational complexity: two databases means two backup strategies, two monitoring setups, two sets of credentials, and data synchronization logic. For most teams, that overhead is not worth it — PostgreSQL with JSONB covers both patterns well enough. But for large teams with specialized workloads, a polyglot persistence approach can be the right call.

The Pragmatic Take: Optimal vs Good Enough

Not every decision needs to be technically optimal. Sometimes the suboptimal choice is the right choice when you factor in cost, security, operational complexity, and team expertise. A database that is 10% slower for your specific access pattern but 50% cheaper to run, requires no additional security hardening, and your team already knows inside out — that is a reasonable trade-off.

This pragmatism cuts both ways. If your team has deep MongoDB experience and your workload is document-shaped, running MongoDB with acceptable trade-offs in transaction safety might be fine. If your workload is technically better suited to MongoDB's document model but your team knows PostgreSQL, the overhead of learning a new database and its security footprint might not be worth the marginal performance gain.

The key insight is that this pragmatic calculation almost always favors PostgreSQL:

• Cost — PostgreSQL is open source with a permissive license. MongoDB's SSPL license restricts how you can offer it as a service, and advanced features (audit logging, encryption at rest, LDAP auth) require the paid Enterprise edition or Atlas.
• Security — PostgreSQL ships secure by default. MongoDB requires careful hardening to avoid becoming a ransomware target.
• Complexity — one database is simpler than two. PostgreSQL with JSONB covers both relational and document patterns, so you rarely need a second database.
• Hiring — SQL is universal. Every developer, data analyst, and BI tool speaks SQL. Finding MongoDB-specific expertise is harder and more expensive.
• Ecosystem — more managed hosting options, more extensions, more tooling, more community support, and more competitive pricing.

The bottom line: choose the database that minimizes your total cost of ownership — and for most teams, that is PostgreSQL. But if your specific situation genuinely calls for MongoDB, do not fight it. Just make sure the reasons are real and not based on outdated assumptions about PostgreSQL's limitations.

Quick Start: PostgreSQL in 30 Seconds

# Start PostgreSQL locally
docker run -d --name postgres \
  -e POSTGRES_PASSWORD=devpassword \
  -e POSTGRES_DB=myapp \
  -p 5432:5432 \
  postgres:17

# Connect
psql postgresql://postgres:devpassword@localhost:5432/myapp

# Sign up at neon.tech, then connect with any PostgreSQL client
psql "postgresql://user:pass@ep-cool-name-123456.us-east-2.aws.neon.tech/mydb?sslmode=require"

Frequently Asked Questions

References

• PostgreSQL Official Documentation — comprehensive reference for all PostgreSQL features, SQL syntax, and configuration
• MongoDB Official Documentation — reference for MongoDB queries, aggregation pipeline, and Atlas configuration
• AWS: MongoDB vs PostgreSQL Comparison — vendor-neutral breakdown of data models, scalability, and use cases
• Amazon Aurora — PostgreSQL-compatible with 3x throughput, up to 128 TB storage, and serverless scaling
• Google Cloud SQL — managed PostgreSQL, MySQL, and SQL Server on Google Cloud Platform
• Azure Database for PostgreSQL — managed PostgreSQL with Citus elastic clusters and AI extensions
• Snyk: The MongoDB Hack and the Importance of Secure Defaults — analysis of MongoDB's insecure defaults and the resulting data breaches
• Neon — Serverless PostgreSQL — managed PostgreSQL with branching, autoscaling, and a free tier