FiveTech Support Forums

Dear friends,

For decades, we have discussed DBF versus SQL, usually focusing on performance, scalability, and modern technology.

But perhaps today's completely different cybersecurity threat landscape gives us a reason to reconsider DBF.

Two questions seem particularly important to me:

1. How can we protect our applications and customer data from cyberattacks?

2. How quickly and reliably can we recover our original data after a successful attack?

Let's compare DBF and SQL under the same security conditions: no SMB shares, no direct database access from workstations, and all communication through a secured microservice.

With DBF, a Harbour microservice accesses local DBF/FPT files directly.

With SQL, we introduce an additional, continuously running database server that needs its own configuration, updates, monitoring, and protection.
And there is another important distinction: Knowing how to write SQL queries and knowing how to securely install, configure, maintain, and recover a SQL server are two completely different skills.

Being a good SQL programmer does not automatically make someone a qualified database administrator.
Does this additional service also create an additional attack surface?

Of course, DBF is not automatically secure. The operating system, microservice, access permissions, and backups must all be properly protected.

But DBF also has an interesting advantage: our original data remains in directly accessible files, potentially simplifying recovery, provided we have consistent and protected backups.

Perhaps we should reconsider DBF, not out of nostalgia, but from the perspective of today's security requirements.

I would be interested in your practical experiences with server security, microservices, offline backups, and disaster recovery.

Could today's cybersecurity challenges actually lead to a rebirth of DBF?

Best regards,
Otto

Otto, separating prevention from recovery is a useful way to frame this. I would judge the complete deployment and its recovery procedure, rather than declare either storage format the safer choice.

In the architecture you describe, removing workstation access to the data and putting access checks in a service is an important boundary. The next question is what happens if that service, or its account, is compromised. Which records can it read or change? Can it also delete the backups? These questions matter with either backend.

An additional database service is another component to configure, patch and monitor, yes. But that does not necessarily mean another publicly reachable endpoint: OWASP recommends restricting database access to the required hosts, or using local-only access where appropriate. Counting services alone does not establish the overall risk. Equally, a local DBF directory should not be treated as protected merely because it has no SMB share.

For recovery, I would compare a concrete restore exercise:

• What is the maximum acceptable data loss, and how long can the business remain offline?
• How is a consistent backup produced while the application is writing? For DBF, does the procedure cover the related memo files and the chosen index recovery/rebuild procedure?
• Can the production account alter or erase every backup, or is there a protected offline copy?
• Can the application and its configuration be rebuilt on a clean machine, and has someone actually restored the data and checked the business results there?

CISA recommends offline, encrypted backups and regular restoration testing. It also stresses that ransomware can involve data theft: restoring the files addresses availability, but does not undo disclosure.

So yes, DBF deserves consideration when it fits the application and the team can operate and recover it reliably. I would not turn that into a general security advantage over SQL without evidence from comparable deployments. A documented, timed restore test would make this discussion much more useful than a format-only comparison.

References:
https://www.cisa.gov/stopransomware/ransomware-guide
https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html

It was an attempt to start a practical discussion and exchange experiences with fellow programmers again.

But I have the feeling that when AI starts answering on our behalf, something essential gets lost: the human exchange of ideas, experiences, and personal opinions.

And by the way, who is supposed to implement all these textbook recommendations from CISA and OWASP? A single developer without an IT department?

That was exactly my point: We need security solutions that small software businesses can actually implement, maintain, and afford.

I use AI extensively myself, but I don't need AI-generated lectures in a forum where I was hoping to talk to other developers.

So I'll leave it at this attempt.

A rebirth of DBF? DBF never died. And it never will! Some of the questions people ask, I swear!

¿El renacimiento del DBF? El DBF NUNCA murió. ¿Y NUNCA morirá? ¡Vaya preguntas que hacen, ¿eh?!

hahahahaha, jejejejejeje.

Regards, saludos.