Both architecture styles apply layers to separate concerns, however they do that in a different way.
The n-tier architecture is about communicating with the database through layers of business logic and representation. It is tightly coupled to the externals (3rd party frameworks/drivers) you want to use, for example to an HTTP Server, an ORM or an SQL driver...
The clean architecture is about implementing use cases and build layers of adapters and externals (3rd party frameworks/drivers) around them. It is loosely coupled to the externals you want to use because of the layer of the adapters. Be aware that by the clean architecture the representation and the database layers would be both included by the externals. So the clean architecture is more about creating an application and separate it from the externals it uses to communicate with its environment. In this scenario it is much easier to test, develop and maintain the code of the application. You don't have to write integration tests or mock out the ORM to test the business logic. You don't have to concern about the externals by implementing the business logic, you can focus on the application itself. You don't have to modify the business logic to replace any external framework/driver, it's enough to write a new adapter to accomplish that.
So I think the clean architecture is a better choice.
After 5+ years:
As far as I can tell, the n-tier is about layering: presentation, application, business, data access below each other and each layer depends on the layer below it. You can do top to bottom or bottom to top development this way. I liked top to bottom. In the case of clean architecture and other related domain centric architectures everything depends on the domain. For example I define a repository interface in the domain and implement it in the data access and not the other way around that I do something in the data access and adjust the domain to be able to use it. My SQLs might be suboptimal this way, but it would be premature optimization if I would care about it and change the domain because of it. I can even write an in-memory repository for the domain tests and finish the SQL repository later, because it is not as important. Finding the right domain model is the hard part, many times you need a domain expert or become a quasi domain expert to know what classes describe your domain properly.