Hello friends,
since there are currently very few technical problems, I think it's a good time to deal with future-oriented topics.
I'll start with a provocative statement.
I'm curious to hear how you see the future.
Best regards,
Otto
Why SQL Is Overrated – and Why Files, DBF, and Microservices Are the Future (Especially for Web and AI)
- SQL hides your data behind layers of magic
“You don’t own your data if you can’t see it.”
-
Data is trapped in engines and formats
-
You need specialized tools to export, debug, or back it up
-
Indexes? Hidden. Logs? Hidden. Snapshots? Only if the DB supports them
-
With files and DBF: Your data is visible and copyable as
.dbf,.json, or.txt
- Filesystems are more transparent, flexible, and AI-friendly
“AI loves structure. Not secrecy.”
-
AI works best with plaintext, JSON, Markdown, CSV
-
SQL? You have to export, transform, clean, and explain the schema
-
With DBF + memos + JSON:
-
Every record is ready for NLP or semantic processing
-
Every field is directly searchable with
grepor shell scripts
- SQL is a monolith. Files are composable.
“You don’t need a cathedral to store customer addresses.”
-
SQL locks you into transactions, schemas, and foreign key drama
-
Every new tool needs a connector or query engine
-
With DBF:
-
You can output JSON, build views, or parse records with any scripting language
-
Works offline, in the browser, in a microservice, or even from a USB stick
-
Query logic should live in your code – not buried in a database engine
-
SELECT * FROM sales WHERE status = 'paid'is readable – but trapped -
As soon as logic lives in SQL views, triggers, or stored procedures:
-
It’s no longer portable
-
Not versionable
-
Not reusable outside the SQL engine
With PHP, JS, or Python:
-
Your filters, validations, and logic live in real code
-
In Git, in your editor, right next to your UI
- Want auditability? You won’t find it in SQL logs
“Dump files ≠ backups. Binary logs ≠ trust.”
-
With files, auditing is easy:
-
Use Git, rsync,
diff, or timestamped snapshots -
With SQL:
-
You have to trust the engine, hope logging was enabled, and pray your dump isn’t corrupted
File = Control.
SQL = Delegation.
-
Want AI or LLM integration? SQL is your bottleneck
-
AI doesn’t query databases – it processes text
-
In the end, you’re exporting SQL data as JSON anyway
-
So why not store it as JSON, CSV, or DBF from the start?
Examples:
-
Memo fields as
.md→ embeddings, summaries, Q\&A -
ripgrepacross DBF memos = instant full-text search -
JSON APIs from
php4dbf_list()→ LLM-compatible feeds
- SQL is good for scaling. But most systems don’t need Google scale.
“Most projects need 10,000 records. Not BigQuery.”
-
SQL shines at massive scale – but brings setup, maintenance, and lock-in
-
Flat files + microservices are:
-
Easier to deploy
-
Easier to secure
-
Easier to migrate
Summary: SQL isn’t bad – but for many modern workflows:
Plain Files + Microservices + Grep > Databases
Feature | SQL | Filesystem + DBF + Tools
---------------- | ---------------------------- | -----------------------------
Portability | Engine-bound | USB-ready
Auditability | Hidden logs | Git, diff, snapshots
Transparency | Tool-dependent | Text editor and shell
AI suitability | Requires export | Native formats
Learning curve | SQL syntax & logic split | Pure scripting
Web integration | Requires APIs | Direct access via PHP/JS
Complexity | Views, joins, keys, rights | Files, folders, grep
Want web, AI, and data sovereignty? Start with:
-
DBF (or JSON/CSV)
-
Plaintext memos
-
Modular scripts
-
APIs instead of queries
-
Git instead of binary logs
**SQL is useful – but often oversized.
The future belongs to files, not engines.**
