Hi HN!We just shipped the public beta of the hosted version of Mathesar, our open source “intuitive spreadsheet UI, full PostgreSQL power” project.Until now, using Mathesar meant installing and running it yourself. Now you can use Mathesar for free without having to maintain your own infrastructure at https://mathesar.cloud.Mathesar Cloud is run by the Mathesar maintainers through the 501(c)(3)...
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.
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.
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
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.
Mathesar, however, is GPL, so you only need to share modifications if you actually distribute the software itself.
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 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.
As for working with multiple linked tables, while editing data, you can search through nested links easily, here's an screenshot illustrating the record selector: https://mathesar.org/_app/immutable/assets/step-3.SKu3rwM2.a...
We also have a visual query builder that can join data across tables: https://github.com/user-attachments/assets/7ff100fe-cd26-422... and https://github.com/user-attachments/assets/0df680d3-621d-466...
I hope that helps!
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.
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.
GPLv3 only applies if you modify and distribute Mathesar itself, it doesn’t extend to services that simply interact with it. If a company makes changes to Mathesar and distributes that modified version, then those modifications would need to be open-sourced under GPLv3. But using Mathesar as a microservice in an enterprise stack? No problem.
We’d love to see companies upstream fixes and improvements, of course!
Metabase adds an abstraction layer with concepts like questions, segments, and metrics, while Mathesar works directly with Postgres tables, schemas, and permissions. Mathesar is deeply integrated with Postgres, so it supports Postgres-native features like role and privilege based access control, which aren’t possible in products designed for multiple database backends.
I hope that helps!
I'm not sure if this would fit your use case, but you can also use a separate SQL editor alongside Mathesar, we always reflect the latest state of your DB.
