Slashdot Mirror

"Is there any open source in memory database? Prefereable fast and stable?"

SQLite has a command line switch to load the and run the database in memory. Unless you're in need of some RDBMS specific tools (replication, etc.) this little gem is the best things I've seen.

And I'm equally tired of hearing from MySQL haters who bitch and bitch and bitch about how MySQL isn't worth shit and should never be used for anything, anywhere, ever. Need I remind you that the very site you're looking at runs on MySQL and handles literally millions of pageviews per day? OK, fine, I won't. How's this then: hundreds of the 33,000 employees where I work rely on MySQL daily, whether they know it or not. Phone lists, surveys, reporting apps, inventory databases, etc etc etc. MySQL does the job and does it just fine. It has not failed me once in all the years I've been using it.

And SQLite is better? Because it's ACID? HA! HA HA HA HA HA! GIVE ME A FUCKING BREAK! That's the only buzzword it IS compliant with. Look at this:

Q: SQLite lets me insert a string into a database column of type integer!
A: This is a feature, not a bug. SQLite does not enforce data type constraints. [emphasis added]

and this:

Q: What is the maximum size of a VARCHAR in SQLite?
A: SQLite does not enforce the length of a VARCHAR. You can declare a VARCHAR(10) and SQLite will be happy to let you put 500 characters in it. And it will keep all 500 characters intact - it never truncates.

and this:

Q: Does SQLite support a BLOB type?
A: SQLite versions 3.0 and leter let you puts BLOB data into any column, even columns that are declared to hold some other type.

all this and more can be seen at http://www.sqlite.org/faq.html

"And Postgresql is far more robust and performs just as well."

And only recently ran natively under Windows. Sorry, but when you're in a company with 33k employees and a substantial IT department, you don't always get to pick your platform. MySQL was there, it worked, and it continues to do so. Why would I switch?

Let me make the required car analogy: a semi is several orders of magnitude more powerful than a 2WD pickup truck. A semi can haul more, and haul more further, and haul big loads more efficiently, and with a sleeper cab and two drivers can operate 24/7, and you can get refrigerated units to move food, etc etc etc. Why, then, are there millions of 2WD pickups sold? Are they just "shitty vehicles with lots of mindshare"? NO! It's because 99.9% of the population just wants to move a couch or go to Home Depot or something. Maybe it'll take a few trips to help a friend move, but even that takes fewer hours than getting a class-whatever license, plus pickups are easier to maneuver and park in apartment complex parking lots and residential neighborhoods, etc etc etc.

I'm not saying MySQL is better than everythinhg else. The fact is, databases and computers are SO capable now that even the WORST in the field is STILL more than 99% of people need. In other words, MySQL is Just Fine.

PS: MySQL is ACID when used with InnoDB tables which came out about 3 years ago. Time to update your troll.

Can we get over mysql already? Even sqlite is a better, and faster, database now. It's ACID, which mysql is not: http://www.sqlite.org/lockingv3.html

And Postgresql is far more robust and performs just as well.

What does mysql offer any more that the other OSS databases don't? Is it just that it's the M in LAMP? I'm so tired of hearing about Mysql, and all the Mysql drama, when it's just a shitty database that has a lot of mindshare.

Fair enough. But no one forces you to use MySQL (other than maybe your clients/employer). Also, MySQL is good enough (tm). You know, the principle that made Microsoft successful. Not necessarily the best software, but good enough to be used to host your average random hacker web project. Over the years more and more start to use MySQL for larger systems, because of the experience they have with the database, and they know that it worked pretty well for them in the past.
Sure, they may all be wrong, stumbling around in the darkness - that's why we need the Postgresql fanboys to advocate their viewpoint. But to bash MySQL without backing it up with references and facts is just pointless.

Can we get over mysql already? Even sqlite is a better, and faster, database now. It's ACID, which mysql is not: http://www.sqlite.org/lockingv3.html

And Postgresql is far more robust and performs just as well.

What does mysql offer any more that the other OSS databases don't? Is it just that it's the M in LAMP? I'm so tired of hearing about Mysql, and all the Mysql drama, when it's just a shitty database that has a lot of mindshare.

postgresql->oracle is the best combo in the book. Every project my company has touched in the last 7 years started with postgresql and if we ran into one of the limitations in postgresql, switching to oracle was painless.

Between them, sqlite->postgresql->oracle offer a full database solution for everything from "I want a better config file for my personal scripts" to "I have to run a mission-critical database for a Fortune 500 corporation", and you can't say much fairer than that.

For a very small website SQLite is your best choice - fast enough and no maintenance. For small to medium, Postgres and MySQL are comparable in terms of the amount of management you need to do to keep them running. MySQL does have a more interesting SQL dialect, so if you use its nonstandard features you can get by writing less code. With large numbers of concurrent users - or if you're using complicated queries with many joins - Postgres is going to come out ahead since it's just better at handling that sort of thing.

A small website should probably use http://www.sqlite.org/. It doesn't require administration or setup. A complete database is stored in a single file. And it implements most of SQL92. Probably more than MySQL but I'm not positive.

I currently have PostgeSQL running on my Tiger box. I initially installed it just to experiment with SQL and database normalization, but now I keep my comic book inventory on it. (I know that this is like swatting a fly with a nuclear weapon but I enjoy using PostgreSQL and it is FREE software.)

SQLite goes one better and is public domain software. It comes with Tiger, too, which makes it a great tool if you don't need an actual server for your SQL play.

"... I always come up against limitations that I can't live with..."

May I ask, what features do you need that aren't in SQLite or PostgreSQL?

Another question: I wonder if the free version of Oracle will work with Compiere ERP + CRM, at least for testing?

Here is a Comparison of Oracle, MySQL and PostgreSQL DBMS.

ZDNet article: Oracle to offer free database.

I was not able to find the list of limitations on the Oracle web site. Anyone?

Aha, i didn't know this. That explains the specs a bit more.

I don't see it as competition to opensource offerings, because a) it's not opensource and b) it's extremely limited. It's main use is to install it on a developer machine to make sure they don't mess with the real database.

And anyone considering this for embedded should probably go for sqlite instead.

SQLite is meant to be embedded, and isn't really comparable to MySQL (consider, if you will, that SQLite doesn't actually include an GRANT or REVOKE statements).

Apples and oranges.

... and just watch a million geek blogs get converted to SQLite.

I haven't tried ibFirebird yet, and for most things it's not really up to PostgreSQL's level, but I have a peer who uses it with great success. It's one of several databases (all mentioned here are included) with features and syntax explicitly designed to make conversion from Oracle easy.

Besides, "not up to PostgreSQL's level" is massive overkill for most projects.

In Real Life(tm), even SQLite is overkill for most projects: SQLite is quite capable, where a SQL interface to flat files and perhaps some rudimentary indexing would be more than enough for 90% of what's out there.

Some people want something that is very lightweight and fast.

In which case they should use something like SQLite, which unlike MySQL doesn't claim to be more than it is, has a better license and actually sticks with standards.

For blogs, SQLite would be more appropriate. I believe MovableType already supports SQLite. This would allow people to run blogs on cheaper hosts.

Thousands of webmasters and home-based coders don't want a competitor to Oracle, we want something that gets he job done quickly, efficiently and affordably.

If speed is your only criteria about what database is best, you should probably use SQLite. The last time they benchmarked its speed, it was significantly faster than both MySQL and PostgreSQL.

But the real point of this post is that making speed your only criteria does make you sound like a blind moron. A database is much more than its speed characteristics. Other considerations are: quality of documentation, richness of data types, SQL features supported, options for locking and concurrency, options for writing procedures in the database, facilities for partitioning and controlling the growth of the data store, and much more.

If these are not considerations for you, you are probably working on toy problems that would work just fine with SQLite.

In fact, I am suprised to not yet have seen systems like Gnome and KDE fire up a stripped down PostgreSQL process or something similar to provide applications with an excellent database for whatever their needs might be.

It called SQLITE and KDE has been debating making it a part of core for years. Qt provides an excellend database abstraction layer though, so it seems pointless to enforce sqlite when some users might prefer mySql or Postgresql.

I'm guessing GNOME does much the same, but I don't follow that desktop.

Need I remind you of SQLite. Albeit, other than this, you are probably right.

AOL does contribute to useful open source software. AOL developers contribute to SQLite and have helped produce numerous useful additions to SQLite.

Quote: The primary purpose for version 3.2.0 is to add support for ALTER TABLE ADD COLUMN. The new ADD COLUMN capability is made possible by AOL developers supporting and embracing great open-source software. Thanks, AOL!

If you are looking for an Oracle replacement try postgresql. Depending on what your needs are it might be better than Oracle, though if you needs are typical of what a business wants Oracle is likely better. Being open source (and more free than MySQL is, as the license is BSD) people do hack it to add weird things to their database.

There are a number of open source databases. MySQL gets the press. That does not mean it is best for your purpose, so you really should examine them all yourself.

Which is best is partially a matter of opinion. Mine is that between sqlite on the low end and postgresql on the high end there isn't much room for more general purpose SQL databases. Of course there are others, I'm not going to list them all because I'll forget at least one if I try.

It is undoubtedly a good thing that the securities trading and depositary apps that I used to work on (not as a developer btw) used Oracle rather than MySQL

On the other hand I see no problem with my blog using MySQL.

Maybe the right way to think of MySQL is not as something like Postgres without data integrity features, but as a something that fits in somewhere between the likes of Postgres and things like SQLite.

The only time that I ever heard anyone suggest MySQL for a financial application it was a fairly lightweight one and and the idea was rejected pretty quickly anyway. Unfortunately I do not think anyone present even gave a thought to Postgres and its like but went with Oracle (as usual).

I suspect MySQL does restrict the use of FOSS DBs because it has so much mind share that when people consider OSS DBs they think of MySQL and if MySQL is not suitable they pick a proprietary DB instead.

As mysql bulks up, if you still want wicked-fast raw inserts with low-overhead engine, consider sqlite. Personally, I'm eager to get the triggers, views and stored procedures, as it will enable PHP apps to mature a bit.

Ahahahaha. Let's review.

1) Run a file search on Windows. Go get a coffee and then see the results. Realize that you can only search on basic attributes of the file, like name/dates/raw content.
2) Run a file search on OS X. Click your heels twice and then see the results. Still, you're limited to some basic attributes.

Some months (or years, in the case of WinFS) from now...
3) Run a file search on WinFS. In theory you get hits pretty damn quickly, if they ever finish this technology. I'm not sure yet what extra file info you'll be able to search on, but I imagine it's more than the basics.
4) Run a file search on OS X Tiger. Not only is your search blindingly fast, but you can search on arbitrary file metadata (it will index things like EXIF data, ID3 tags etc). Also, you can save stock searches which will automatically update when new matches appear in the FS. I believe this technology was brought over with BeOS coders.

I am so used to the OS X file search speed and Mail.app search speed that on my work Windows laptop I was forced to buy X1.com's search tool to get around the incredibly annoying (when you're not desensitized to it) delay when searching in either Windows Explorer or Outlook. The market for this utility should frankly not even exist. It should be the responsibility of the OS to help you find things as quickly as possible, and it should have been done YESTERDAY. I mean Jesus, it doesn't take a rocket scientist to embed something like a SQLite engine in your email client code.

I'm glad that Microsoft is finally getting around to this (someday) but in the meantime I will be quite happy when Apple's Tiger shows up on my doorstep early this summer.

Ahahahaha. Let's review.

1) Run a file search on Windows. Go get a coffee and then see the results. Realize that you can only search on basic attributes of the file, like name/dates/raw content.
2) Run a file search on OS X. Click your heels twice and then see the results. Still, you're limited to some basic attributes.

Some months (or years) from now...
3) Run a file search on WinFS. In theory you get hits pretty damn quickly, if they ever finish this technology. I'm not sure yet what extra file info you'll be able to search on.
4) Run a file search on OS X Tiger. Not only is your search blindingly fast, but you can search on arbitrary file metadata. Also, you can save stock searches which will automatically update when new matches appear in the FS. I believe this technology was brought over with BeOS coders.

I am so used to the OS X file search speed and Mail.app search speed that on my work Windows laptop I was forced to buy X1.com's search tool to get around the incredibly annoying (when you're not desensitized to it) delay when searching in either Windows Explorer or Outlook. The market for this utility should frankly not even exist. It should be the responsibility of the OS to help you find things as quickly as possible, and it should have been done YESTERDAY. I mean Jesus, it doesn't take a rocket scientist to embed something like a SQLite engine in your email client code.

I'm glad that Microsoft is finally getting around to this (someday) but in the meantime I will be quite happy when Apple's Tiger shows up on my doorstep early this summer.

> > The solution is to switch to a database that actually implements ACID (the second letter stands for "Consistency" and the last letter stands for "Durability" which is what failed here).

> Which RDBMSes that you know are 100% ACID compliant? Please name any you know.

Even SQLite, for God's sake!

The first point of the features list on their website: "Transactions are atomic, consistent, isolated, and durable (ACID) even after system crashes and power failures." [emphasis added]

Was you trying to be funny? The fact is that ACID is not that hard that no one has it. MySQL is the only one who seems to have a problem with it, but what is even more frightening is that the answer of MySQL developers was always "ACID? You don't really need it." Even today you specifically need to create tables using non-standard syntax if you want them to be ACID-compliant (and yes, they are MUCH slower than PostgreSQL).

The bottom line is that ACID is something successfully implemented for DECADES in DBMSs. I won't ever trust a self-proclaimed database "expert" who has ever even suggested that ACID is not a top priority because even if that developer adds some half-assed ACID features later to his project, we will see problems like this one with Wikimedia.

If you're serious about your data, you need ACID because it means that EVEN IF THE POWER IS DOWN and EVEN IF THE DISK DIDN'T WRITE WHAT IT SHOULD HAVE WRITTEN when the power went down then your database is still in a consistent state (you know, the "C" in ACID) as in any given point. I've been following the MySQL development since the beginning, and the history of MySQL attitude can be summed up as:

1. First was: You don't really need ACID!
2. Oh, you do? But ACID would slow down the DB.
3. Oh, correct data is important than speed? But in fact, no one has ACID. (YOU ARE HERE)
4. Oh, they do? All of them? OK, here, have those new tables.
5. Oh, they're slower than PostgreSQL? But they are real ACID!
6. Oh, they're not? Wikimedia is screwed? ... (WE ARE HERE)

I wonder how many years will have to pass before people will finally get over it and admit that MySQL is not a serious database...

This is an interesting question. The databases you ask about don't have MySQL gotchas, that's for sure. Nor do they have PostgreSQL gotchas. They don't have SQLite gotchas either. Or Oracle gotchas, for that matter. But one thing is sure, trust me, they most certainly do have gotchas of their own. Do you know them? Can you work around them? Will they silently corrupt your data? Will it be easy to migrate your data to other RDBMS without changing your applications? How do they scale? Do they fully support SQL92? SQL99? Can you afford them not to? Are their transactions truly atomic? Is your data always guaranteed to be in a consistent state? Are the operations on your data isolated? Are the transactions durable? What is the developers' relation to the decades of scientific research and engineering experience in the field of relational database management systems? Do they fully understand it? Do they know why you need ACID? Or would they rather tell you that you don't? Those are the questions that you have to answer. When it comes to relational databases, it is always a question of which gotchas are you ready to face. And of course, as I have already written, you will be unable to answer that question without at least some basic understanding of relational algebra, set theory and predicate calculus. Those fields are essential to understand what the relational model is all about.

The product page boasts their RDBMS is written in pure Java.

Databases engines must mainly do hardcore work on large sets of data (index, sort, merge, uniq, manipulate dates...); using Java for data crunching, is that really a neat idea?

Aside from the needed feature set, speed is I think the most important factor when picking up a RDBMS. I guess this is one of the major reasons for the quick adoption of SQLite and the popularity of MySQL vs. PostgreSQL.

Feel ready to own one or many Tux Stickers?

what about postgresql?

That is a very good question, I don't know why has it been moderated as off-topic. Naturally it is useless to compare MySQL performance to MySQL performance ignoring any other options. (It is essentially the same tactic Micro$oft is doing all the time! Do we really want to parrot them?) First of all, there are MySQL gotchas and PostgreSQL gotchas, so you have to know whether the particular glitches are acceptable for you before you decide to use either RDBMS. Understanding the relational algebra, set theory and predicate calculus is essential to understand what the relational model is all about. Lack of this knowledge often leads to confusing tuples with OOP-style objects and other stupidity, so you will save a lot of time learning it first.

Now, the performance. Generally speaking MySQL is faster for a heavy load of simple read-only queries (like Slashdot) while PostgreSQL is faster for complex read-write queries (like a bank). Once you turn on the ACID support in MySQL it is no longer so fast, and it can really crawl because of row or even table (sic!) locking, a mistake avoided for decades by any advanced database. Here is another comparison. See also this recent thread on Slashdot. One of the best comparisons of Oracle, MySQL and PostgreSQL was done by the Computer division of Fermilab (Fermi National Accelerator Laboratory), this is a must-read.

There is a lot to read about it if you need more comarisons, but the general rule of thumb is that if you want lots of very simple read-only and very few read-write queries when the integrity of your data is not critical, you should probably choose MySQL. When you need that (or better) speed but the data is critical and you need ACID transactions which would severly slow down MySQL, try SQLite, the easiest choice there is, especially using Perl where you don't even need to install it (but just like with every other database, there are SQLite gotchas too, you need to be aware of them). If you need full ANSI SQL compatibility, ACID transactions, scalability and your data integrity is important, you should probably choose Oracle or PostgreSQL. There are also licensing issues. Oracle is proprietary. MySQL is GPL so you need to pay if you want to use it in any non-GPL software. PostgreSQL is released under a free-for-all BSD license. SQLite is public domain.

As you can see, there is no one-size-fits-all database. Every one has its strengths and weaknesses. The correct choice is a matter of trade-offs and finding out which database is optimal for your particular niche. Good luck.

what about postgresql?

That is a very good question, I don't know why has it been moderated as off-topic. Naturally it is useless to compare MySQL performance to MySQL performance ignoring any other options. (It is essentially the same tactic Micro$oft is doing all the time! Do we really want to parrot them?) First of all, there are MySQL gotchas and PostgreSQL gotchas, so you have to know whether the particular glitches are acceptable for you before you decide to use either RDBMS. Understanding the relational algebra, set theory and predicate calculus is essential to understand what the relational model is all about. Lack of this knowledge often leads to confusing tuples with OOP-style objects and other stupidity, so you will save a lot of time learning it first.

Now, the performance. Generally speaking MySQL is faster for a heavy load of simple read-only queries (like Slashdot) while PostgreSQL is faster for complex read-write queries (like a bank). Once you turn on the ACID support in MySQL it is no longer so fast, and it can really crawl because of row or even table (sic!) locking, a mistake avoided for decades by any advanced database. Here is another comparison. See also this recent thread on Slashdot. One of the best comparisons of Oracle, MySQL and PostgreSQL was done by the Computer division of Fermilab (Fermi National Accelerator Laboratory), this is a must-read.

There is a lot to read about it if you need more comarisons, but the general rule of thumb is that if you want lots of very simple read-only and very few read-write queries when the integrity of your data is not critical, you should probably choose MySQL. When you need that (or better) speed but the data is critical and you need ACID transactions which would severly slow down MySQL, try SQLite, the easiest choice there is, especially using Perl where you don't even need to install it (but just like with every other database, there are SQLite gotchas too, you need to be aware of them). If you need full ANSI SQL compatibility, ACID transactions, scalability and your data integrity is important, you should probably choose Oracle or PostgreSQL. There are also licensing issues. Oracle is proprietary. MySQL is GPL so you need to pay if you want to use it in any non-GPL software. PostgreSQL is released under a free-for-all BSD license. SQLite is public domain.

As you can see, there is no one-size-fits-all database. Every one has its strengths and weaknesses. The correct choice is a matter of trade-offs and finding out which database is optimal for your particular niche. Good luck.

First of all, this book seems like a nice rewrite of on-line documentation. It is even a good idea in principle, because building a database driven site with PHP and MySQL is indeed very quick, almost as quick as using Perl and SQLite, but as with every RDBMS there are gotchas. It is true for MySQL, true for PostgreSQL, true for SQLite and even for Oracle, because just like no system is secure, no database is perfect. You always have to know the gotchas to work around them, which is especially important when you want to write a portable database-independent application, which is always a good idea. Unfortunately, this book lacks many important informations about those issues, as it also lacks essential introduction to relational algebra, set theory and predicate calculus, which are important to understand the relational model and to know what the relational database is all about. Without such background, people tend to confuse the relational model with a SQL interface to the filesystem, or an object store, so the lack of such an introduction is the most important flaw of that book. Other than that, it is quite a nice rewrite of many HOWTOs available on-line, and it is always easier and quicker to read one book than to hunt countless websites. All in all, a nice book.

First of all, this book seems like a nice rewrite of on-line documentation. It is even a good idea in principle, because building a database driven site with PHP and MySQL is indeed very quick, almost as quick as using Perl and SQLite, but as with every RDBMS there are gotchas. It is true for MySQL, true for PostgreSQL, true for SQLite and even for Oracle, because just like no system is secure, no database is perfect. You always have to know the gotchas to work around them, which is especially important when you want to write a portable database-independent application, which is always a good idea. Unfortunately, this book lacks many important informations about those issues, as it also lacks essential introduction to relational algebra, set theory and predicate calculus, which are important to understand the relational model and to know what the relational database is all about. Without such background, people tend to confuse the relational model with a SQL interface to the filesystem, or an object store, so the lack of such an introduction is the most important flaw of that book. Other than that, it is quite a nice rewrite of many HOWTOs available on-line, and it is always easier and quicker to read one book than to hunt countless websites. All in all, a nice book.

Good lord, are you kidding? I would assume any reasonable organization that was accessing their database over a network would keep the webserver on a DMZ and the database server behind a firewall that's tightened up and only allows access to the database from the DMZ. Isn't this, uh, kinda obvious?

Hello? We are talking about people using MySQL. Seriously, what did you expect? Calm down, no one is running MySQL for any mission critical database, and no one has any mission critical database open to the world. We are talking about blogs here and small websites, but still I agree that using SQLite would be much better idea -- it's secure from the network, it has real ACID transactions, it is a real RDBMS. But people prefer MySQL running on Windows, what are you gonna do? Nothing. So calm down. It's not the end of the world, is it?

Cloudscape looks really nice. I'm not a Java guy, though, so I use SQLLite (http://www.sqlite.org/) as my embedded database.

You might wanna check out SQLite, which is in the public domain. It matches all of your requirements, and then some, I think.

You might wanna check out SQLite, which is in the public domain. It matches all of your requirements, and then some, I think.

How about using SQLite. It's a C library (native C++, does that mean C is ok?) which provides a self-contained database engine. No need to run a DBMS.

Code footprints:

• SQLite: less than 250KB
• BDB: about 450KB
• Derby: 2000KB jar file

For lite uses, and many heavy ones, SQLite seems excellent. I haven't used it yet, but whoever writes for the project is an excellent communicator.

In my experience, most open source projects, and almost all commercial products, have a (maybe mostly unconscious) plan: "We will carefully measure how much hassle people will accept, and make sure we don't document anything more than enough to just barely keep people from rejecting us."

It's common to visit an open source project and find that, yes, they have a new version, but the manual is two years old. There are plenty of commericial projects that are the same way, like Netgear's FVS318. Their reference manual is for version 1.4, but the latest version is 2.4.

An advantage of open source projects is that they are usually far more honest than commercial projects. I love this from the PostgreSQL What's New page: "Although tested throughout our release cycle, the Windows port does not have the benefit of years of use in production environments that PostgreSQL has on Unix platforms and therefore should be treated with the same level of caution as you would a new product." Marketing people are generally so dishonest that they would not allow an honest statement like this.

MySQL is a non-standard implementation of SQL. That's a problem that's probably partly caused by not doing good documentation. If they had documented everything as they wrote MySQL, they might have seen what a mess they were making. Bad documentation obscures programming messes.

PostgreSQL has an elaborate documentation system, and the new features are very impressive.

If MySQL's features are good enough for you but you want real transactions and ACID and you are sick of the gotchas, then try SQLite. If you are using Perl, then there is a DBI module on CPAN that contains the entire SQLite database, so you only have to run "cpan -i DBD::SQLite" and you can DBI->connect right away! You can even install it in your home directory when you are on a shared hosting, even if you don't have a shell access! Just make a CGI script with "use CPAN" that will install DBD::SQLite and run it with your browser! :) Now, how cool is that? Advantages: it is faster than both Postgres and MySQL, it support truly atomic, consistent, isolated, and durable (ACID) transactions, even after system crashes and power failures, no setup or administration is needed, a complete database is stored in a single disk file that can be freely shared between machines with different byte orders, it supports databases up to 2 terabytes in size, sizes of strings and BLOBs limited only by available memory, small code footprint (less than 30K lines of C code! less than 250KB code space!), it is FAST, it is ROBUST (well-commented source code with over 95% test coverage), it is self-contained (no external dependencies!), it is in the public domain. Cool, isn't it? I love the ability to move the database by just moving the file. That way my websites are truly portable across any platform with Perl (is there anything without Perl?), and I don't even care what database is prefered by my ISP. EOP (end of plug). :)

How about SQLite?
from IBM's site:
"it's just a 2-MB .jar file"
from SQLite site:
"less than 250KB code space (gcc on i486)"

D. Richard Hipp created SQLite, which is now bundled with PHP5. He gives very detailed, personal responses to any questions on the SQLite mailing list. Very nice software and very good support. Thanks Hippster!

I've had to struggle with this also, but after all is said and done, I'm moving our whole embedded platform to linux.

This has had a few repercussion; namely, we're also doing away with the whole Windows client side of the application and replacing it with a web-app. It turns out that when you have a highly evolved embedded web server, scripting language, and database, an active client becomes unnecessary and can be replaced with a web browser.

By the way, just in case anyone else is doing this, in the embedded space I've found that LAMP (Linux-Apache-MySQL-PHP) can be successfully replaced with LBSL (Linux-BOA-SQLite-LUA).

BOA is a little web server (less than 70KB). It uses the GPL license.

SQLite is a very efficient SQL database (about 200KB if you replace math library functions with an inline function). It is public domain.

LUA is a tiny (about 100-200KB, depending on modules compiled in) scripting language with a very elegant design. The math module can be rewritten to not use the math library. It uses the MIT license.

Each of these pieces of software has a different licenses, with SQLite and LUA basically allowing you to do what you please. BOA improvements must be opened up, however you can add functionality through CGI-like modules, and that will not need to be opened.

It looks to me (but I have no experience with it) that SQLite is part of an excellent replacement for Access, FileMaker, dBase, and FoxPro.

From the look of the web site, SQLite is VERY impressive. Now we need a GUI form designer.

One thing a lot of people haven't noticed is that SQLite will be in 10.4 . Read it on Apple's Tiger preview page (right at the bottom, last paragraph).

While they're not specifiying what they're doing with it, or if it'll even be tied to the filesystem, is seems to be in there for some reason, and apple will put it to use.

SQLite ;)

The new version of PHP includes SQLite as well, which is probably a better fit for most web sites. Unlike PostgreSQL, SQLite is not a full client-server database, it is simply an SQL interface for database files. Unless your application is intended to run on a server farm, this might be a better solution. It's also public domain, so even more `free' than PostgreSQL...

The author disclaims copyright to this source code. In place of a legal notice, here is a blessing:

May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.

The author disclaims copyright to this source code. In place of a legal notice, here is a blessing:

May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.

• UNIX utilities such as cp, tar and nsync can properly handle HFS+ resource forks
• command-line access to Spotlight
• new Open Source libraries for XML transformations (libxslt) and data persistence (SQLite)