Re: Choice of DB

On Tue, Nov 27, 2018 at 1:08 PM Nico Callewaert <
app(dot)development1972(at)gmail(dot)com> wrote:

> Hi,
>
> It's my first post to this list. I'm a little familiar with PostgreSQL
> from the documentation but never used it yet in a real environment. I've
> used the last 15 years Firebird as the RDBMS for our ERP application. Not
> bad, it served us somehow ok, but not that great either... I've grown
> unhappy with the product because of the many corrupted database we
> encounter at customer sites. I have plans to rewrite the ERP application
> and use a new RDBMS and create a new database from scratch. And of course
> the problem now is, what RDBMS to use. I know this is not an easy question
> and has no straight answer. And I certainly don't want to start a war of
> words of pro's and con's of database servers. However I have to make a
> choice.
>
> First of all the Uber story scared me. Seems they went from Postgres to
> MySql because of several issues. But maybe issues I would never run into.
> First of all, performance is certainly very important. It's said that
> MariaDB outperforms "everything", but I'm not sure if that's a good choice.
> It's not like we have a thousand simultanous users who are updating records
> non stop. Most of our sites have between 10 and 50 users. Of course they
> insert and update data, but not at a speed of xxx transactions per second.
> They are simply users who enter quotes, orders, delivery notes, invoices,
> projects, time registration of employees on the road, etc....
>
> I'm wondering if PostgreSQL outperforms Firebird in client/server ERP
> applications? The big thing is, sometimes large datasets are fetched, I'm
> wondering if PostgreSQL would do better than firebird and if the
> performance of Postgres is fine let's say compared to mysql or mariadb,
> because if the performance won't be good, my boss would consider the
> migration from firebird a total failure.
>
> Thanks in advance and sorry if my question doesn't fit in with the list.
>
> Best regards...
>

It might be better posted to the "general" list to get a wider audience.
From what you have described, PostgreSQL seems like a great choice. Your
stated reason for looking for alternatives is corrupted databases. I can
say that in the last 15 years I have never encountered that with PostgreSQL
and when someone trips on the power cord or some other issue brings down a
machine PostgreSQL always recovers extremely quickly to a consistent state.

As to performance, PostgreSQL should be plenty fast for the application you
described. I do run consistently at XXX transactions per second where XXX
is in the low 100 TPS. And that is on 10-year-old hardware that is not
breathing hard and not yet upgraded to the latest PostgreSQL. Performance
is more than speed and just like reading one story about Uber (that has had
a lot of pushback), you can find plenty about MySQL recovery times in the
many minutes to several hours.

Look at the overall picture. For feature set, SQL compliance, code quality,
performance, reliability, user-groups, mailing list support, documentation,
cloud availability, commercial support availability, etc. PostgreSQL does
very well.

Cheers,
Steve