Drupal Views — what it is and when it falls short
Views is at the heart of Drupal — almost every listing, search result and archive is powered by Views. Here is what it is and where it falls short.
What Drupal Views is
Views is a Drupal core module that lets you query the database through a visual interface — without writing SQL. You choose which content types to show, which fields to include, which filters to apply, how to sort, and whether to paginate.
Practically every "listing" in Drupal is a View:
- News listing on the homepage
- Blog post archive
- User list in the admin interface
- Search results
- Related articles at the end of a post
Views is one of Drupal's biggest strengths — it dramatically reduces the amount of code that needs to be written.
What Views does well
Simple filtering — show only published content of a certain type, within a date range, with a specific tag.
Sorting — by date, title, or manual drag-and-drop order.
Multiple formats — table, list, grid, slideshow, calendar, map (with add-on modules).
Exposed filters — filters can be made public so users filter themselves (e.g. in a product catalogue).
Relationships — display fields from referenced entities (e.g. the author's photo on an article).
When Views falls short
Complex business logic
Views builds SQL queries but does not run PHP logic for each result. If you need "show products where the price after discount is under €50" and the discount is a computed field — Views cannot handle this.
External data sources
Views works with the Drupal database. If you need to display data from an external API, ERP, or another database, you need custom code or a Views plugin.
Very large datasets
Views generates SQL automatically. On complex queries against large databases this can be slow. With 100,000+ records you often need hand-optimised queries.
Real-time content
Views queries the database, which may be cached. If you need a live-updating view (live stock prices, chat, ticket availability), Views is not the right tool.
Deeply nested relationships
Views handles one-level relationships well, two or three levels adequately. Deeper than that and the query becomes complex and slow.
Alternatives
Custom module — when the logic is complex, a custom page with a custom query is cleaner.
Search API + Solr/Elasticsearch — for large datasets and full-text search (see the Search API article).
GraphQL / REST + frontend — when data goes to a frontend that has its own rendering logic.
Summary
Views is the first thing to try for any content listing. It covers 80% of cases perfectly. The remaining 20% — complex logic, external data, large volumes — require custom development.
If you've hit Views' limits, get in touch — we'll work out the best solution.
Kaido Toomingas
WebPro Company OÜ
Need Drupal help?
If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.