I'm familiar with SQLite and Derby. I used SQLLite in a Ruby project before and I looked at Derby for a personal Java project that went nowhere. Both of these were 2+ years ago, and I'm sure much has changed. What are the top contenders (preferably free) today?
Could you elaborate on these choices? What advantages/disadvantages do they have over others?
Thomas Owens
2008-10-31 19:09:56
+7
A:
SQLite is still an excellent choice. It's undergone performance tuning and sits at the core of a large number of applications now as a purely embedded database for that specific application. It's lightweight and very functional - it's provided as a common underpinning on small devices like the iPhone and Android, and plugs in to a large number of different languages.
heckj
2008-10-31 19:07:29
Ah. It's good that something that I'm somewhat familiar with is still mainstream. I didn't think it was what popular when I used it, so I expected it to be alone and dying. Thanks.
Thomas Owens
2008-10-31 19:09:23
Actually the website speculates that it's the database with the most installations in the world, so no way it's dying, it even growing under the hood of the sqlite-foundation.
André
2008-10-31 21:02:42
+1
A:
You could also look at db4o at http://www.db4o.com/. I've played about with it but never used it in anger.
Jackson
2008-10-31 19:10:40
Looks interesting, but I do want to point out that it can't be used in commercial products without a license (or so it appears).
Thomas Owens
2008-10-31 19:11:59
I thought it was released under the GPL and they only charged for support? The site does say that it's a GPL licensed C# database.
Jackson
2008-10-31 19:31:45
A:
XML or other forms of text files... But serverless designs are slower; why do you want a serverless database?
tsilb
2008-10-31 19:16:20
Because of the capabilities of databases that I would have to roll my own for if I used XML or text files. And to store relational data (possible in text files, not so clear in XML).
Thomas Owens
2008-10-31 19:18:24
Actually, embedded databases are not always slower. In fact, for small datasets (<1GB), they are usually *faster*.
Daniel Spiewak
2008-10-31 19:18:49
i modded you up. xml is definitely a valid option. take for example, linq to xsd.
Shawn Simon
2008-10-31 21:00:40
Why do you thing serverless is slower? Don't forget that there is no network overhead with a local db on the filesystem that modern machines could even fit completely into memory. That's a magnitude faster than network traffic.
André
2008-10-31 21:06:10
I specify it as slower because you generally have to run through the entire file(s) or object(s) for each query, versus having incdices. Obviously it does have its applications.
tsilb
2008-11-02 05:58:51
André - There would also be no network overhead if you installed SQL Express, MySQL, or MSDE locally.
tsilb
2008-11-02 06:00:11
+9
A:
SQLite is a fine choice, but it is a bit limited in some ways in what it supports. That's fine for a lot of applications (e.g. CoreData), but some folks might find it limiting. Also, SQLite doesn't work very well in Java (bad drivers).
Derby is also very nice, but it is Java specific unless you run it in server mode. It supports almost all standard database constructions, including triggers, stored procedures, indexes, etc. It's also very stable. The major problem I have with it is it is dog slow compared to SQLite.
One item which is not on the list so far but deserves to be is HSQLDB. It supports almost as many features as Derby (more than SQLite), and is utterly, blisteringly fast. It even has an in-memory mode for temporary databases and the like (I use it for testing ActiveObjects). Since they fixed the data-loss bugs a few years back, it's been very stable and reliable for most applications. Many Java utility webapps use it because it allows config-free installation (e.g. Hudson, Jira, Confluence, etc). The one downside is it is Java-specific in embedded-mode. However, if you're considering Derby, that might not be an issue. I would highly recommend this option.
Daniel Spiewak
2008-10-31 19:18:05
Doesn't work well in Java? But it's the underpinning of any Android data-acess. That's a little weird.
jcollum
2010-06-17 05:51:22
A:
Microsoft Access would also be a serverless database though I doubt many would think it a good idea.
JB King
2008-10-31 19:19:14
Yeah, Access is a horrible choice for an embedded database. Amusing thought though. :-)
Daniel Spiewak
2008-10-31 19:20:07
+4
A:
Let's not forget the venerable Berkeley DB
And a new iteration on the concept, Tokyo Cabinet
Vinko Vrsalovic
2008-10-31 19:20:06
+1
A:
Codebase just keeps on truckin'. I ported a bunch of code from DOS through windows and now into CE, with no changes.
And since they charge a little bit of $$, it's fully supported.
le dorfier
2008-10-31 20:58:33
+3
A:
I'd go with Firebird. It:
- is completely SQL compliant with all the advanced features like foreign keys, triggers, stored procedures and views.
- has a very small footprint (just a couple of DLL files, a few MB total).
- is super easy to deploy (just copy those files with your executable)
- works on Windows, Linux, Mac
- is open source and free for commercial deployment
- keeps the entire database is a single file, so it's very easy to backup and move around
- scales very good: if you decide to go to full server one day, you just change the connection path, i.e. ONE LINE in your code or config file.
Milan Babuškov
2008-11-02 18:22:41
A:
There are plenty of applications out there that need a serverless database engine. Maybe they want to xcopy or click once deploy to desktop and need a database present for queries and reporting.
If you are developing for .Net applications you could look at VistaDB. See the SO thread on Advantages of VistaDB for more information.
- Full disclosure - I am the owner of VistaDB so I may be biased. :)
Jason Short
2009-04-22 02:34:15
+1
A:
Whatever you do - don't go with VistaDB. Their web site looks good and all that but the database sucks. I would suggest SqlLite. Really depends on how you are planning to use it.
IDaho
2009-11-01 23:04:29