Hacker News new | past | comments | ask | show | jobs | submit login

We use PostgreSQL but also Firebird, which maybe is the great underdog in opensource databases.



While not quite on topic, let me second that Firebird is a fine and under-appreciated RDBMS. Though it can obviously be used to run on your own server, it really shines when it's deployed in the field. It's used for desktop software I help maintain, running at several hundreds of small businesses. The install is super lightweight, requires very little configuration and practically zero maintenance. Firebird strikes a nice balance when it comes to features. What's great is that it can be used with or without a server process. That way you can start using it like SQLite and scale up to a more PostgreSQL-like setup, or go the other way, with no effort. Many years later, we're still very satisfied with our choice at the time.


I used InterBase (Firebird predecessor) 15 years ago, and recall it had some big limits around versioning/lots of updates. To reclaim disk space we’d have to periodically backup/restore the db. It got so bad/frequent that we moved to Postgres and haven’t looked back since. I guess if one is considering SQLite that it’s not too relevant, but is this still an issue with modern Firebird?


Many of IB's limitations and bugs have been removed over the years. I think it was around FB2.5 that it really became a better product than IB ever was. A cool thing, though, is that it's very backward compatible. If you have applications that expect IB6, they will happily connect to any version of FB, even using the old client lib. The pace of development has ramped up since FB3, which was focused on rearchitecting the core. That's mostly a good thing. Still, I fear a little that it will also affect reliability.

Not sure exactly what kind of situation got you in trouble, but I haven't had any issues (ab)using the database myself. Disk space is still not reclaimed. It does, however, get used when the amount of data grows again, of course. Effectively the database is always the largest size it ever needed to be, but no larger. Most of the time, that shouldn't be any issue. If you expect huge spikes, there are other ways around it.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: