I don't think it's a better or worse decision. The question was "Is SQL overrated?"
It depends a lot on what you want to do with the data — whether you're just collecting it or actually working with it.
I often wonder why companies still need so many Excel spreadsheets despite using SQL?
What’s needed is an update to the DBF format and a group of people to take care of it. DBF is the POS (point of strength) of Harbour/FiveWin.
There are other specialists and programming languages for SQL. By focusing on SQL support, we (Clipper/Harbour and its successors) are undermining our own foundation. In total, only a few percent of Clipper/Harbour and its successors -programmers actually use SQL — but they demand and receive the full attention of the community.
From a marketing perspective, wouldn’t an xBrowse with variable row height be more valuable than yet another SQL dialect for just a few programmers?
It weakens the developer’s self-image: “I used to do everything locally, portably, directly – now I have to deal with engines, dumps, user rights, and query errors?” This scares off smaller companies, solo developers, and niche software – the core of the HARBOUR/FIVEWIN/Xbase audience.
SQL might be the right choice for individuals — but not for Harbour/FiveWin.
If we want to attract new users, we need to look at the market of Excel programmers, GIS user, DMS systems.
Don’t replace DBF – improve it.
A modern DBF 2.0 with: Unicode support, longer field names,parallel index support,transaction logging,easy JSON export ...would be a future-proof format that fits.
I once asked this question to every AI personally available to me. Here's a compressed summary:
It depends a lot on what you want to do with the data — whether you're just collecting it or actually working with it.
I often wonder why companies still need so many Excel spreadsheets despite using SQL?
What’s needed is an update to the DBF format and a group of people to take care of it. DBF is the POS (point of strength) of Harbour/FiveWin.
There are other specialists and programming languages for SQL. By focusing on SQL support, we (Clipper/Harbour and its successors) are undermining our own foundation. In total, only a few percent of Clipper/Harbour and its successors -programmers actually use SQL — but they demand and receive the full attention of the community.
From a marketing perspective, wouldn’t an xBrowse with variable row height be more valuable than yet another SQL dialect for just a few programmers?
It weakens the developer’s self-image: “I used to do everything locally, portably, directly – now I have to deal with engines, dumps, user rights, and query errors?” This scares off smaller companies, solo developers, and niche software – the core of the HARBOUR/FIVEWIN/Xbase audience.
SQL might be the right choice for individuals — but not for Harbour/FiveWin.
If we want to attract new users, we need to look at the market of Excel programmers, GIS user, DMS systems.
Don’t replace DBF – improve it.
A modern DBF 2.0 with: Unicode support, longer field names,parallel index support,transaction logging,easy JSON export ...would be a future-proof format that fits.
I once asked this question to every AI personally available to me. Here's a compressed summary:
🧠 How long will SQL retain its current relevance?
📉 SQL today is “legacy by default.”
It dominates not because of innovation, but because it's already there — in toolchains, frameworks, and job descriptions.
The next generation doesn’t use SQL directly, but through ORMs, no-code platforms, or abstracting backend services.
In AI-based architectures (LLMs, retrieval engines, embedding systems), SQL is no longer central:
Vector databases (e.g., Weaviate, Pinecone, Qdrant) are non-relational
JSON/DocStore approaches like MongoDB, Typesense, DuckDB, Zep, etc., are structure-flexible
AI works with text, not with tables
🤖 AI radically changes data access
Before AI → After AI
Tables, columns → Embeddings, documents, tokens
Queries, joins → Prompts, relevance, context windows
Formal models → Semantic search
SQL optimization → Prompt optimization, chunk strategy
Data engineers → Prompt engineers / Data curators
➡️ AI needs structured raw data in text form — JSON, Markdown, or XML — not SQL join logic.
➡️ The next generation asks:
“How do I embed this invoice?”
not: “How do I LEFT JOIN it?”
📊 Forecast (realistic):
Timeframe SQL relevance in practice
2025 Stable but stagnating
2030 Largely replaced by AI/NoCode/LLM abstractions
2035+ SQL as a niche solution (audit, reporting, legacy)
Continuity Only in large enterprises, government, legacy projects
🧩 Conclusion for developers and decision-makers:
SQL is like COBOL: it will never completely disappear — but it won’t be central anymore.
The future belongs to formats that are machine-readable, semantically analyzable, and versionable.
DBF + JSON + filesystem logs are suddenly not outdated,
but ideal sources for AI, LLM processing, and audits.
