Hello Scott,
Thanks for your reply. It's quite optimistic for me :)
Let me answer & ask more questions on some parts of your reply.
The general consensus within the WordPress ecosystem is that custom tables are bad and should be avoided primarily because they operate outside of the normal architecture of WordPress itself.
Yes that's what I meant in "being outside of WordPress territory".
Something like Pods offers a fusion of both, which lets you have custom post types / custom taxonomies, but powered by a separate table for their custom fields. It also integrates with the *_*_meta functions in WordPress, which WP core and other plugins utilize to interact with the fields, so the location being in a table is almost inconsequential.
In other words, using Pods will let me have native Custom Post Type functionality AND custom tables. http://wordpress.stackexchange.com/questions/62862/how-to-use-custom-post-type-apis-but-use-a-different-db-table?rq=1 - This is about one-year-old thread about same topic and author of reply says that it's not possible I think she/he wasn't aware of Pods at that time or maybe she/he was talking about some other kinds of problems?
For searching, I'm not sure the performance is entirely noticeable if you're on an optimized server / site utilizing object caching etc. Pods caches just like WordPress for it's data across the entire codebase, so that's something we've thought about deeply.
I have chosen WPEngine as my managed WordPress hosting so I think optimizing server won't be a problem for me.
As with Pods, let me tell you that I have discovered this framework today despite that I am planning website project for almost 2 months already and it seems that it's must-use plugin for my project, isn't it?
I recommend keeping to the standard Custom Post Types and meta-based field storage in most cases, but something you'll find is quite bad when filtering is that when you run a query in WordPress for 10 fields, that's 10 extra database SQL joins just for the meta alone, and that can really slow things down when you have a lot of data.
As meta-based field storage causes slowing things down and the solution is custom database tables, does Pods solve this? I mean what you have said above that you can have Custom Post Types as well as custom database tables and the only downside is WP_Query which you are working on. One more thing, I am not developer myself, could you tell me what that means in my scenario? I mean what will WP_Query problems will cause. Is it mostly search-related, or what?
And the last question here I am going to run WordPress multisite as I have already said above and actually, there will be two search locations:
1. On specific site - where end-user will be able to search custom post types only from that specific site;
2. On homepage - which will index everything across the network;
So, in first case, we are talking about defined quantity of posts. For example, maximum quantity of custom post types our site will have is hardly about 40 000. And we will have only few of these kind of huge sites. Others will have hundreds or few thousands.
In second case, we will have to index hundreds of thousands of products just like wordpress.com search does.
So, as quantity of items are slowing things down, it will impact only second case right? I mean, sites, itself won't have huge quantity of posts (if what you mean in HUGE isn't few thousands). I think it's good that WordPress Multisite creates dedicated table for each site, this will help specific sites avoid this slowing down right as search bar on specific site already knows in which table it should search for typed product, so instead of searching in hundreds of thousands products (like it would on single installation of WordPress) it will search in thousands.