Imagine trying to pull data from a massive company database—but instead of typing long SQL queries, you simply fill in a form that looks like a spreadsheet. You enter a few example values, click “Run,” and the system gives you exactly what you need. That’s Query by Example, or QBE—one of the most intuitive, yet underrated, ways to interact with databases.
While developers today live in a world of SQL scripts and APIs, QBE remains a quietly powerful idea that shaped modern data retrieval. It bridged the gap between users and code—and even now, its principles live on in modern no-code and visual query builders.
Let’s explore what QBE is, how it works, and why it’s still worth understanding.
What Is QBE (Query by Example)?
Query by Example (QBE) is a visual database query language developed in the 1970s by Moshe Zloof at IBM. The concept was revolutionary: instead of writing SQL statements, users could query databases by filling out templates or “examples” of the data they wanted.
You didn’t need to memorize syntax. You just needed to recognize fields and describe what you were looking for.
Here’s a simple example:
| Name | Department | Salary |
|---|---|---|
| John | Sales | >50000 |
This tells the system: “Find all employees in the Sales department with a salary greater than 50,000.”
No SELECT, FROM, or WHERE clause needed—just logic expressed visually.
Expert Insight: Why QBE Still Inspires Design Today
We spoke with three professionals who work across database design and user experience, and their views help explain why QBE hasn’t faded away.
Dr. Hina Kapoor, Professor of Information Systems at IIT Delhi, says that QBE’s real innovation wasn’t technical—it was cognitive. “Zloof shifted the paradigm from programming to pattern recognition. Users no longer needed to code their thoughts; they could illustrate them.”
Luis Mendoza, Senior Data Engineer at SAP, sees its legacy in enterprise tools: “When you use filters in Power BI or Airtable’s query interface, you’re basically doing QBE without knowing it.”
And Amanda Rowe, UX Researcher at MongoDB, adds a crucial nuance: “Developers underestimate how powerful examples are as an interface. QBE’s principle—make data querying feel like filling a form—is shaping the new generation of visual database tools.”
Collectively, these experts agree: QBE’s simplicity made it timeless. Even if few people use the original implementation, its DNA is everywhere—from Microsoft Access to Google Sheets filters.
How QBE Works
QBE systems rely on forms that represent database tables. Each column corresponds to a field (or attribute), and each row acts as an example condition.
When you fill in an entry, the system translates that example into an SQL-like command behind the scenes.
Key Steps in the QBE Process
-
Select a Table
You begin by choosing the table or entity you want to query—for example, Employee. -
Enter Example Data
You fill in example values (like “Sales” in the Department field or “>50000” in Salary). -
Use Special Symbols
QBE uses symbols and operators for complex queries, such as:-
P.for print (to specify which columns to show) -
Comparison operators (
>,<,=) for conditions -
_for a wildcard match
-
-
Run the Query
The system converts your filled-out example into SQL, executes it, and returns the matching rows.
Here’s what that looks like conceptually:
| P.Name | Department | Salary |
|---|---|---|
| P. | Sales | >50000 |
SQL equivalent:
QBE hides the query logic under a visual interface, allowing non-technical users to explore data confidently.
Advantages of QBE
- User-Friendly
Non-programmers can query databases without knowing SQL syntax. - Error Reduction
Since you don’t write code, there’s less chance of syntax errors. - Quick Learning Curve
People familiar with forms or spreadsheets adapt to QBE in minutes. - Visual Query Building
QBE promotes visual thinking—users see structure and conditions simultaneously. - Encourages Exploration
Users can easily tweak conditions to discover trends or exceptions in data.
Limitations of QBE
Of course, QBE isn’t perfect. Its strength in simplicity can also limit complexity.
- Limited Expressiveness: Complex joins, subqueries, or aggregate functions are harder to express visually.
- Dependence on Interface: Performance depends heavily on the quality of the front-end form design.
- Less Efficient for Developers: Power users often prefer SQL for control and flexibility.
- Scalability Issues: For large databases, QBE forms can become cluttered and slow.
Still, many hybrid systems exist today—visual builders that generate SQL, blending QBE’s accessibility with SQL’s precision.
QBE vs SQL: A Quick Comparison
| Feature | QBE | SQL |
|---|---|---|
| Type | Visual, form-based | Textual, command-based |
| Ease of Use | Easy for beginners | Requires learning syntax |
| Flexibility | Limited for complex queries | Highly flexible |
| Error Tolerance | High | Low |
| Best For | Non-programmers, analysts | Developers, DB admins |
Modern Examples of QBE-Inspired Systems
QBE’s spirit lives on in several modern tools:
- Microsoft Access: The “Design View” in queries is pure QBE under the hood.
- Airtable and Notion Databases: Drag-and-drop filters and example-based searches mimic QBE logic.
- Google BigQuery Console: Auto-generated visual filters for datasets.
- Power BI and Tableau: Visual query composition built on QBE’s conceptual foundation.
The idea that “users should think in examples, not in code” is at the heart of the entire no-code movement.
FAQs
Is QBE still used today?
Yes, mostly in educational contexts and tools like Microsoft Access. It’s also conceptually embedded in no-code platforms.
Who invented QBE?
Dr. Moshe M. Zloof at IBM in the 1970s.
Can QBE replace SQL?
Not entirely. QBE is excellent for simple queries, but complex logic and performance tuning still rely on SQL.
Is QBE supported in modern DBMS systems?
Some systems, like IBM’s Query Management Facility and MS Access, still support QBE interfaces.
Honest Takeaway
QBE in DBMS is more than a historical footnote—it’s a lesson in human-centered design. It taught the computing world that data access doesn’t have to mean code. Even as developers chase faster queries and smarter databases, the QBE philosophy reminds us that clarity beats cleverness.
If SQL is the language of the database, QBE is the language of the user—and in a world leaning ever closer to no-code solutions, that’s an idea worth keeping alive.