If you like Mathesar’s approach but need to work with MySQL, FDWs would let you connect a MySQL database to Mathesar for data entry and querying. This could be useful if you also have Postgres data and want to work with both in a single interface, or if you wanted things like cross-database queries between both DBs.

That said, if you’re only using MySQL, FDWs add an extra layer, and something like VisualDB, since it’s built for multi-database support, would likely be a more natural fit. The main advantage of Mathesar in this scenario would be if you want something open source and self-hosted (VisualDB looks like proprietary SaaS) or if you just like our UI and user experience.

As a side note, we _are_ considering adding support for other database backends through Postgres foreign data wrappers: https://wiki.postgresql.org/wiki/Foreign_data_wrappers. If this is something you'd be interested in, please feel free to open an issue on our repo.

NocoDB is a universal database GUI that supports multiple backends, while Mathesar is Postgres-only but deeply integrated with its native features, like using Postgres roles and privileges for access control. NocoDB also adds its own UI-level abstractions on top of database objects, whereas Mathesar directly reflects the database structure. That said, NocoDB has features Mathesar doesn’t yet support, like kanban and calendar views, forms, and more Airtable-like data types.

Baserow is more of an open-source Airtable alternative and doesn’t connect to existing databases at all—unlike Mathesar and NocoDB. It has many of the same UI-driven features as NocoDB, such as different types of views and forms, but it doesn’t function as a database interface the way Mathesar does.

Mathesar, however, has a visual query builder that allows joins and query creation directly from the UI, as well as some data modeling tools, like moving columns between tables and merging duplicate data—neither NocoDB nor Baserow offer these. Mathesar is also 100% open source, while both NocoDB and Baserow follow an open-core model with paid features.

We do want Mathesar to be competitive as an Airtable alternative over time. You can already create a database from scratch (we’re not just a GUI for existing databases), but we’d likely need more data types, views, and integrations before it can match Airtable across a broad set of use cases.

And Postgres is definitely amazingly versatile! That's one of the reasons we were comfortable focusing on it as the only supported DB backend for now.

Thank you! Where would you need to hide these fields?

If you had some time, it would be great if you could make a GitHub issue with more details about your use case! https://github.com/mathesar-foundation/mathesar/issues

I think they're pretty different use cases. LibreOffice Base and Kexi are desktop database frontends focused on local databases, while Mathesar is web-based, self-hosted, can be connected to a remote database, and built for multi-user collaboration.

We don't have the capacity to do that internally, but we were thinking about having a "Community Guides" section of our docs where people could contribute guides to setting up Mathesar on different infrastructure. Let me know if that's something you'd be interested in contributing to!

Just a heads-up, I’m opinionated on this!

Every app has some terminology you need to learn to use it effectively, we just think that terminology should actually map to how databases work, rather than being an arbitrary abstraction. Instead of inventing our own terms, we stick to tables, records, schemas, and relationships so that users who learn Mathesar are also learning concepts that translate directly to Postgres (or relational databases in general).

Making software approachable isn’t about hiding complexity, it’s about presenting it well. The UI patterns you use determine whether a system feels intuitive, not whether the underlying mental model is simple. A well-designed interface can make even complex concepts feel natural, while a bad one can make simple tasks frustrating. Mathesar doesn’t make databases approachable by pretending tables aren’t tables, it makes them approachable by using familiar interactions, and progressively exposing functionality as you need it.

We do want to work on surveys ("forms") soon, and we're definitely thinking about bulk actions and integrations as well. Please feel free to open a feature request on https://github.com/mathesar-foundation/mathesar/issues for anything that would particularly help your use case.

Ultorg is awesome! Eirik (Ultorg's founder) and I compare notes every once in a while. :)