Welcome back, and hell yeah welcome to PHP!

Yeah, this is really not a good idea unless you have a very specific technical reason for it. Pieter Levels does it for his projects, but I'd focus on taking product/business advice from him instead of technical advice most of the time.

One of SQLite's limitations is only having one write connection to a database at a time. So splitting into multiple different DBs allows you to have multiple write connections. However, for most projects, it's unlikely you'll hit a traffic scale where you would need to do this.

What I would recommend doing this for is when you have app functionality that can be DB-heavy and you don't want to affect your users, like a DB-drive cache or queue system.

If you aren't using a framework yet, I can highly stress that you try one out. And especially if that one is Laravel! If you think base PHP is fast to work with, once you get the hang of the ecosystem, you can go to super speed with Laravel.

If you'd like an example of this multi-SQlite DB pattern, I use it in my #toyboxforlaravel project.

Honestly, save yourself the headache and use a proper database with nice joins and stuff. Save time on managing weird stack choices and stick to the standard, especially when there's no good reason for it or if you're just getting started.

Is totally fine if you use SQLite.

Have a look at Mongo as well, it is a really good database and surprisingly easy to run yourself. I actually recently switched all my databases from SQLite to Mongo.

You sound like you might just be getting started so I'd suggest you stick to very well known patterns and not try to overcomplicate the DB design.

In other words: you should just have 1 SQL DB, multiple tables. Design the tables and columns appropriately using the right data types, and ask ChatGPT for help if you're not sure which data type to use.

Avoid:
- Multiple DBs, NoSQL, and any kind of premature optimization. Worry about 1 million users/visits problems when you get to that level, and even at that level modern RDBMS software can handle that kind of load on a single DB server.
- MongoDB and non-relational DBs. Mongo tends to lie about what their databases can handle despite fancy "transactions" marketing on their site

If you don't believe me, note the no less than 5 separate studies (!) into how Mongo loses writes and experiences other problems you really don't want to have to think about: jepsen.io/analyses

To be fair, these studies are slightly old and it's very possible they've been addressed by now, but Mongo has been guilty many times of misleading marketing practices. I wouldn't place my trust in this kind of entity.

Instead, use and learn:
- Very well known and tested databases where experts have verified their behavior properly so that you don't have to worry about unexpected surprises in production. PostgreSQL and MySQL are both good choices for this reason.
- SQLite is also OK to stick with, but you might have to think about extra things like restoring the DB from a backup if the server dies. I'd advise just using any "database as a service" provider like Amazon RDS and picking Postgres/MySQL as I mentioned - Amazon has a free tier, handle automated backups and persisting data for you so that you don't have to worry about it.