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.
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!
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.
Yep, AGPL can run alongside proprietary services without issues, and if you host it without modifications, you don’t have to share anything. But if you modify it and make it available over a network, you have to provide the source to users.
Mathesar, however, is GPL, so you only need to share modifications if you actually distribute the software itself.
Thank you! And yeah, I understand your gripe. The tagline is meant to convey the general idea of "editing data in a table UI without a lot of clicks or keystrokes" in the fewest number in words; it does sacrifice precision (although that's why it's "spreadsheet-like" and not just "spreadsheet"). Do you have any ideas for language we could use instead?
Yeah, I understand why that would be a concern. For what it's worth, our schemas are completely isolated and never touch any other data. We use them to store our DB functions and custom data types.
The functions are what lets us reflect the latest DB state in the UI in real-time without worrying about schema migrations or adding a bunch of reflection queries to each API call (which would make the UI much less responsive). We just need them installed _somewhere_ in the database.
Our custom data types (e.g. email, URL) are just available for convenience. If you don't have any columns that use those types, then you'll never need to deal with them.
We don't have any ability to customize UIs yet, although we're certainly open to feature requests.
We do have a "Record Page" for each individual record that shows a tabular view of related records from other tables, here's a screenshot from our website: https://mathesar.org/_app/immutable/assets/step-2.CKT9S1j0.a... - you can create new linked records directly there.
Mathesar doesn’t cache any database state, it always reflects the live structure of the database. If you run migrations through SQLAlchemy or Django, Mathesar will just show the database as it is before and after the migration, no extra steps needed.
You can also modify the data model directly in Mathesar, but if you’re using an ORM-managed database, you’ll need to update the ORM layer yourself to reflect any schema changes. If your ORM expects strict control over the schema, it’s a good idea to configure our permissions to prevent users from making data model changes in Mathesar's UI. Otherwise, it should coexist just fine.
sixdimensional covered this pretty well, but just to reiterate, I believe DBeaver is primarily a desktop app aimed at a technical audience. Mathesar is web-based and designed to have an intuitive, collaborative, spreadsheet-like UI for non-technical users who know anything about SQL or DB concepts. Also, Mathesar has deep integration with Postgres features e.g. you can configure roles and privileges through the UI.
We're working on multiple options for sustainability, both the traditional nonprofit route (major donors, individual sponsors, etc.) and also looking into revenue from hosting or services. We're committed to always being 100% open source and self-hostable no matter what.
