My understanding is that the processing of queries is not done on Metabase side. Metabase sends the queries to the server, the query runs there, and the results are being sent back to Metabase to be shown or visualized.
If the above is true, then why composite key support is an issue?
And more generally, what’s the point of having “entity keys” in Metabase data model, if the processing of queries is done on the server side?
Hi @King_Edward
As far as I know, there is sometimes processing done by Metabase. Example if you use “Cumulative sum of …”
Not sure, but I think “Entity Key” is being used as part of drill-through.
Let’s try to ping @camsaul and see if he can enlighten everybody 
@King_Edward, you're right that queries do run on the database, and not in Metabase itself. But we still have to generate the queries in Metabase and make sure the results come back with the right information that is needed to power features like drill-thru.
I just added a response to the GitHub issue you linked:
Ok, since people have been asking, to clarify, what we mean by saying we don't support composite keys is that you can't use them for features like Drill Thru and filtering by a column in a related table via composite foreign key and the like in the visual Query Builder. You can still run queries against these tables. You can still write any queries you want using SQL. This is only an issue with us not having a way to mode composite key relationships in the metadata used by the Query Builder. It's something we will definitely address in the future.
Hopefully that clarifies things. Let me know if you have any more questions.