Re^2: SQLite vs Firebird vs ...

Although I usually use Postgres now, embedded/serverless mode still has its uses, for example when a program which is run by normal users wants to store data/statistics in some relational database without having to deal with system-level permissions or a system-wide daemon. Another approach would be to run a per-user database daemon, like in KDE's akonadi which starts its own MySQL daemon; this is not really feasible for a command line-based program.

Firebird is not unproven, it has a long (as in decades-long, in some form or another) track record. Though perhaps it's still not popular in Unix/Linux circles. Kind of sad, because SQLite really sucks "SQL-wise".

I think I'll bite my finger and just start to use it. I'll share my experiences later.

Comment on Re^2: SQLite vs Firebird vs ...

Replies are listed 'Best First'.
Re^3: SQLite vs Firebird vs ... by Your Mother (Archbishop) on Mar 12, 2013 at 18:32 UTC
SQLite really sucks "SQL-wise". SQLite rules for what it is: an utterly free, stable, embeddable, minimalistic engine. Saying it sucks because it doesn't match your use case is like saying a saw sucks because it won't drive nails well.	[reply]
Re^4: SQLite vs Firebird vs ... by sedusedan (Pilgrim) on Mar 13, 2013 at 03:00 UTC
I was actually saying "SQLite's SQL features sucks (as in: are lacking)". To be more specific: no dates, very limited ALTER TABLE. Is that more objective now? (Although now that I think of it, those two lacking features are crippling for my use cases, others might not be bothered with that).	[reply]
Re^3: SQLite vs Firebird vs ... by core_dumped (Acolyte) on Jul 09, 2013 at 01:40 UTC
I used Firebird a long time ago and remember it was as solid as Postgres is today, providing concurrency, transactions and everything else on the flakiest Windows versions, which is something. The problem I see with using it now is that it has very little support in hosting services, so your application would have to remain in a server you have complete control of.	[reply]