Let me start saying that I know a 'tax_query' is faster than 'meta_query'.

It's always recommended to use taxonomies over custom meta when filtering by custom data is required, but here I found myself in this situation.

I'm creating a Real Estate application where I have this obvious post type 'property'. Each property is supposed to have X number of rooms and bathrooms.

Then in my app you can filter properties by range... for example: Show all properties that have from 3 to 18 rooms.

The custom field way would be to add a custom field, eg: 'rooms' and then do my query like:

$args = array(
    'post_type'  => 'property',
    'meta_query' => array(
        'key'     => 'rooms',
        'value'   => array(3,18),
        'type'    => 'numeric',
        'compare' => 'BETWEEN',
$query = new WP_Query( $args );

The taxonomy way would be for example to create a custom taxonomy called 'property_rooms', then create the terms like '1', '2', '3', etc.. and do my query by term ID's like:

$args = array(
    'post_type'  => 'property',
    'tax_query' => array(
        'taxonomy' => 'property_rooms',
        'terms'      => array(3,4,5,6,7,8,9,10,11,12,13,14,15...etc) // Just pretend these are the corresponding term id's
$query = new WP_Query( $args );

And here's the question: Does tax_query beats meta_query even in situations like this?

It may be relevant to mention that we could be talking about thousands of properties.

Keep in mind sorting by these fields is neither a requirement nor a consideration to trade the speed of the query.


2 Answers 2


Does tax_query beats meta_query even in situations like this?


Taxonomies are appropriate if you have a common set of values that are shared by many posts, and you're doing a simple comparison based on whether the post has or does not have a particular value. They are not appropriate if you need to perform numerical or range comparisons, like your example, or if the values are going to be unique for every post.

Here's some examples of what should and should not be a taxonomy on a Real Estate site:

  • Property type eg. House/Apartment/Townhouse, should be a taxonomy.
  • Buy/Rent should be a taxonomy.
  • Features eg. Pets allowed/Air conditioning/Dishwasher, should be a taxonomy.
  • No. of bedrooms, should be meta.
  • No. of parking spaces, should be meta.
  • Address, should be meta.

On top of being faster to query, having taxonomies for those properties makes managing them easier in the back-end, and makes generating a list for filtering considerably easier and faster.

However, keep in mind that even if meta is the only viable option for filtering a value, using too many meta queries will really hurt the performance of the query. This is because you are querying based on the value of the meta, rather than an ID, and the value column is not indexed. However, just because it's not indexed doesn't mean it would be appropriate to index it yourself. This is because the meta_value column of wp_postmeta holds vastly different kinds and amounts of data for different things.

If you have a large number of numerical fields that you need to use for filtering, neither post meta nor taxonomies might be appropriate. You might be better off creating a custom table with your own indexes and more appropriate column types. You could then store those values in your custom table, and use the posts_clauses, or posts_join, and posts_where filters to add your own SQL to WP_Query to use your table for more efficient filtering.

  • My setup of taxonomies and metas is exactly what you wrote. Guess you already worked on a Real Estate site. But let me clarify that I have set a predefined amount of terms as quantity for rooms and bathrooms (30 exactly for each). Now tell me... knowing theres a limited set of options which means is not really unique for every post and looking at my example, lets say I have 5k properties, which method would be faster with my exact example as a reference? Commented Aug 7, 2019 at 8:39
  • I don't actually know for certain, all I can suggest is testing it. The problem with your method of using taxonomies is that you need to figure out the term IDs to use based on the query. For example, if the users search for properties with between 3 & 7 rooms, you need to figure out the term IDs to use for that query. That would add overhead. The alternative would be to query based on term slugs, but that's going to be slower than querying by term ID because I believe it requires another join. It also prevents you from sorting by that field. Commented Aug 7, 2019 at 8:48
  • I've done some autocaching to compensate for this. All predefined terms ids for rooms and bathrooms are already stored in the wp options. I just do a get_option and filter the desired ID's. I'm loving the conversation because I'm noticing I saw the flaws in advance. The order commenter mentioned the same about loosing the option to sort by those fileds, but as I told him this is not a requirement in the near future an obviously not a consideration to trade speed off. Commented Aug 7, 2019 at 8:54

Well, I wouldn't say that "tax_query beats meta_query"... They're a little bit different things.

When you perform tax_query, then two JOINS are needed in your SQL query. Meta_query results in only one join (if you search for only one meta).

So when is the tax_query better? For example when you search for posts assigned to multiple taxonomies.

Let's say you want to find properties that have 2 floors, 4 bedrooms, separate kitchen, and a garage. So you're doing a search with multiple conditions based on multiple properties.

In such case:

  • tax_query will result in an SQL query with just 2 JOINS and multiple conditions in WHERE part.
  • meta_query will result in an SQL query with 1 JOIN for every property in your search.

And even worse - tax_query uses proper IDs and keys and in meta_query you'll have to use strings as keys. So yeah - in such case tax_query has to be faster.

But... Tax_queries are really bad choice if:

  • you need to order by its value (i.e. order properties by their price),
  • you search for all values within given range (i.e. search for properties within given price range),
  • you have a lot of different values for given property (i.e. price since there will be almost the same number of different prices as properties).

So no - tax_query does not beat meta_query every time. They're different things and you should use them according to your needs.

  • To be honest, taxonomy wasnt even an option for the price part in my case. I'm already using custom fields for that. But according to my example am I on the right track still using taxonomies for things like "rooms" (limited to 30), "bathrooms" (limited to 30), "type" (eg: apartment, house, business), condition (eg: "new", "used", "under construction")? Commented Aug 7, 2019 at 8:30
  • I would go for custom fields for rooms/bathrooms, I guess. Commented Aug 7, 2019 at 8:33
  • Even knowing their uniqueness have been limited to 30 options? Commented Aug 7, 2019 at 8:43
  • 1
    Yes, because ordering by the number of rooms sounds like a pretty probable scenario. So does searching by the range (and even worse - searching "properties with more rooms than X"). All of these will be hard with taxonomies. Commented Aug 7, 2019 at 8:44
  • searching properties with more or less rooms than X is practically what im doing hehe. I dont see the problem in that part. If its min=2&max=7 i just use 2,3,4,5,6,7 id's. Ordering for sure will be a problem. But I'm pretty sure that ordering by custom filters is not an option I see coming for a looong time... probably by then the project is making enough cash to pay for itself a real team of devs and a better backend architecture than WP. Commented Aug 7, 2019 at 8:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.