
Firebird vs. MySQL vs. PostgreSQL (code quality comparison) - AndreyKarpov
https://medium.com/@CPP_Coder/code-quality-comparison-of-firebird-mysql-and-postgresql-53e39fc3298d
======
rurban
No Sergey,

Do not recommend RtlSecureZeroMemory(), but the secure C11 standard
memset_s(). People will ignore bad advice, which would be a mistake, because
this MySQL crypto bug looks terrible.

See
[http://en.cppreference.com/w/c/string/byte/memset](http://en.cppreference.com/w/c/string/byte/memset)

memset_s is not optimized away.

This would be implemented on FreeBSD with explicit_bzero() or on Microsoft
with SecureZeroMemory(), but there's a C11 standard for this.

You can use safeclib for this, when your libc doesn't have it. It doesn't
because nobody cares yet about secure C functions. At least MSVC and
Embarcadero does, and Android Bionic reportedly also.

------
jmnicolas
A bit off topic but anybody runs Firebird in prod ? What are its advantages
and pain points ?

~~~
rstuart4133
I run it. I used it initially because it was bundled with Delphi decades ago.
It was called Interbase and it was free (well, free if you bought Delphi,
which about as free as you got back then).

If you needed an SQL DB, you just shipped it with your application, and
treated it like you might treat sqlite today. Your user didn't know it was
there, it had a single data file which you could put the data file anywhere
you wanted. The backups are portable to any arch. It used MCC rather than
locks, which was novel for the time. Being able to do a full backup on a live
database without blocking anything was certainly novel, and is still somewhat
novel today. You see other remnants of that choice, like "alter table" being
instant and as far as I know, no conversion time when upgrading between
versions. It also happens to be very fully featured - supporting triggers,
stored procedures and what not, so much so that it was the goto database if
you were migrating from Oracle. Nothing else came close.

Times have changed. It's definitely been overtaken on some features. If it's
not standard SQL syntax, it's unlikely Firebird will support it, so forget
JSON indexing or geospatial indexes. On the other hand if there is a ANSI SQL
syntax, Firebird almost certainly does support it. It's embedded heritage
still shows through. There are almost no maintenance tools besides backup and
restore, because they aren't needed in an embedded setup. Again, very like
sqlite.

And that is why I still use it. If you want to ship an application and the SQL
part just be an unseen implementation detail, Firebird is the one to use. If
you want to use a database as a tool like a spreadsheet, with lots of fancy
tools for getting data and out, and lots of SQL extensions like pivot tables
to make doing one off things easier, then it isn't.

The Firebird source does (or did) support an embedded mode, ie as a library
you just linked into your application, just like you do with sqlite.
Unfortunately none of the distro's seem to ship it that way which is a shame,
because it's handling of concurrent users is so much better than sqlite's I'd
use it instead of sqlite if I could.

~~~
jmnicolas
Thank you for this detailed answer, next time I need SQLite I will look at
Firebird instead.

