A New Approach to Content Storage, Relationships, and Search
We have made software architecture unnecessarily complicated.
Today, if you want to build a simple blogging platform, you are expected to set up a database, backend server, API, CMS, authentication system, and frontend framework.
But why?
If I have 1,000 articles, 20 categories, and 100 tags, why do I need PostgreSQL, MySQL, MongoDB, or an entire content management system just to organize and retrieve those articles?
What if we rethink the entire architecture from the ground up?
What if a few JSON files and a collection of Markdown documents could replace most of this infrastructure?
Not by sacrificing functionality, but by reorganizing how we store, connect, and search information.
1. The Problem With Traditional Database Architecture
Consider a typical blogging platform.
You have articles, categories, tags, authors, and relationships.
Traditionally, developers create database tables:
Database
├── articles
├── categories
├── tags
├── article_categories
├── article_tags
└── authors
Then they build APIs to communicate with these tables.
The frontend requests information from the backend, which queries the database and returns the results.
All this infrastructure exists primarily to answer simple questions:
- What articles belong to this category?
- Which articles contain this tag?
- What is the title of article 105?
- Which articles mention quantum physics?
- What other articles are related to this one?
But these are fundamentally questions about relationships between information.
Do we really need a separate database server to answer them?
For many applications, I don't think we do.
2. Replace Database Tables With Files
Imagine a different architecture.
Instead of storing everything inside database tables, we store the actual content as independent files.
/blog
│
├── articles/
│ ├── 001.md
│ ├── 002.md
│ ├── 003.md
│ └── 004.md
│
├── index.json
├── categories.json
├── tags.json
└── search-index.json
That's the entire foundation.
Four JSON files organize the content, while Markdown files contain the articles.
There is no mandatory database server.
No SQL queries.
No complicated database schema.
The files themselves become the storage system.
The JSON files become the indexes that explain how everything is connected.
3. Categories and Tags Are Just Relationships
Suppose we have four articles about science, physics, technology, and artificial intelligence.
Instead of building relational database tables, we create a simple category index.
categories.json
{
"science": ["001", "002", "004"],
"technology": ["002", "003"],
"physics": ["001", "004"]
}
Now, if someone opens the Science category, the application already knows which articles belong to it.
It doesn't need to perform a relational database query.
The relationship is already available.
We can do the same for tags.
tags.json
{
"quantum": ["001", "004"],
"artificial-intelligence": ["002", "003"],
"research": ["001", "002"]
}
Each tag points directly to the articles associated with it.
And the main index contains information about every article.
index.json
{
"001": {
"title": "Understanding Quantum Physics",
"file": "articles/001.md",
"categories": ["science", "physics"],
"tags": ["quantum", "research"]
}
}
Everything is connected through identifiers.
This is essentially a file-based relational system.
The important architectural rule is that we should not manually maintain the same relationships in multiple places. Article metadata should have one authoritative source, and the category and tag indexes should be generated automatically.
4. What About Searching Thousands of Articles?
This is probably the most important question.
If we eliminate the database, can we still search through every article?
Absolutely.
And we don't need to open thousands of Markdown files every time someone searches for something.
We can build a search index.
Consider this example:
search-index.json
{
"quantum": ["001", "003", "008"],
"physics": ["001", "004", "008"],
"intelligence": ["002", "005", "009"],
"technology": ["002", "003", "010"]
}
This is called an inverted index.
Instead of storing which words belong to each article, we also maintain a mapping showing which articles contain each word.
Now imagine a visitor searches for:
"Quantum Physics"
The search engine looks up both words and identifies articles containing them.
It can rank the results based on how closely they match the query.
For more advanced searching, the index can also store word frequencies, positions, and other ranking information.
We can support title search, full-text search, category filters, tag filters, and combined searches.
And all of this can happen without a traditional database server.
Search Directly Inside the Browser
We can go even further.
What if the website downloads its search index and performs searches locally?
User opens website
↓
Search index loads
↓
User enters a query
↓
Browser searches the index
↓
Results appear
No backend request is necessary for each search.
No database query.
No search server.
JavaScript libraries such as MiniSearch, FlexSearch, and Lunr.js already demonstrate that this approach is practical.
For larger websites, we can divide the search index into smaller files and load only what is necessary.
The search experience can remain fast without forcing users to download the entire content collection.
5. What Happens When We Publish a New Article?
Now comes another important architectural question.
If someone writes a new article, how do we update all these files?
We shouldn't require the author to manually edit categories, tags, relationships, and search indexes.
Instead, we create a simple indexing engine.
New Article Created
↓
Extract Metadata
↓
Assign Article ID
↓
Update Main Index
↓
Update Categories
↓
Update Tags
↓
Update Search Index
↓
Publish
The process can be fully automated.
For smaller collections, we could rebuild the indexes whenever content changes.
For larger collections, we could update only the entries affected by the change.
The author simply writes the article.
The system handles the organization.
In production, we would also need atomic file updates or snapshot publishing to prevent readers from seeing partially updated indexes.
This is where the architecture becomes interesting: the indexing engine replaces much of the work traditionally performed by a CMS and database backend.
6. Should Every Article Have Its Own File?
Not necessarily.
We could organize content in several ways.
For example, one file could contain 20 articles.
/articles
├── articles-001-020.json
├── articles-021-040.json
├── articles-041-060.json
└── articles-061-080.json
Or every article could exist independently.
/articles
├── 001.md
├── 002.md
├── 003.md
└── 004.md
Both approaches are valid.
Individual files are easier to edit, version, and update independently.
Grouped files can reduce the number of requests when distributing content.
We don't necessarily need to choose only one approach.
We can maintain individual source files and automatically generate grouped files for reading and distribution.
The system decides how to organize data based on its usage.
7. Could This Replace a Traditional CMS?
For a large category of websites, yes.
Consider what a CMS actually does.
It allows people to create content, organize it, connect it to categories and tags, retrieve it, search it, and publish it.
Our architecture can provide these capabilities.
A writing interface could edit Markdown or structured JSON files directly.
An indexing engine could maintain relationships automatically.
A static website generator could produce the public pages.
The result would be a publishing platform that doesn't require a continuously running database server or a conventional CMS backend.
However, this doesn't mean we should eliminate databases everywhere.
Applications involving complex transactions, concurrent editing by many users, banking, inventory management, or continuously changing records can benefit significantly from traditional database systems.
File-based storage also requires engineering for synchronization, access control, reliable updates, and recovery.
The point is not that databases are useless.
The point is that we have started using them by default, even when simpler architectures may be sufficient.
8. This Architecture Is Not Limited to Blogging
Now imagine applying the same concept beyond articles.
A bookmark manager could use:
bookmarks/
├── links/
├── categories.json
├── tags.json
└── search-index.json
A personal knowledge system could use:
knowledge/
├── documents/
├── concepts.json
├── relationships.json
└── search-index.json
A research platform could use:
research/
├── papers/
├── discoveries/
├── citations.json
├── concepts.json
└── search-index.json
The same foundation works across multiple domains.
Instead of creating a new database schema and backend for every application, we could build a reusable file-native indexing engine.
It would understand documents, identifiers, metadata, and relationships.
Different applications would simply interpret these files differently.
9. Artificial Intelligence Changes the Equation
There is another dimension to this architecture.
AI agents.
Today, an AI agent interacting with a traditional application may need to understand database schemas, authentication, API endpoints, and application-specific operations.
But imagine giving an AI agent a directory containing articles, metadata, relationships, and search indexes.
The agent could inspect the files, understand the structure, create new documents, reorganize categories, and update content.
It could invoke the indexing engine to rebuild relationships and search indexes after making changes.
We could also introduce semantic search by generating embeddings from the documents and storing a searchable vector index in files.
That would allow users to search for concepts rather than exact words.
For example, someone could search:
"Why do objects never physically touch at the quantum level?"
The system could retrieve relevant research even if those exact words never appear in the article.
This would require an embedding model and a suitable vector-search mechanism, but it would not necessarily require a separate vector database server.
AI agents would still need validation, permissions, and controlled write operations to maintain data integrity.
Nevertheless, this architecture offers something valuable:
Knowledge stored in portable, readable files that both humans and AI systems can work with.
10. We Are Not Eliminating the Database. We Are Rethinking It.
There is an important distinction here.
A collection of organized files and searchable indexes is itself a form of database.
The innovation is not eliminating data organization.
It is separating data organization from the assumption that every application requires a traditional database management system.
We could build an architecture where:
Files are the storage.
JSON represents the relationships.
Indexes enable searching.
Software manages consistency.
AI understands and manipulates the knowledge.
And the application becomes an interface to that information rather than the owner of it.
This approach also has precedents. Static site generators, file-based CMS platforms, and search-index libraries already implement parts of this idea.
What interests me is combining these concepts into one coherent, general-purpose architecture.
11. The Future: A File-Native Knowledge Engine
I think we should stop treating databases, websites, documents, and content management systems as completely separate problems.
At their foundation, they all deal with information and relationships.
We create information.
We classify it.
We connect it.
We retrieve it.
We search it.
And we update it.
Why should every new application require another complicated infrastructure stack to perform these basic operations?
Imagine a single file-native knowledge engine capable of organizing articles, research papers, bookmarks, notes, projects, and other structured information.
A website could read from it.
A desktop application could read from it.
An AI assistant could work with it.
And the information would remain accessible even if the original application disappeared.
No dependency on a particular CMS.
No mandatory database service.
No proprietary storage format.
Just portable information, structured relationships, and searchable indexes.
Of course, this engine would still need careful design around indexing performance, concurrent writes, data integrity, and scaling.
Those are engineering problems we can measure and solve.
But the underlying idea is worth pursuing.
Conclusion: Why Are We Building So Much Infrastructure Around Simple Information?
We have spent decades building increasingly complicated systems to store, organize, and retrieve information.
And in many cases, that complexity is justified.
But not every blog needs PostgreSQL.
Not every knowledge system needs a dedicated database server.
Not every collection of documents needs a CMS.
Sometimes, the content is already sitting there in files.
We just need a better way to connect it, index it, search it, and make it accessible.
Maybe the next generation of software shouldn't begin with the question, "Which database should we use?"
Maybe it should begin with a much simpler question: "Do we need a database server at all?"
And if the answer is no, we should have an architecture that allows us to build without one.
That's the direction I want to explore: a file-native, self-indexing knowledge architecture where information exists independently of the software built around it.