postgresql vs mysql in ease of scaling, and usefulness for highly relational (tons of foreign keys) databases

OK, I've read quite a few things about PostgresSQL and it seems to have a few features which seem pretty awesome, I really like the idea of being able to update a table and adding a column/index without having to wait for the database and have it being locked. Also it seems to be about as fast as MySQL, when it comes to the performance. But I'm mostly worried about the ease of scaling it up with as relational as my system is.

Right now I have tables which all have foreign keys and relate to eachother for ease of use, and I use foreign keys a lot. For an example of this, I've got a "players" table which then has many tables which relate out of it. I have the following tables that branch out of it.

1. players_mail
2. players_mail_attachments
3. players_bank
4. players_inventory
5. players_effects
6. players_effects_temp
7. players_quests
8. players_quests_tasks
9. ...

and the list continues on. I have a few other tables and they all use the players table's id as one of their indexes and relate back to the players.id column. Also the mail one has a foreign key to the mail, and others are also as relational. Does PostgreSQL scale well with that relational of a database? I also have a few indexes on most of the tables. All tables that aren't "root" tables(like the players one) have two indexes the primary key and then also the indexes for the foreign keys.

I've already read that postgres doesn't automatically create indexes on foreign keys, so I know that I'll likely have to manually create those indexes. With what I've said how well does Postgres handle that kind of dataset? I'm sure that someone else out there has already created a highly relational database in a RDBMS before me, and I'd love to hear their experience.

Edit to add:

I primarily am looking at it because how it handles locking during writes, and also because I don'开发者_高级运维t know how I feel about oracle, and being reliant on xtradb as a database format. Even though I know that MariaDB is working on it's own database format, I still don't like my favorite database format being under the control of a company who might just kill it, or worse make it completely closed source. After I go through postgresql and look at how I can easily move my databases to it and look over the tools for it, I'll pick which answer was best, I'll also leave it open for 24hrs so that people can amend anything that they wish.

edit 2:

I've just finally really started looking at the database format itself, and whilst I really like some of the things I cannot stand Object Orientation, it drives me insane. I was fully ready to go to postgres until I realized that it's modeled after half of object orientation, I guess one of my last bits of questions for this is, it doesn't force me to use classes and objects correct? Wikipedia says that it's a "bridge" between the OOP and RDMBs, thus I take it as I can still do everything the way that I like to think of it. If that is how it works, then I'll likely love the database, if I cannot then I'll hate it. And I'd rather not hate a tool that is so crucial to the success of this thing.

300 tables with lots of foreign keys and indexes, about 150 tables having more than 1000 records, about 20 tables having more than 100000 records is big enough for you?

Never faced performance issues caused by the PostgreSQl itself. Monstrous 400+ lines queries with about 15 subselectes runs within a second.

To sum up: PostgreSQL scales very well. No match for Oracle of course, but it gets the job done. The only hint: if you are VERY concerned about performance - replace triggers with rules and use views instead of stored procedures if possible

If you're really worried about scaling out, then eventually you should stop relying on foreign keys within the database and handle it at the application level.

As far as scaling MySQL vs Postgres, you're mostly going to run into the same hurdles since they're both really fast and stable RDBMS.

All that said, Postgres is much more ACID compliant than MySQL, it handles FKs just as you're needing and I would generally recommend it based on what you've expressed in your post.

It does not matter what you use. Everything depends on the application and architecture. For example, foreign keys does not hurt much if you make a little redundancy. example:

players(id, ....)
players_quests(id, player_id, ....)
players_quests_tasks(id,player_quest_id, ...)

To find players_quests_tasks belongs to some player you need joins. Solution: add player_id to players_quests_tasks table. It's break normalization but there is no join:

players_quests_tasks(id,player_quest_id, player_id,...)
SELECT * FROM players_quests_tasks WHERE player_id=:player_id_to_find;

It's make sense if you have much more reads than writes.