I began my programming career in web development using PHP and MySQL. I got quite accustomed to utilizing db for storage of most dynamic data as well as some setting/parameter data. Sometimes there would be a lot of data while other times entries in the tables would be few. To me this just seemed natural and as far as I'm aware this is more or less an acceptable approach in web development. (Please correct me if I'm wrong...)

I'm delving into desktop applications now and my natural inclination is to again utilize a db to store a lot of information that will be generated through the usage of the application. However, as far as I can tell I don't see applications (that I use) utilizing a db very often. [EDIT: It has since been pointed out that this was a faulty assumption in that many applications do use lightweight dbs embedded into the program itself.] What is the reason for this? At what point is it appropriate to utilize a db? Are there any standards on this matter? Also what are the reasons to NOT use a db to develop a desktop application?

  • 2
    "However, as far as I can tell I don't see applications (that I use) utilizing a db very often"? Based on what? If they used SQLite, how could you tell if they were or were not using a database?
    – S.Lott
    Commented Mar 23, 2011 at 0:44
  • That was why I said as far as I can tell as I knew there was a possibility I was wrong. I figured there might be some apps that use embedded db's... Is it pretty common for apps to use dbs?
    – Kenneth
    Commented Mar 23, 2011 at 0:55
  • @Kenneth: Please Google for embedded DB's like SQLite. There are many. They're widely used. AFAIK, Apple's iOS uses it for all persistence. Please Google.
    – S.Lott
    Commented Mar 23, 2011 at 1:24
  • 2
    I Google a lot. Sometimes though nothing replaces experienced opinions which you can't always find googling.
    – Kenneth
    Commented Mar 23, 2011 at 1:39
  • 1
    I think these comments are sufficient to correct the faulty assumption. I apologize for the error. I feel I use a healthy mix of googling and asking questions. Sometimes there's no substitute for latter IMHO. Now my googling will be better directed and more productive.
    – Kenneth
    Commented Mar 23, 2011 at 2:30

7 Answers 7


if your application is document-oriented, store things in a document file

if you application deals with more structured data, too much for a single document (like an XML document), use a database


A database system has traditionally been seen as a relatively heavy service - that you didn't necessarily want to install on every client machine out there. I've actually been in situations (desktop GUI app development where a lot of data needed to be saved) where a real DB system would have been an "ideal" solution - but because back in the day the only available databases were relatively heavy, we went with flat data files instead.

Despite there being some lighter databases out there these days, this is still a valid argument against client-side databases. Imagine some simple little desktop app (such as say, a simple desktop toy or game) that has to store a few dozen settings and parameters. It seems way over the top to make a person install MySQL just to run your app.

With web development, the server is naturally a back end, where having a database is par of the course. eg. The users don't have to worry about installing a database at their end.

  • So you would recommend not using a db for stand-alone apps then unless heavy volumes of data really warranted it?
    – Kenneth
    Commented Mar 23, 2011 at 0:42
  • what are your thoughts on using lightweight db's... same as the full-scale db's?
    – Kenneth
    Commented Mar 23, 2011 at 0:44
  • 1
    @Kenneth: I'd say "it depends". If the app calls for large volumes of tabular data that really calls for being in a proper DB, then the argument might be strong enough to ship the app with a lightweight DB. But if it's just configuration/settings kind of data, then it's probably overkill. Commented Mar 23, 2011 at 3:28

Desktop applications maintain state while they are running. Whereas web development typically doesnt. So while you might need to store a user setting in a database in between page loads, in a desktop app you just keep them in memory. That greatly reduces the need for such types of persistant storage. When you want to store preferences between uses, you can save them all to one file, or put them someplace like the Windows registry.

That being said, database systems are used quite a lot in desktop apps. Long before the web, desktop applications have been connectiong to DBMS's. Primarily for applications that are not document based. Though these days, with the better availability of light weight engines, you're seing the lines blurred a little bit. For ex, I use SQLite db's as documents in a few of my apps.

  • +1 If you don't have complex persistence issues, like multi-user, multi-location, simultaneous blocking updates a traditional database might be overkill. If the data in question is fairly static (it may grow or get appended to, but does not evolve or get updated), and contension/competition isn't frequent or perverse (side effects/user-experience for waiting on a lock to free isn't unacceptable considering performance and complexity tradeoffs), you may not need a database.
    – JustinC
    Commented Mar 23, 2011 at 5:38

One thing you might want to look into are lightweight databases that don't require an actual running database service. e.g. on the Microsoft front there is SQL Server Compact, which is free, only requires a single file for the database and some DLLs added to your app, and from a developer's perspective, behaves much the same way as a "real" SQL Server.

I am positive there are similar options on other platforms.

  • 1
    A very similar example on the Java side is Derby. I think there are others, too.
    – jprete
    Commented Mar 23, 2011 at 0:32
  • 1
    This sounds like it might be an ideal solution... I really enjoy utilizing db's! lol
    – Kenneth
    Commented Mar 23, 2011 at 0:43
  • Are there downsides to using lightweight db's?
    – Kenneth
    Commented Mar 23, 2011 at 0:44
  • @Kenneth: They make your installation larger and can increase the codebase. But that is much less than installing a whole database server on a client, that is only usually done when the application is distributed and needs a more substantial database. The Berkeley DB is one of the most commonly used.
    – Orbling
    Commented Mar 23, 2011 at 0:53
  • another option is SQLite, which is far lighter on both RAM and disk space, and doesn't have any arbitrary limitations. No wonder it's used by all non-MS smartphones and web browsers.
    – Javier
    Commented Mar 23, 2011 at 1:55

On web applications, it's important to store any persistent state on a centralized storage. Since the web app is usually first bottleneck, it's important to be able to just distribute it without having to question which copy has the data (the 'Shared Nothing' principle). Not just a database, but memcached and queue systems are there for the same reason.

Desktop apps don't have the same scalability goal. Typically, most of the data is locally stored on each workstation. Data sharing is a different issue in most cases. That eliminates one big reason to use a database.

GUI applications also can have complex documents which might be handled as a complex web of objects in memory. Normalizing the structure into a relational DB schema can add significant complexity to the problem, sometimes it's easier to just serialize the whole thing in a single bytestream. Many OOP frameworks include some facilities just for that.

Still, making the stored documents readable with tools outside of the main application is a big advantage in many cases, so either using human-readable formats (XML, JSON, YAML, etc), or a zipfile amalgamating several simpler pieces are getting more and more common.

On the same vein, using an embeddable database library (BDB, Tokyo Cabinet, SQLite, MS-SQL*server Compact, etc.) is another great approach.


Databases can be overkill but they usually don't have to be. Very simple programs just don't need them. If your document can load up in memory in a trivial amount of time and stay there without issues, you don't really need one for many programs.

For instance consider:

#include "superheader.h"

int main()
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    string hello_world=db.fetch(row, column);
    return 0;

Well that is overly simplistic, but obviously this is just too much. There's no real point to having that level of data management for "Hello World"

Usually the rule of thumb I go by is use a database if you have many sets of data, especially if they are uniquely different OR use a database if the amount of data is rather massive. Databases in general are associated with some overhead, but there are many which don't really have much. Small, lightweight, in-memory databases for instance are sometimes useful for small projects with heavy processing, scheduling or lots of dynamic changes to the data.

There are different coding styles, many many times there is nothing wrong with a database but most of us just wont go 'that far' for basic tasks. There are still other times the right database would offer performance benefits. Try to especially understand the differences in where the data will be, how long it will be there and what will change it during it's lifespan.


Using a db is always the right thing and with SQLite implementations for practically every language out there not using one is just poor design decision making. The only reason not to use one is if you're doing embedded programming or some other type of non-application form of programming. Querying data and settings with a declarative language like SQL is much more natural than traversing flat files or other objects in memory with imperative syntax. Plus, it cleanly separates the data operations from other application code which in the long run makes code more modular and maintainable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.