At what point will a developer feel they should have used Drupal after choosing Grav, or the opposite? This isn't about native architecture or multisite functionality or about how the engines operate. Grav is a powerful flat-file CMS that many developers prefer precisely because it avoids the complexity of database-driven systems. But certain project requirements push beyond what Grav was designed for. This is about recognizing those thresholds and also knowing when Drupal's power becomes unnecessary overhead for what Grav handles effortlessly.
When You'll Wish You'd Chosen Drupal
Real-world pain points where a developer will say "I should have used Drupal":
1. User-Generated Content with Complex Permissions
When you need users to register, create profiles, submit content, and have granular permission controls, Grav's user registration capabilities are limited. User registration is disabled by default in Grav and requires manual plugin configuration. You'll hit the wall when trying to build:
- Community sites where users create and manage their own content
- Membership sites with multiple user tiers and different access levels
- Sites where different user roles can edit different types of content
2. E-commerce Beyond Simple Products
There's minimal e-commerce support in Grav, with developers struggling to find solutions for e-commerce sites. The main shopping cart plugin is explicitly marked as "NOT SUPPORTED, NOT MAINTAINED". You need Drupal when building:
- Full-featured online stores with inventory management
- Complex product relationships and variations
- Integrated payment processing workflows
- Order management systems
3. Editorial Workflows and Content Approval
Developers explicitly ask about 4-eyes workflow for review and approval processes in Grav, indicating this is a missing feature. Grav has basic publish/unpublish but lacks:
- Multi-step approval chains (draft → editor review → approval → publish)
- Content moderation with multiple reviewers
- Revision tracking with approval history
- Role-based publishing workflows for large teams
4. Advanced Search and Filtering
While Grav has basic search plugins, users struggle to build dynamic search pages with multiple taxonomy filters like area, size, and features. You'll need Drupal for:
- Faceted search (filter by multiple attributes simultaneously)
- Real-time filtering without page refreshes
- Complex search across multiple content types with relationships
- Search result aggregation from different sources
5. Complex Content Relationships
Drupal Views can handle multi-tiered content relationships across three or more content types using relationships and entity references. Grav's taxonomy system is simpler and you'll struggle with:
- Content that references other content in complex hierarchies
- Displaying related content from multiple levels of relationships
- Building dynamic listings based on content relationships
- Queries that need to join multiple content types together
6. Large-Scale Content Management
When managing thousands of pieces of content with hundreds of contributors, Grav's flat-file system becomes problematic. You need Drupal for:
- Sites with 10,000+ pages where file system limits become an issue
- Multiple content editors working simultaneously (Grav's Git sync helps but isn't enough)
- Content that needs complex querying and aggregation
- High-traffic sites requiring database-level caching
7. Dynamic Forms and Data Collection
Grav's form plugin handles basic contact forms, but you'll struggle with:
- Multi-step forms with conditional logic
- Forms that create user accounts with specific roles
- Form submissions that need to interact with external APIs
- Complex form validation across multiple fields
- Forms that populate content or user profiles
When You'll Wish You'd Chosen Grav CMS
Real-world pain points where a developer will say "I should have used Grav CMS instead of Drupal":
1. Content-Focused Sites Without Complex User Interactions
When your site is primarily about publishing content such as marketing sites, documentation, portfolios, blogs, company sites. If visitors aren't logging in, creating accounts, submitting content, or interacting with complex permissions, you don't need Drupal's user system.
Grav makes content-oriented websites easier and simpler, especially for frontend developers. Grav handles basic login protection for admin areas, and that's often enough. You'll regret Drupal when you realize you spent weeks configuring what Grav does out of the box.
2. Speed to Launch Matters
Grav boasts a simple setup process. You can get started quickly without complex configurations. In contrast, Drupal development typically requires a good grasp of technical skills, and newcomers often find Drupal's interface less intuitive. If you need a site live in days rather than weeks, Grav wins.
3. Small Teams or Solo Developers
Making the climb from "why" to "how" in Drupal is not easy and does not happen overnight, or even over weeks. Drupal is frequently very frustrating because while it makes the very hard possible, it also makes the very easy hard. For a solo developer or small team without dedicated Drupal expertise, the learning curve alone can sink a project timeline.
4. Developer-Friendly Workflows with Git
You can exploit Git for your content workflow using the Git Sync plugin, so that your content editors can deploy changes via the Administration console. To deploy Grav you essentially just need to move the user-folder to another server. The flat-file architecture means your entire site can live in version control naturally, with no database dumps or migration scripts.
5. Low Server Requirements and Hosting Flexibility
A more complex Drupal installation can easily exhaust 256 MB of RAM with only one or two visitors. Meanwhile, Grav doesn't rely on a database, stores content in files and folders, and requires less server resources. You can host Grav on basic shared hosting that would choke on Drupal.
6. Frontend Developer Control
By rendering pages with Twig Templates, you have complete control over how your site looks, with virtually no limitations. Taxonomies are MUCH simpler in Grav than in Drupal. Just add them to your config file and reference them in YAML frontmatter. Frontend developers can build themes without learning "the Drupal way."
7. Documentation and Knowledge Sites
Grav intelligently caches content to deliver great performance and lets you define custom fields for any of your pages, including modular content. For technical documentation, course materials, or knowledge bases where content structure is straightforward, Grav's Markdown-based workflow is far more natural than Drupal's entity system.
8. Budget-Constrained Projects
Building and maintaining a Drupal site can be more time-consuming than using simpler CMS platforms. Customization often requires significant time and effort due to its complexity. Drupal developers often command higher salaries compared to developers skilled in more straightforward CMSs. When budget is tight, Drupal's overhead becomes a liability.
9. Rapid Prototyping and Iteration
What if there was a platform that was fast, easy-to-learn, and still powerful and flexible? A flat-file based CMS is the answer. When you're iterating on design and content structure, Grav's file-based approach lets you make changes directly in your editor without navigating admin interfaces or clearing caches.
The Bottom Line
Grav is excellent for marketing sites, documentation, portfolios, and content-focused business sites. But the moment you need user-generated content, e-commerce, editorial workflows, or complex data relationships, you'll be fighting the system and that's when Drupal earns its complexity.
Conversely, when your project doesn't require those features, Drupal's overhead delivers no return. Choose the tool that matches your actual requirements, not your hypothetical future ones.
What If You're Unsure?
When the decision isn't clear-cut, here's a practical approach:
Start with Grav if your requirements are ambiguous. Migrating from Grav to Drupal later is far easier than the reverse. Grav's Markdown content files are portable and human-readable and you can move that content into virtually any system. Drupal's database-driven content, complex entity relationships, and module dependencies make outbound migration significantly more painful.
Ask these five questions:
1. Will visitors create accounts and submit content? If yes, lean Drupal. If only admins touch content, Grav handles it fine.
2. Do you need more than basic "buy now" buttons? If you're building a catalog with inventory, variations, and order management, you need Drupal (or a dedicated e-commerce platform). If you just need to link to Stripe or embed Snipcart for a handful of products, Grav works.
3. How many people will edit content simultaneously? One or two editors working asynchronously? Grav's Git-based workflow is fine. A team of ten editors with approval chains? Drupal.
4. Will content reference other content in complex ways? If you're thinking "I need to show all articles by authors who have also written about Topic X in Category Y," that's Drupal territory. If your relationships are simple (posts have tags, pages have categories), Grav handles it.
5. What's your realistic timeline? If you need something live in a week and you don't already know Drupal, don't learn it under deadline pressure. Ship with Grav now; migrate later if you outgrow it.
The Honest Truth
Most projects that end up on Drupal didn't need to be there. Developers often choose Drupal for what the site might become rather than what it is. If you're building for hypothetical future requirements, you'll pay the complexity tax today for features you may never use.
Start lean, and let actual pain points (not anticipated ones) drive your platform decisions.
Beyond Grav and Drupal: Similar Technologies
The Grav vs. Drupal decision reflects a broader choice between two fundamentally different CMS philosophies. Understanding these categories helps you evaluate alternatives without needing a dedicated comparison for every combination.
Flat-File CMS Options (Like Grav)
These systems store content in files rather than databases. They prioritize speed, simplicity, and developer-friendly workflows.
- Grav – PHP-based, Markdown content, Twig templating, strong plugin ecosystem
- Kirby – PHP-based, file-driven, elegant paid license model
- Statamic – Laravel-based, flat-file by default, polished control panel
- Hugo – Go-based static site generator, extremely fast builds
- Eleventy (11ty) – JavaScript-based static site generator, highly flexible
- Jekyll – Ruby-based, tight GitHub Pages integration
- Publii – Desktop-based static CMS with GUI
When to explore these: You want speed, Git-based workflows, simple hosting, and your content editors are comfortable with Markdown or a lightweight admin panel.
Database-Driven CMS Options (Like Drupal)
These systems use relational databases to store content. They handle complex data relationships, user management, and enterprise-scale requirements.
- Drupal – PHP-based, highly extensible, enterprise-grade
- WordPress – PHP-based, most popular CMS globally
- Joomla – PHP-based, sits between WordPress and Drupal in complexity
- TYPO3 – PHP-based, popular in Europe, enterprise and multilingual
- Craft CMS – PHP-based (Yii framework), developer-friendly content modeling
- Concrete CMS – PHP-based, in-context editing, beginner-friendly
- Backdrop CMS – Drupal 7 fork, preserving simplicity
When to explore these: You need user accounts, complex permissions, editorial workflows, content relationships, e-commerce, or integration with enterprise systems.
Headless CMS Options (A Third Path)
These systems manage content through an API, decoupling the backend from the frontend.
- Strapi – Open-source, Node.js-based, self-hosted
- Directus – Open-source, wraps any SQL database with an API
- Sanity – Hosted, real-time collaboration, highly customizable
- Contentful – Hosted, enterprise-focused, mature API
- Payload CMS – Open-source, TypeScript-based, code-first
- Ghost – Focused on publishing and newsletters
When to explore these: You're building with React/Vue/Next.js, need content delivered to multiple platforms, or want to separate content management from presentation entirely.
Quick Reference Tables
If Your Project Needs... → Choose Drupal
| Requirement | Why Drupal? |
|---|---|
| User-generated content with permissions | Built-in user registration, roles, and granular permissions |
| E-commerce with inventory management | Drupal Commerce provides full-featured online store capabilities |
| Editorial workflows and approval chains | Content moderation with multi-step review and publishing workflows |
| Advanced search and faceted filtering | Views and Search API handle complex queries and filtering |
| Complex content relationships | Entity references and relationships across multiple content types |
| Large-scale content (10,000+ pages) | Database-driven architecture scales efficiently |
| Dynamic forms with conditional logic | Webform module supports complex multi-step forms |
If Your Project Needs... → Choose Grav
| Requirement | Why Grav? |
|---|---|
| Content-focused marketing or documentation site | Fast, simple, no database overhead |
| Quick launch (days, not weeks) | Minimal setup, no complex configuration |
| Small team or solo developer | Gentle learning curve, no "Drupal way" to learn |
| Git-based content workflow | Flat-file architecture lives naturally in version control |
| Low server requirements | Runs on basic shared hosting |
| Frontend developer control | Twig templates, simple taxonomy, direct file editing |
| Budget constraints | Lower development and hosting costs |
| Rapid prototyping | Direct file editing without admin interfaces |
How to Choose
Pick the category first, then the tool. If flat-file fits your requirements, compare within that group. If you need database-driven capabilities, compare those options. Crossing categories means you've likely misdiagnosed your requirements.
Need Help Choosing?
I work with government agencies and organizations evaluating CMS and technology platform decisions. If you're weighing options for your project and need an objective perspective, let's talk.
This comparison draws from real developer experiences and pain points documented in community forums, StackOverflow discussions, and project post-mortems. Choose based on your actual requirements, not your aspirations.