Just use Postgres

Postgres as the “Default”

• Many agree Postgres is an excellent default: powerful features (constraints, indexes, JSON/JSONB, full-text search, FDWs, RLS, etc.), strong tooling, and widely deployed.
• Some argue you should lean into Postgres-specific features instead of fearing lock-in; others prefer sticking to more portable SQL to ease future migrations or hedge against licensing changes.
• A minority note real gaps (e.g., native temporal tables, built-in multi-master HA) and that some advanced HA/replication is effectively paywalled in commercial distributions.

SQLite vs Postgres

• Pro-SQLite points: embeddable library, “just a file” backups, trivial snapshots, great for single-box apps, desktop/mobile, and small self‑hosted deployments. Some report years of reliable production use, even in regulated contexts, with periodic-snapshot RPOs.
• Caveats: defaults are unsafe unless tuned (foreign keys off, non-strict typing unless STRICT tables, WAL opt-in); limited ALTER TABLE operations; single-writer locking and potential app-wide blocking; not well suited to certain PaaS offerings.
• Pro-Postgres side argues that for server apps, a separate DB process is fine, overhead is small, and backup/maintenance are manageable; critics counter that major upgrades, backup/restore tooling, user management, and socket quirks are non-trivial.

MySQL/MariaDB and Other SQL Databases

• Several see little reason to choose MySQL now, citing historical footguns, stagnation, and Oracle ownership risk; MariaDB is viewed as better than MySQL but still behind Postgres and full of “nasty surprises.”
• Others highlight MySQL’s mature HA options (group replication, Galera), though Galera’s correctness is questioned.

MongoDB, DynamoDB, and NoSQL

• One camp: Mongo/NoSQL are overused by newcomers who want to avoid schemas; teams often “recreate SQL badly” on top. Concerns about consistency, denormalization locking in access patterns, and licensing (SSPL).
• Defenders say most criticisms are outdated or inaccurate: Mongo has sharding, replication, JSON schema validation, aggregation pipelines, change streams, and can scale to billions of documents and high QPS; Postgres also struggles at very large scales or across multiple machines.
• Dynamo-/KV-style systems: some emphasize needing well-known access patterns; others say schemas and indexes can evolve and that KV can encourage better service boundaries.

Business Logic, ORMs, and Architecture

• One side advocates writing SQL directly and pushing heavy business logic into the database (procedures, views, constraints) for performance and consistency; examples of long-lived systems benefitting from this.
• Others report poor developer experience with large stored-proc codebases (tooling, debugging, version control) and prefer hexagonal architectures where the DB is a replaceable adapter.
• ORMs are both criticized (abstraction, bad queries) and defended (productivity, consistent modeling, sometimes better query generation).

Scaling, Analytics, and Specialized Use Cases

• Postgres generally scales “far enough” for most companies; if you outgrow it, you likely can afford specialists.
• For heavy analytics, columnar/MPP systems (Snowflake, ClickHouse, Vertica) are said to outperform Postgres row storage.
• Horizontal write scaling for Postgres via Citus/logical replication exists, but HA and multi-master stories are seen as weaker than some alternatives.

AI, Vectors, and New Databases

• Disagreement over “AI is a bubble”: some dismiss dedicated vector DBs; others stress real needs for multimodal and semantic search.
• pgvector and SQLite vector extensions are noted as ways to keep using general-purpose SQL DBs while adding vector search.

Education and “Just Use X” Advice

• Bootcamps often teach MongoDB; some see this as giving students an easy but misleading intro (no migrations, implicit schema), others as a valid way to learn trade-offs.
• Multiple commenters caution against one-size-fits-all slogans: “just use Postgres” or “just use SQLite” works as a heuristic, but real choices should follow requirements, scale, environment, and team expertise.