How Azquo Thinks
The architecture behind the flexibility
Names, Not Tables
Most databases store data in tables — fixed grids of rows and columns where every record must conform to a predetermined structure. Azquo does something fundamentally different. It stores data as names organised into hierarchies.
A name is any concept your business uses: a product, a customer, a week, a cost centre, a sales channel, a scenario. Names are not confined to a single table or dimension. A name can belong to any number of hierarchies simultaneously — “May“ can be a month in the date hierarchy and a member of “Bank Holidays“ at the same time. A product can sit under its category, its supplier, its warehouse location, and any ad-hoc grouping you create later.
This is closer to how people actually think about data than the rigid table structures that conventional databases impose.
Values Anchored to Names, Not Cells
In a spreadsheet, a number lives in a cell. Move the cell, lose the number. In a relational database, a number lives in a row. Change the table structure, and you need migration scripts.
In Azquo, a numeric value is anchored to a set of names — its peers. A revenue figure of £12,000 might be attached to the names “Week 12“, “Email“, “Actual“, “2024/25“, and “Gross Sales“. That single value is then automatically queryable by any combination of those names, at any level of aggregation, without pre-built cubes or summarisation steps.
Because the value is linked to names rather than to a position in a grid, new ways of slicing the data can be introduced at any time — without touching the data itself.
Structure That Evolves Without Disruption
In conventional systems, changing how data is organised — adding a new reporting dimension, regrouping products, introducing a regional breakdown — typically requires schema changes, ETL modifications, and IT involvement.
In Azquo, you upload a simple spreadsheet that defines the new grouping, and it becomes immediately available in every report. The existing data does not move. The existing reports do not break. The new hierarchy simply provides an additional lens through which the same data can be viewed.
This is possible because names have no dimensional constraints. Adding a name to a new hierarchy is like adding a word to a new sentence — it does not change the word‘s meaning in any other sentence.
In-Memory, with Direct Links
Azquo holds its entire database in memory, with direct links between names and values. There is no query compilation step, no index lookup, no join operation. When a report asks for data, Azquo navigates directly from the names in the report headings to the values attached to them.
This is what makes Azquo fast enough to sit behind a live Excel spreadsheet — the response time is fast enough that the spreadsheet feels as if the data is local, even when the database holds millions of records.
Spreadsheets as the Interface, Not a Workaround
Many systems treat Excel as an export destination — a place where data lands after being extracted from the “real“ system. Azquo treats Excel as the primary interface.
Reports are ordinary Excel workbooks connected live to the database. The connection runs in both directions: data flows into the spreadsheet for analysis, and values entered or calculated in the spreadsheet can be written back to the database. Every value carries full provenance — source file, user, and timestamp — so the audit trail is maintained regardless of which direction the data travels.
This means business users work entirely within Excel. They do not need SQL, a BI tool, or a separate planning application. The spreadsheet skills they already have are sufficient.
AI-Ready by Design
Azquo‘s architecture turns out to be well suited to AI. The name/hierarchy model is closer to natural language than relational schemas are — concepts are organised the way people describe them, not the way machines traditionally store them.
We are actively working with AI (Claude, built by Anthropic) to handle Azquo‘s import and reporting conventions. Early results suggest that AI can learn to build Azquo templates, design hierarchies, and interpret database structures with minimal specialist knowledge — potentially removing the need for any Azquo-specific training before a business user can work with the system.
This is an ongoing project, and we are writing about what we learn on our blog.
When Azquo is the Right Choice
Azquo occupies the space between relational databases and OLAP cubes. It is not a replacement for a transactional database that processes millions of identical operations per second. It is designed for situations where:
- Data arrives from multiple sources in different formats
- Reporting requirements change frequently
- Business users need to build and modify their own analytical models
- Audit trails and provenance matter
- The organisation already relies on spreadsheets and does not want to abandon them
If your data fits neatly into a fixed relational schema and your reporting needs are stable, a conventional database will serve you well. Azquo is for the cases where they don‘t.