[danpalmer]

To clarify the advice, at least how I believe it should be done…

Use One Big Database Server…

… and on it, use one software database per application.

For example, one Postgres server can host many databases that are mostly* independent from each other. Each application or service should have its own database and be unaware of the others, communicating with them via the services if necessary. This makes splitting up into multiple database servers fairly straightforward if needed later. In reality most businesses will have a long tail of tiny databases that can all be on the same server, with only bigger databases needing dedicated resources.

*you can have interdependencies when you’re using deep features sometimes, but in an application-first development model I’d advise against this.

[giardini]

">Use One Big Database Server…

… and on it, use one software database per application.<"

FWIW that is how it is usually is done(and has been done for decades) on mainframes (IBM & UNISYS).

-----------------------

"Plus ça change, plus c'est la même chose."

English: "the more things change, the more they stay the same."

- old French expression.

[goodoldneon]

OP mentioned joining, so they were definitely talking about a single database

[riquito]

Not suggesting it, but for the sake of knowledge you can join tables living in different databases, as long as they are on the same server (e.g. mysql, postgresql, SQL server supports it - doesn't necessarily come for free)

[yellowapple]

In PostgreSQL's case, it doesn't even need to be the same server: https://www.postgresql.org/docs/current/postgres-fdw.html

[danpalmer]

You can still do a ton of joining.

I’d start with a monolith, that’s a single app, single database, single point of ownership of the data model, and a ton of joins.

Then as services are added after the monolith they can still use the main database for ease of infra development, simpler backups and replication, etc. but those wouldn’t be able to be joined because they’re cross-service.