What databases are we really using? Quick community survey

[xmanuel]

Hi everyone,
After several years working with different databases, I wonder if our community is evolving in its technology choices or if we remain loyal to the same old tools.
I'd like to know your experience and opinion to get a real picture of where we're heading. It'll only take you 2 minutes and I'll share the results with everyone so we can see community trends.

1. What databases do you currently use in your projects? (check all that apply)

   DBF/Clipper/xBase
   MySQL/MariaDB
   PostgreSQL
   SQL Server
   Oracle
   SQLite
   MongoDB
   Firebird
   Access
   Other: _______________

1. What database would you consider for your next project or migration? (maximum 2 options)

   DBF/Clipper/xBase
   MySQL/MariaDB
   PostgreSQL
   SQL Server
   Oracle
   SQLite
   MongoDB
   Firebird
   Other: _______________
   None, I'm staying with what I have

1. If you had to choose the 3 MOST IMPORTANT features in a database access library, what would they be? (maximum 3)

   Access speed and performance
   Simple and clear syntax
   Multi-engine SQL compatibility
   Robust transaction support
   Automatic connection and pool management
   Complete and updated documentation
   Practical examples and use cases
   ORM support (object-relational mapping)
   Intelligent caching system
   Clear and detailed error handling
   Active technical support
   Integrated debugging tools

1. (Optional) What currently holds you back from migrating or trying another database?

Thank you for participating! In a few days I'll post a summary with the results so we can all see our community's trends.

[Otto]

Manuel,
I think the answers to this survey depend heavily on context that isn’t mentioned yet:
– size of the business / deployment
– number of concurrent users
– solo developer vs. team
– what “next project” or “future” actually means (1 year, 2 years, longer term)

Without that, very different realities get mixed into the same result.

Best regards,
Otto

PS:
The framing “evolving in its technology choices vs. remaining loyal to the same old tools” is useful as a metaphor, but it deserves context.
In practice, decisions are usually driven by business size, concurrency, deployment model, team structure, and existing data.
Using established tools can be a deliberate and rational choice, just as adopting newer technologies can be. Evolution often happens in architecture and access patterns rather than in the data format itself.

Example / practical perspective:
In some projects we use an extended DBF model where the DBF remains the structured index, while memo data is stored in external XML files.
This allows data structures to evolve at runtime. For example, phone numbers can be extended on the fly within the application — personal, spouse, children, association, etc. — without schema changes or migrations.
This kind of flexibility is often exactly what small businesses need.

[xmanuel]

Hi Otto,
Thanks a lot for the thoughtful and detailed comment — I really appreciate the practical example you gave with the extended DBF + external XML approach. That kind of real-world flexibility is exactly why I think these older formats are still alive in many places.
I completely understand that the “right” database depends heavily on business size, concurrency, team setup, deployment model, timeline, etc. Your points are spot on.
What I’m trying to capture with this quick poll, though, is a raw, unfiltered picture of what developers in our community (especially in Spanish-speaking circles or niches where DBF/xBase, Firebird, etc. are still common) are actually using right now in their day-to-day work — regardless of whether it’s a small business, a legacy system, a solo project, or something bigger.
I’m also curious about the direction people are looking when they think about a new project or a migration (even if most end up staying put — that’s why I included the “None, I’m staying with what I have” option).
And finally, I wanted to see what really matters most to people when choosing a data-access library, no matter which engine they’re using.
That’s why I tried to keep the questions very simple, multiple-choice, and fast to answer (2 minutes max), without adding too many qualifiers or context fields. The idea is to get as many responses as possible and then show the naked numbers + the interesting qualitative comments (like yours) when I share the summary.
If enough people feel the lack of context makes the results hard to read, I can always add an optional quick question later (something like “Main scale you work in: Solo/Freelance · Small business · Medium · Large/Enterprise · Hobby”). But for now I’d prefer to keep it super lightweight so we get higher participation.
Would you mind answering anyway, even if you just drop a line about your typical context in the optional last question? It would help give more color to the final picture.
Thanks again for the great input, Otto — really valuable.
Looking forward to seeing what the community says overall.
Best regards,
Manuel

[Enrico Maria Giordano]

1. What databases do you currently use in your projects? (check all that apply)

DBF and any SQL databases (I try to be engine-aware as I can't predict which database my customers will want to use).

1. What database would you consider for your next project or migration? (maximum 2 options)

It depends on customer request. DBF is my default.

1. If you had to choose the 3 MOST IMPORTANT features in a database access library, what would they be? (maximum 3)

I'm using the standard DBF commands and ADO for SQL.

1. (Optional) What currently holds you back from migrating or trying another database?

I have nothing to try.

As a summary, your survey is not much useful, sorry.

[Otto]

A question for you, Manuel, regarding the survey itself:
how do you plan to continue with the results?

I find the survey interesting, but it would be a pity if it remained just a list of technologies. From my point of view, the real value comes when we go deeper into concepts and access models. Very often, certain options are simply not known and therefore never considered.

An example from my own experience:
I developed php4dbf, a library to access DBF files from PHP. At the time it made sense, but only later did I realize how simple and efficient access via a Harbour microservice using WebSockets actually is.

WebSockets are not an exotic add-on; they are part of the Windows operating system, comparable to network drivers:

extremely efficient

event-driven

running directly in memory

without the classic request/response overhead

This effectively gives you your own “SQL-like server” based on DBF:

with full control over locking

transactions

caching

protocol

and access patterns

The key difference compared to traditional SQL servers is that everything is under your control, with full transparency.

That’s why I think it would be very valuable to complement the survey with a discussion such as:

why do people move away from DBF?

how do they actually access DBF in practice?

direct access, via services, stateful or stateless?

I believe many decisions are driven less by real technical limitations
and more by a lack of awareness of alternative architectures.

[Marco Augusto]

Actualmente utilizo MYSQL y DBF/NTX
A futuro no creo hacer cambios
quizá versiones más recientes de MySql
primera opción MySQL
proyectos antiguos con DBF/NTX

[Rick Lipkin]

I use a mixture

dbf/cdx
MS Access ( sql )
MS Sql Server

Generally I use MS Access Sql ( Microsoft.Jet.OLEDB.4.0 ) for local apps and Sql Server for large Corporate environments. I use DBF\CDX for creating temp tables for reports. When I use local MS Access .. I can easily scale up the application to Sql Server if needed for Corporate users... with SQLOLEDB and no change to the .prg code ... just change the database provider ...

Rick Lipkin

[vilian]

We are using MySql, as a result of its Access speed and performance, mainly in the web.

[alerchster]

MySQL
DBF/ntx & cdx
MS Access

[Maurizio]

MySQL

[Marcelo Via Giglio]

Hello,

ADS (local, remote)
POSTGRES

thanks

Marcelo

[ShumingWang]

MySQL

[Mulyadi]

Oracle

[xmanuel]

I really appreciate your comments, Enrico Maria and Otto, but the idea is simpler: it's a technical inquiry that can help other colleagues in the FiveWin ecosystem learn which database engines are currently being used in production, their use cases, and the advantages/disadvantages found in real-world environments.

[Otto]

Manuel. Do you really think that after years of DBF being criticized and openly bashed here, someone would now stand up and say, “Yes, I’m using DBF”?

If there are more than 1,000 subscribers and only a handful openly choose SQL, what do you think the others are actually using?

Silence doesn’t necessarily mean absence. In many cases, it simply means people prefer not to expose themselves to another round of debate.
Best regards,
Otto
f such a survey is meant to have any real explanatory power, you have to respect at least the most basic statistical rules — otherwise it’s just opinion sampling dressed up as data.

A few key points you can state plainly:

With 1,000 members, a survey needs around 280–300 responses to reach a 95 % confidence level with ±5 % margin of error.

Anything below 100 responses is statistically weak and highly sensitive to self-selection bias.

Below 50 responses, results are essentially anecdotal — interesting, but not representative.

Voluntary surveys in a polarized environment (DBF vs SQL) systematically under-report unpopular or “defensive” choices, regardless of anonymity.

So a concise way to phrase it in English could be:

For a survey like this to be statistically meaningful, basic sampling rules need to be respected.
With a community of over 1,000 members, you would need roughly 300 responses to draw conclusions with reasonable confidence.

Anything significantly below that threshold reflects participation bias rather than real usage patterns — especially in a context where certain technologies have been publicly criticized for years.

In such cases, silence should not be interpreted as absence, but as reluctance to engage.

I actually went back to my old statistics notes for this.
Without a sufficiently large sample size, such surveys are interesting — but not representative.