Has anybody had any experience using either mySQL or postgreSQL?

[TedAnderson]

For comparison, here is a benchmark (pgbench.exe) on the same machine, where we see around 700 tuples/sec being written.
C:\Users\Ted>"C:\Program Files\PostgreSQL\10\bin\pgbench" --username=postgres -t1000 postgres
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 1000
number of transactions actually processed: 1000/1000
latency average = 1.450 ms
tps = 689.496120 (including connections establishing)
tps = 725.808235 (excluding connections establishing)

C:\Users\Ted>"C:\Program Files\PostgreSQL\10\bin\pgbench" --username=postgres -t10000 postgres
query mode: simple
number of clients: 1
number of threads: 1
number of transactions per client: 10000
number of transactions actually processed: 10000/10000
latency average = 1.407 ms
tps = 710.891140 (including connections establishing)
tps = 714.529320 (excluding connections establishing)

[rolfk]

Well I'm quite sure the pgbench application is NOT going through ODBC or ADO to interface to the database but directly using the native PostgreSQL shared library. As such the comparison is pretty unfair for sure.

The database toolkit uses the ADO/DAO Active X interface which most likely has to go through the ADO-ODBC bridge to interface to the Postgre ODBC driver which in turn eventuelly calls the native PostgreSQL driver to communicate with the database server. Lots of interface translations in between, each with their own specific requirements and limitations. That's going to be a performance killer for sure especially if the ODBC driver wasn't specifically implemented to support the latest and greatest ODBC 3.x features to help the ADO bridge to work more efficiently. And I certainly doubt anyone ever bothered to write directly a PostgreSQL ADO driver, which would shortcut some of the performance bottlenecks.

Over on Lavag.org drjdpowell did create a LabVIEW library to directly interface to the native shared library. You should probably give him a shout.

And yes for mySQL similar things apply. The mySQL ODBC driver is absolutely not known for its high performance. It works but is certainly not the best solution if performance is your requirement.