This post is not about databases but against data bases. If you are a big fan of DB, don’t be sad. Maybe you will get a new insight into a different mindset and you will migrate some of your programs that are slowed down by databases to objects and binary files.
I will not discuss databases in my books for three reasons:
1. Databases are quite popular (perhaps too popular), so people can find tons of resources online about this topic. I say they’re too popular because, frankly, in many cases they’re overused or downright abused. In my view, the right conditions for using a database are when:
-
- Data needs to be searched AND it cannot fit in memory. Think of something like a web app with millions of user records where you’re constantly digging through data that won’t squeeze into RAM.
- The user (not the programmer) has to perform multiple search operations using non-repeating search patterns. This is where end-users—like in some fancy business intelligence tool—need to poke around using SQL with unpredictable queries.
Sure, databases have their perks, like keeping data tidy and handling multiple users at once, but they’re not always the golden ticket.
2. I personally have never needed to use a database system in my personal or commercial projects. Instead, I store my objects in binary files, which, are significantly faster and more efficient than databases. Binary files shine when you’ve got big, static datasets that don’t need all the fancy querying nonsense databases drag along.
One of my next books will dive into how to store objects in binary files. If you’re too impatient to wait (each book took me about two years to write —sorry, I’m thorough!), head over to my GitHub repository and poke around my Bioinformatics library. Look for classes like TCube—they already know how to save themselves to binary files. My GitHub repository also contains three examples (from simple to complex) about serializing objects to binary files. I will also make some videos on my YouTube channel ( YouTube.com/@GabrielOnDelphi ) about binary files.
3. In many cases, using a DB in your program, requires you to deploy/install some kind of DB system in user’s computer. Personally, I LOVE (capital letters) monolithic programs – programs where you deliver a single exe file. No installer, no fuss.
1.1.1 Why databases are so abused?
As you have noticed I don’t say that databases are bad – not even by far! There are fair places where they are the perfect solution. What I am saying is that they have been used in places where the program would have been more flexible, faster, smaller and easier to maintain if something else would have been used instead of databases.
So, it’s only fair to dig into the why databases became the default go-to, especially in the Delphi world. It’s not just because they were cool (though they kind of were). There’s a mix of practical, historical, and human reasons behind it, and since you’ve got some solid guesses—data size, programmer habits, and serialization jitters—I’ll build on those. Let’s break it down with the same straight-talking vibe you’re used to.
1.1.1.1 1. Data was too big for memory (back then)
Picture this: it’s the ‘90s or early 2000s, and you’re building a restaurant management app. You’ve got menus with hundreds of items—each with names, prices, ingredients—plus orders, inventory, and maybe customer records. That’s a lot of data, and back then, RAM was more like a teaspoon than the giant bucket it is today. Trying to keep all that in memory? Good luck. Your app would choke faster than a diner on a poorly chewed steak.
Enter databases. They let you stash all that data on disk while still making it searchable – and that’s the key phrase here!
Need the price of a cheeseburger? Query the database, grab just that row, and leave the rest alone. It was a lifesaver when memory was tight. For example, a busy restaurant might track hundreds of orders a day—databases handled that without breaking a sweat….well… except that your program was slow-ish.
Today, with gigabytes of RAM standard, a lot of that data could live in memory. Yet, databases stuck around like an old habit nobody bothered to kick.
1.1.1.2 Programmers were stuck in the procedural era
Delphi was a big deal because it brought object-oriented programming (OOP) and GUI to the table, but not every programmer was ready to give up the familiar data-centric architecture based on some DB engine for the new, modern object-oriented programming. Many came from the procedural world—think Pascal or C—where life was all about functions and procedures. Objects? That was a whole new beast. Some folks looked at OOP and thought, “Nah, I’ll pass.” They weren’t afraid of objects in a horror-movie sense, but more like, “Why fix what ain’t broke?”
Plus, using objects right means knowing how to build a proper software architecture—a chain of objects that play nice together. That takes skill: encapsulation to keep things tidy, inheritance to reuse code, polymorphism to make it flexible. Without that know-how, you’re more likely to end up with a tangle of code than a sleek system. So, instead of wrestling with objects, programmers kept using what they knew better: databases. Tables and rows felt familiar, like a procedural comfort zone, even if it meant overcomplicating and slowing down things.
1.1.1.3 Serialization Seemed Scary
Objects are great in memory, but if you want them to stick around after the app closes, you’ve got to serialize them—turn them into something you can save, like a binary file. In Delphi, that often meant mucking around with streams and bytes, which could feel like a dark art to some. Binary objects? Intimidating is right. One slip-up with byte order or versioning, and your data’s toast. Compare with databases, they are fast, but furious “beasts”. For databases didn’t need to think about how the data got saved—just toss it in a table, and the database handled the rest. No fiddling with low-level details, no sweaty palms over corrupted files. For programmers spooked by serialization, databases were a cozy blanket—even if they were overkill for something simple like saving a few settings.
Side note: I still see today (older) programmers burdening their simple app with some DB engine only because they wanted to save same basic settings at program shutdown.
1.1.2 Why Delphi made it worse (or better?)
Delphi didn’t just play along; it practically begged you to use databases. The IDE was a dream for data-driven apps—drag a few components onto a form, hook them up to a dataset, and bam, you’re done. It was so slick that even a newbie could build a database app in an afternoon. Tutorials, books, and example projects all sang the same tune: databases are the way. Delphi books about software engineering. Zero. It was like Delphi handed you a shiny database hammer and said, “Go hit everything with this.”
And for big, complex apps, that made sense. But for smaller stuff—like storing user preferences—there were simpler options: binary files, INI files, whatever. Didn’t matter. Databases were so easy in Delphi that programmers used them anyway. Why learn to serialize when you could just drop a `TDataSource` and call it good?
1.1.3 The tide is turning, Silvester
Things aren’t what they used to be, though. Here’s why databases are losing their grip:
Memory is cheap: Modern PCs have RAM to spare. That restaurant app? You could probably keep its whole dataset in memory now, no disk required.
OOP isn’t alien anymore: Programmers have gotten the hang of objects. Better education and resources mean more folks can build solid architectures without breaking a sweat.
Serialization got simpler: Delphi’s `TStream` and third-party libraries (like JSON tools) have taken the sting out of saving objects. It’s not rocket science anymore.
Plus, new options like NoSQL databases—think MongoDB or CouchDB—offer lighter, more tailored alternatives to old-school relational setups. In the Delphi crowd, the mindset’s shifting too. Databases still have their place, but people are starting to ask, “Do I really need this?”
Next time you’re itching to spin up a database for a tiny project, pause and think: is this overkill? Chances are, it might be.
1.1.4 New fields: New trends
In the molecular biology field, where I activate a lot, preliminary genomic sequences or protein data (we’re talking exabytes to petabytes, per university) is stored exclusively in binary files. For datasets that massive databases would be laughably slow and pile on way too much overhead.
My prognosis? As data keeps ballooning, we’ll see a shift away from traditional SQL/relational databases to something better suited for the job. Cloud providers are already jumping ship—check out stuff like AWS DynamoDB or Google Bigtable, their non-SQL options built for massive, sprawling data.
Find more about software engineering in Delphi.