Choose PostgreSQL.

For a four-person team building a greenfield, multi-tenant B2B SaaS with future analytics, PostgreSQL is the stronger default in 2026.

Why PostgreSQL wins here

• Database-enforced tenant isolation. PostgreSQL’s native row-level security lets you define policies such as tenant_id = current_setting(...), protecting tables even if application code forgets a tenant filter. MySQL lacks equivalent native RLS, leaving isolation primarily to application conventions—a meaningful risk in multi-tenant software (promptstoproduct.com, kunalganglani.com).

• Better fit for moderate analytics. PostgreSQL is generally stronger for complex joins, aggregations, CTEs, window functions, and mixed transactional/analytical queries. That gives you more headroom as reporting grows without immediately introducing a separate warehouse (devtoolswatch.com).

• More room for product expansion. Native arrays, strong jsonb indexing, full-text search, PostGIS, and pgvector can postpone extra infrastructure. That matters for a small team that should avoid operating separate search, geospatial, or vector systems prematurely (patotski.com).

• Strong managed-service ecosystem. Supabase, Neon, Railway, Render, Fly.io, and major cloud providers all offer managed PostgreSQL. Supabase and Neon are especially approachable for small teams, although production decisions should emphasize reliability and support rather than merely free tiers (promptstoproduct.com).

• Performance is not a deciding disadvantage. At typical early SaaS scale, both engines can comfortably handle the workload. MySQL can excel at highly concurrent, simple primary-key reads, but your expected multi-tenant and analytical requirements align more closely with PostgreSQL’s strengths.

How I would implement it

Use a managed PostgreSQL service, one shared schema, and a mandatory tenant_id on every tenant-owned table:

ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
USING (
  tenant_id = current_setting('app.tenant_id')::uuid
)
WITH CHECK (
  tenant_id = current_setting('app.tenant_id')::uuid
);

Then:

• Include tenant_id in relevant unique constraints and indexes.
• Use a non-owner application role subject to RLS; table owners and privileged roles can bypass policies.
• Set tenant context transaction-locally and use connection pooling carefully.
• Test cross-tenant reads, writes, joins, background jobs, exports, and migrations explicitly.
• Start analytics on read replicas or dedicated reporting tables/materialized views. Introduce a warehouse only when workload isolation or scale justifies it.

Why not MySQL?

MySQL would be reasonable if you were inheriting a MySQL application, deploying specifically on PlanetScale, or had unusually deep MySQL operational expertise. None of those advantages outweigh PostgreSQL’s RLS and analytics capabilities for this greenfield SaaS.

Decision: managed PostgreSQL, with RLS as defense in depth—not as a replacement for application authorization.

Choose PostgreSQL. Specifically, PostgreSQL 18 on a managed service.

That's the answer. Here's the argument, and then the concrete setup.

Why the ecosystem question is now settled

The strategic risk has flipped decisively in Postgres's favor. Oracle shipped MySQL 9.7.0 in May 2026 as the first LTS since 8.4, and it arrived amid community concerns about declining MySQL development activity and Oracle's long-term commitment to the project. Percona founder Peter Zaitsev estimated 60–70% of the engineers had left, and over 500 developers asked Oracle to create a vendor-neutral MySQL foundation — Oracle refused. The Innovation-release experiment didn't help adoption either: Percona declined to ship MySQL 9.x Innovation Releases at all, citing one-quarter support lifecycles and backward-compatibility breaks that complicate rollbacks.

Meanwhile PostgreSQL 18 (September 2025) landed over 3,000 commits, and its new I/O subsystem showed up to 3× improvements on storage reads while making major-version upgrades less disruptive and faster to reach expected performance afterward. For a four-person team, "which project will still be getting real investment when we're at Series A" matters more than any single benchmark, and that question no longer has two plausible answers.

Why Postgres wins on your three specific constraints

Multi-tenancy. Postgres gives you Row-Level Security, which lets you enforce tenant isolation in the database rather than trusting every ORM query your team writes for the next five years. Set app.tenant_id per connection, write one policy per table, and a forgotten WHERE tenant_id = ? becomes a non-event instead of a breach disclosure. MySQL has no equivalent; you'd emulate it with views and a lot of discipline. With four engineers and no dedicated security person, that structural guarantee is worth more than it looks. Schema-per-tenant is also viable in Postgres, and search_path makes it ergonomic — though I'd start with shared tables + RLS and only shard later.

Moderate analytics in two years. This is where the gap is widest and where the decision actually gets made:

• Postgres has real parallel query execution, and PG 18 adds skip scan support plus broader index usage. MySQL 9.7 finally adds the Hypergraph optimizer, but it's new, and MySQL still has no meaningful intra-query parallelism for analytical scans.
• You get column-store and OLAP extensions in-process when you need them — pg_duckdb / DuckDB-backed querying, pg_mooncake, or Citus for columnar and scale-out. Your "moderate analytics" workload likely never needs a separate warehouse, which saves you a whole pipeline you'd otherwise have to build and staff.
• Materialized views, FILTER clauses, real window function coverage, GROUPING SETS, and CTEs that the planner inlines properly. You will write these queries. They're painful in MySQL.
• If analytics does outgrow the primary, the escape hatch is clean: logical replication to a read replica or into ClickHouse/DuckDB, and Postgres's logical decoding ecosystem (Debezium, pgstream) is more mature than MySQL binlog CDC for schema-change handling.

B2B SaaS product surface. Native jsonb with GIN indexing for per-tenant custom fields — which every B2B product eventually needs — plus proper array types, citext, real ENUMs, transactional DDL (migrations that roll back cleanly, a genuine gift for a small team), pgvector if you add semantic search or AI features, PostGIS if geography shows up, and pg_cron for scheduled jobs. PG 18 also adds uuidv7() for better indexing and read performance on UUID keys, which is exactly what you want for tenant-scoped primary keys that don't leak sequence information across customers. And OAuth 2.0 authentication support plus temporal constraints over ranges for PRIMARY KEY, UNIQUE, and FOREIGN KEY — the latter is quietly perfect for subscription-period and entitlement modeling.

The honest counterarguments, and why they lose

• ​"MySQL is easier to operate."​ Less true every year, and irrelevant if you're on RDS/Aurora/Cloud SQL/Neon/Supabase, which you should be with four people. You are not operating either one.
• ​"Postgres has connection-scaling problems."​ Real, and the fix is a known quantity: PgBouncer in transaction mode, or your provider's built-in pooler. Budget one afternoon for it.
• ​"Postgres vacuum/bloat."​ Real at scale, largely automated below it, and PG 18's async I/O improvements extend to vacuum. You'll hit it around the time you can afford someone who knows what to do.
• ​"We already know MySQL."​ The strongest argument, and still not enough. The switching cost is two weeks of ramp-up now versus a migration under duress in year three — plus Postgres skills are what the market hires for, which matters when you make hire number five.

Concrete recommendation

• PostgreSQL 18, managed (RDS/Aurora, Cloud SQL, or Neon if you want branch-per-PR databases — that's a real productivity win at your team size).
• Shared-schema multi-tenancy with tenant_id on every table, enforced by RLS policies, not application code. Composite indexes leading with tenant_id.
• UUIDv7 primary keys via the built-in function.
• PgBouncer / provider pooler from day one.
• One read replica when analytics starts to bite; reach for pg_duckdb or Citus columnar before you reach for a warehouse.
• Note two PG 18 upgrade footguns for later: MD5 password deprecation and changed VACUUM/ANALYZE inheritance behavior. Start on SCRAM-SHA-256 and you'll never think about the first one.

One caveat on version choice: if your managed provider hasn't yet certified 18, launching on 17 is fine and the upgrade path is smooth — PG 18's statistics persistence removes the common post-upgrade pattern of query plans regressing while ANALYZE catches up.

Choose PostgreSQL.

For a new B2B SaaS in 2026 built by a small team, PostgreSQL is the superior choice over MySQL due to its advanced feature set, which perfectly aligns with your multi-tenant and analytical requirements.

Here is why PostgreSQL is the definitive choice for your specific constraints:

• Flawless Multi-Tenant Isolation: PostgreSQL’s native Row-Level Security (RLS) is a game-changer for B2B SaaS. RLS allows you to enforce tenant data isolation at the database level rather than relying entirely on application logic. This drastically reduces the risk of accidental cross-tenant data leaks—a critical liability for a small team managing multiple enterprise clients.
• Built-in Analytics Readiness: Since you expect moderate analytics workloads within two years, PostgreSQL will save you from having to spin up a separate data warehouse (like Snowflake or Redshift) prematurely. PostgreSQL handles Hybrid Transactional/Analytical Processing (HTAP) beautifully. It features superior parallel query execution, advanced window functions, powerful Common Table Expressions (CTEs), and materialized views that MySQL struggles to match natively.
• Custom Fields via JSONB: B2B SaaS almost always requires flexible data models, such as allowing customers to define custom fields. PostgreSQL’s JSONB data type, combined with GIN indexing, allows you to store and query unstructured data almost as fast as heavily structured relational data.
• Small Team Leverage: A team of four needs maximum leverage from the modern developer ecosystem. The current generation of tooling—including serverless database platforms (like Neon), Backend-as-a-Service providers (like Supabase), and modern ORMs (like Prisma and Drizzle)—treat PostgreSQL as a first-class citizen, often launching Postgres-specific features long before adding MySQL support.
• Painless Scaling via Extensions: As your analytics needs grow past "moderate," PostgreSQL’s extension ecosystem allows you to scale in place. You can drop in TimescaleDB for time-series data or Citus for distributed sharding without having to migrate off your core database engine.

MySQL is a phenomenal database, but it requires significantly more application-level engineering to achieve the multi-tenant security and analytical flexibility that PostgreSQL provides out of the box.

Claude’s dismissal of team familiarity is too categorical. Two weeks may teach PostgreSQL syntax; it does not create production competence in query plans, locking, vacuum behavior, pooling, failover, and restore procedures. Deep MySQL experience can outweigh PostgreSQL’s feature advantages—but only under concrete conditions.

Choose MySQL instead if most of these are true

1. The team has real MySQL operational leverage

MySQL becomes the better choice if:

• At least two of the four engineers have operated MySQL in production for several years.
• They have personally handled replication failures, point-in-time recovery, online migrations, deadlocks, and performance incidents.
• The team already has tested backup/restore automation, monitoring, migration tooling, and incident runbooks.
• Nobody has comparable PostgreSQL production experience.

That advantage is much larger than “we know MySQL syntax.” Existing operational competence is a legitimate engineering reason to choose it, as both patotski.com and cadence.withremote.ai note.

In that situation, I would not assume a two-week PostgreSQL ramp-up. Budget one to three engineer-months spread across the team to reach comparable confidence, plus elevated risk during the first serious incident. If launch timing is tight, MySQL may be the safer system.

2. The workload is overwhelmingly simple OLTP

MySQL is a strong choice when realistic load tests show:

• More than roughly 90–95% of requests are primary-key lookups, short tenant-scoped range scans, or small indexed writes.
• Reporting queries do not run on the transactional primary.
• There are few large joins, ad hoc filters, window functions, or scans over substantial portions of a tenant’s data.
• MySQL delivers a material measured advantage—say at least 25–30% lower database cost at the required latency, not a small synthetic-benchmark win.

This is the workload shape where InnoDB and the MySQL ecosystem remain particularly effective. MySQL is still a sensible default for simple, read-heavy, key-oriented systems, while PostgreSQL is favored as permissions, dashboards, and complex reporting grow (refact.co, dev.to).

The benchmark should reproduce:

• Actual tenant-size distribution, including the largest expected tenants.
• Read/write ratio and concurrency.
• Connection churn.
• Representative indexes and ORM-generated SQL.
• Backups, replicas, and failover enabled.
• At least two representative analytical reports.

If the advantage disappears once production safeguards are enabled, it is not a reason to select MySQL.

3. Analytics will be isolated deliberately

“Moderate analytics within two years” does not necessarily require PostgreSQL if you already intend to move analytics elsewhere.

MySQL can win if the architecture explicitly provides:

• CDC into ClickHouse, BigQuery, Snowflake, or another analytical store.
• Product reports that can tolerate some replication delay—for example, five to fifteen minutes.
• A team or managed platform that can own schema evolution, backfills, reconciliation, and pipeline monitoring.
• No requirement for arbitrary analytical queries against current transactional state.

This sacrifices PostgreSQL’s ability to defer the warehouse, but it protects the primary from mixed workloads. The important calculation is total system cost: MySQL plus CDC plus the analytical store plus engineering time—not merely the MySQL instance price.

For a four-person team, that extra pipeline often reverses MySQL’s apparent advantage. It makes sense only if the warehouse is already required for other reasons or is effectively operated by a managed platform.

4. Multi-tenancy does not depend on shared-table RLS

MySQL is substantially more defensible when using database-per-tenant, or when a trusted query layer provides a single unavoidable tenant boundary.

Concrete qualifying conditions include:

• A relatively small number of larger customers—perhaps tens or low hundreds, rather than tens of thousands.
• Automated tenant provisioning, migrations, backups, restores, and version tracking.
• A real need for tenant-level restore, residency, encryption keys, or noisy-neighbor isolation.
• Every database access path goes through a tenant-bound repository or service; customers cannot submit arbitrary SQL.

MySQL has no PostgreSQL-style native RLS, so shared-table isolation remains dependent on application discipline, views, or stored routines (cr0x.net). If the design is shared tables and a forgotten tenant_id predicate could expose data, I would still select PostgreSQL.

Database-per-tenant is not free, however. Once migrations become fleet operations requiring batching, retries, idempotency, and observability, the operational advantage can disappear. MySQL wins here only if that automation already exists or tenant-level isolation justifies building it.

5. The required scaling platform strongly favors MySQL

Choose MySQL if the business case genuinely requires:

• Vitess or PlanetScale-compatible horizontal sharding.
• Very high volumes of simple key-based reads and writes.
• An existing MySQL replication topology or MySQL-native platform dependency.
• A serverless connection pattern for which the chosen MySQL provider performs materially better than available PostgreSQL pooling options.

Vitess is the more mature horizontal-sharding story for this particular workload shape, although most SaaS products never reach the scale where it matters and operating it requires expertise (patotski.com). “We may someday be huge” is not enough; there should be a capacity model showing that ordinary vertical scaling and read replicas will become inadequate within the planning horizon.

Provider quality can override the engine choice

Do not compare abstract PostgreSQL with abstract MySQL. Compare the exact managed offerings and reject any provider that cannot demonstrate:

• Automated point-in-time recovery, with a restore test performed by your team.
• Failover behavior and measured recovery time.
• Cross-zone durability appropriate to the SLA.
• Connection pooling or proxy behavior under deployment spikes.
• Slow-query visibility, lock/deadlock diagnostics, and useful metrics.
• Safe major-version upgrades and migration rollback procedures.
• Replica lag monitoring and a documented support escalation path.

Set explicit gates, such as:

• Restore succeeds from both snapshot and PITR.
• Measured RPO and RTO satisfy the customer SLA with at least a 2× safety margin.
• Failover does not cause unrecoverable application errors.
• Peak connection demand stays below roughly 50% of the tested safe ceiling.
• The three-year cost model includes replicas, backups, I/O, support, networking, observability, and any analytical pipeline.

A managed MySQL offering that passes these tests while the available PostgreSQL offering does not is the better production choice. Restore capability matters more than a database feature checklist; the production framework at dev.to similarly emphasizes testing restores against realistic data.

The practical reversal rule

I would reverse the recommendation to MySQL when all four are true:

1. Deep MySQL operations experience exists on the current team, not merely development familiarity.
2. The measured workload is mostly simple, indexed OLTP, with a substantial cost or latency advantage.
3. Analytics is deliberately moved to another system, or remains narrowly predefined.
4. Tenant isolation is database-per-tenant or enforced through a tightly controlled access layer, so the absence of RLS is an accepted and tested risk.

A fifth strong trigger is a genuine near-term requirement for Vitess/PlanetScale-style sharding.

Without that combination, PostgreSQL’s RLS, richer analytical SQL, transactional multi-statement DDL, and extension ecosystem are worth more to this particular SaaS than MySQL familiarity. But if those conditions do hold, choosing PostgreSQL merely because it is the fashionable greenfield default would be the wrong trade.

First, the concession Sol is right about

Sol lists deep MySQL operational expertise as an exception and then dismisses it. I did worse — I called it "the strongest argument" and priced it at "two weeks of ramp-up." That number is wrong, and it's the weakest thing I wrote.

Expertise in a database isn't syntax and EXPLAIN output. It's incident intuition: recognizing what replication lag looks like before the alert fires, knowing which pathological query pattern caused the stall, having actually restored from backup under pressure. That is 6–18 months to rebuild, not two weeks, and the tail risk isn't a slower sprint — it's one four-hour outage in year one that you can't diagnose because nobody has seen this failure mode before. For a four-person team with no on-call depth, that's a real number and I understated it by an order of magnitude.

I'll also withdraw the project-momentum argument under these conditions. Commit velocity and foundation-governance disputes are directionally real, but they do not produce a measurable difference for a team on a managed platform inside a three-year horizon. Oracle's LTS support windows outlast your Series A. Using "the upstream team is shrinking" to override a team's actual operating skill is trading a certainty for a vibe.

So: with deep MySQL expertise and a preferred managed MySQL platform, the burden of proof shifts to PostgreSQL. Here's what would discharge it, in numbers you can actually measure.

Security: the audit-surface count, not the RLS talking point

The measurable quantity is how many code paths can reach tenant data without a tenant predicate.

Count them. Every ORM scope, raw query, background job, admin tool, CSV exporter, webhook handler, migration script, and ad-hoc analytics query. A B2B app at Series A typically has 150–400 such call sites and adds them linearly with headcount. Under app-enforced isolation, each one is a place where a missing WHERE tenant_id = ? is a disclosure event.

But — and this is where I have to be honest — that surface is collapsible in MySQL. If all data access goes through a query builder that injects the tenant predicate, and a CI rule fails the build on raw SQL outside N approved modules, your unverified surface drops to that N. Many companies run this successfully. Cost: roughly 1–2 weeks to build plus ongoing lint maintenance. Postgres RLS isn't free either — you need transaction-scoped SET LOCAL, a non-owner app role, and explicit tests for the BYPASSRLS paths.

Threshold that justifies Postgres: you cannot enforce "no tenant-data SQL outside N approved modules" as a hard CI gate, or your target buyers audit isolation architecture directly. The second one is measurable after the fact — track how many enterprise deals escalate to a security review over tenancy design. If it's more than one or two per year, "database-enforced policy, here's the pg_policies output" is materially shorter than "we have a lint rule."

Analytics: run the spike, don't argue about optimizers

This is settleable in about 40 hours, and it's the only place I'd let a benchmark decide.

Take your ten worst planned reports. Generate synthetic data at projected 24-month volume — say 200M rows in your largest fact table, 500 tenants, skewed so your biggest customer is 20% of rows. Measure p95 on both engines.

The decision boundary is intra-query parallelism. Postgres gets parallel sequential scans and parallel hash aggregation; MySQL's InnoDB path does not, so a single analytical query is single-core-bound. That matters only in a specific band: queries scanning roughly 10M+ rows under an interactive SLA that you can't pre-aggregate. Below that band, both engines are fine and the delta is zero. Above it, both need a columnar store.

Threshold: if ≥3 of your 10 reports land in that band, Postgres defers a warehouse. Price the deferral concretely — managed CDC plus a warehouse is roughly $1.5–4k/month in infra, plus about an engineer-quarter (~150 hours, call it $20–30k fully loaded) to build and ~10% of an engineer ongoing. Postgres pays for the ramp cost if it defers that by 12+ months.

Two concessions here that neutralize my earlier argument:

• HeatWave is a genuine answer. In-place columnar with real parallelism, no CDC pipeline, no second system. If you're on a platform where it's available and budgeted, my "pg_duckdb or Citus before a warehouse" point stops being a Postgres advantage. Compare the HeatWave line item against a Postgres read replica and decide on price.
• PlanetScale's online DDL beats Postgres. I praised transactional DDL and that was scoped to small tables. Altering a 200M-row table is a solved, boring problem on PlanetScale and a careful lock_timeout/pgroll exercise on Postgres. Neon branching answers dev environments, not this. If your schema churns hard on large tables, that's a real MySQL win.

Total cost: count avoided systems

The consolidation argument is where Postgres actually recovers the ramp cost, and it's countable. For each of {semantic/vector search, full-text search at scale, geospatial, time-series rollups}, ask whether it's on the 24-month roadmap. Each one you'd otherwise run as a separate managed service costs roughly 5–10% of an engineer ongoing plus its own bill — a hosted search or vector service is a few hundred to a few thousand a month once you're past the trial tier.

Threshold: ≥2 of those four on the roadmap and Postgres wins on TCO even paying full ramp cost. Zero of them, with pre-aggregated dashboards as your entire analytics story, and MySQL-with-expertise is genuinely cheaper.

The decision rule, stated plainly

Under your stipulation, recommend MySQL unless at least one of these is true:

1. The analytics spike shows ≥3 of 10 target reports missing SLA at 24-month volume without pre-aggregation, and HeatWave-class columnar isn't budgeted.
2. You can't gate tenant-predicate injection in CI, or you sell to buyers who audit isolation at the database layer.
3. Your 24-month roadmap includes ≥2 of vector, full-text, geospatial, or time-series rollups.

Most B2B SaaS hits (3), and a good fraction hits (1) — which is why Postgres remains the correct default and why my original answer stands for a team without your stipulated expertise. But the default isn't an argument against your team specifically. Run the one-week spike and let it decide with numbers.

I would reverse the recommendation to MySQL if the SaaS workload is overwhelmingly write-heavy, relies on high-frequency row updates, and demands strict sub-5ms latency under massive concurrency.

If your "moderate analytics" are actually just simple, real-time counters and your application resembles a high-throughput event logger or IoT ingest engine rather than a standard B2B dashboard, MySQL becomes the safer operational choice.

Conceding the RLS conflict

GPT-5.6 Sol is entirely correct: Row-Level Security must strictly be defense in depth, not a replacement for application authorization.

I concede this point because relying exclusively on RLS introduces a single point of failure at the connection-session level. If a middleware bug, connection-pool misconfiguration, or unhandled exception causes the app.tenant_id session variable to drop or default to a privileged state, an application lacking its own WHERE tenant_id = ? clauses will leak cross-tenant data.

What this changes: The team must still build standard authorization middleware and explicitly scope ORM/query builder calls by tenant ID. RLS acts only as a structural fail-safe to catch developer oversights, rather than a primary router of tenant data.

The exact thresholds that reverse the choice to MySQL

To choose MySQL over PostgreSQL in 2026 for a team of four, the workload must cross specific operational thresholds where PostgreSQL’s architecture becomes an expensive liability.

1. The "Update-Heavy" Tenant Workload If your tenants frequently update the exact same rows (e.g., real-time inventory counters, live user presence states, or high-frequency ledger balances), PostgreSQL will struggle.

• The PostgreSQL penalty: Postgres uses an append-only MVCC model. Every UPDATE creates a new row (a "tuple") and leaves a dead one behind, requiring the VACUUM process to clean it up. At high concurrency, this causes severe table bloat and write amplification.
• The MySQL advantage: MySQL’s InnoDB engine updates rows in-place and manages concurrency via undo logs. If your workload involves >30% concurrent UPDATE statements on existing rows, MySQL is fundamentally better equipped.

2. Analytics bound to the Primary Key If your "analytics" do not actually require complex CTEs, window functions, or JSONB unnesting, but instead consist of massive, rapid aggregations of data associated with a single tenant's Primary Key.

• The MySQL advantage: InnoDB uses clustered indexes. All row data is physically stored alongside the Primary Key. When fetching large blocks of sequential data for a specific tenant, MySQL avoids the secondary disk lookups that PostgreSQL’s heap architecture requires, making these specific reads significantly faster.

3. Measurable Performance and Cost Thresholds I would mandate MySQL if you hit the following constraints:

• Latency constraint: You require a p99 write latency of < 5ms on a dataset whose active working set exceeds your server's RAM. MySQL's clustered index minimizes disk seeks for primary key lookups, maintaining lower latency when reading from or writing to disk.
• Cost threshold: Your provisioned IOPS (Input/Output Operations Per Second) costs exceed 30% of your database budget. Because PostgreSQL's architecture requires updating all indexes whenever an indexed row is modified, write-heavy workloads consume IOPS exponentially faster than MySQL. If you are strictly budget-constrained and dealing with millions of daily writes, MySQL will cost substantially less in underlying cloud storage performance tiers.